Closed mr-ma closed 6 years ago
The problem is solved, i.e., we don't get false alarms.
| 0x00400de0 c745d8700d40. mov dword [local_28h], sym.f20
| 0x00400de7 66c745e84400 mov word [local_18h], 0x44 ; 'D'
| 0x00400ded c745c4370000. mov dword [local_3ch], **0x37** ; '7'
| 0x00400df4 8b7dd8 mov edi, dword [local_28h]
| 0x00400df7 0fb775e8 movzx esi, word [local_18h]
| 0x00400dfb ba37000000 mov edx, **0x37** ; '7' ; 55
| 0x00400e00 e8db000000 call sym.guardMe ;[1]
As illustrated in the sample snippet, the placeholder corresponding to 0x37 is patched twice, once in the load and another time when the argument is being prepared for the guardMe call. This is particularly bad when we apply OH, as constants are not properly (if not at all) protected by OH.
Why the compiled binary doesn't respect the LLVM IR remains a mystery to me! @anahitH Any ideas?
Reported by @dennisfischer
Given following the LLVM IR:
We get the following binary representation (of course after post patching guards):
Despite the fact that the expected hash is loaded:
The corresponding argument in the binary representation for guardMe is read from a constant value, which must be read (I EXPECT) from the loaded value.
This problem duplicates expected hash tokens, and since the post patcher expects one patch per token, some placeholders remain unpatched. Therefore, false tamper detection is taking place in the protected binaries.
A harmless hack is to extend the post patcher to patch all the occurrence of tokens in the binary.
This should not affect #1.