gregvish / l1tf-poc Goto Github PK

In function read_memory_byte, we should change the type of byte_scores from uint8_t to uint64_t.
uint8_t byte_scores[0x100] = {0}; --> uint64_t byte_scores[0x100] = {0};

Because the byte could really be 0, and if byte_score[0]>255, it will overflow. For example, if byte_scores[0] is 256, it will overflow, hence byte_scores[0]==0, and will not go into the following branch. As a result, we will miss the real byte 0，specifically when byte_scores[0]%256 is within the interval of [0,ZERO_CONFIDENCE_THRESH].
if (byte_scores[0] > ZERO_CONFIDENCE_THRESH) {
*out_byte = 0;
return true;
}

In README.md Practicality section, you said
"The limitaion of host physical address randomization appears to not be very significant for this attack vector, as on my machine I got about 14 bits of entropy for the host kernels physical addresses. Therefore, it's possible to find the very recognizable sys_call_table with 16k read attempts (perhaps 10-20 minutes based on this PoC). "

But the precondition is that we must know the offset of the sys_call_table, which is about 20 bits. So, actually, we must do at least 2^34 read attempts(base:14bits + offset:20bits) to find sys_call_table, which is far more than 10 minutes. In other words, it is impossible to success in a real attack.

Can you share me some more tricks to achieve a successful attack in real world, e.g. how to get the offset of the sys_call_table.