Inception can't find signature for Windows 7 SP1 (6.1.7601.22616)
Opened this issue · 14 comments
I'm using a fresh pull of Inception, the most recent version as of 2014/11/25. (v0.4.0)
Running the tool yields no result, it's unable to find the pattern. My target is a Windows 7 x64 SP1 with 4 GB RAM.
This is what I have:
C:\Windows\System32\msv1_0.dll (File version: 6.1.7601.22616)
MD5: 3D44F6A846FF2EB89742FB0239930119
SHA-1: 054B1253870F00ABE16867B20A5FE282BBE007BB
SHA-256: F9ACDE56081676A728DF9336B3DDF78BD78EF98AEA41F176D74B1465075622ED
C:\Windows\SysWow64\msv1_0.dll (File version: 6.1.7601.22616)
MD5: BCFA9744837CA3EAB9D9B759986E3EF3
SHA-1: B55F6A5DBAA5896F73AEC66CDE886FDFCDB4B4DA
SHA-256: 5EB671854151AEA8D6125EC7D868E7514059D35EBD1DC8275EB83254D1C43F04
Anders Karlsson on 2014 June 16 commented that Inception v.0.3.5 does not find the signature for this verion of the DLLs after some recent patches for this version, so I assume I'm not alone with this issue.
Looking at the DLLs in IDA Pro results in this:
System32/msv1_0.dll (x64 binary), searching for pattern "C6 0F 85 ?? ?? ?? ?? B8" from the unlock.py is found at 1 place:
000007FF73505E5A BE 10 00 00 00 mov esi, 10h
000007FF73505E5F 48 8D 55 50 lea rdx, [rbp+50h] ; Source2
000007FF73505E63 48 8B CB mov rcx, rbx ; Source1
000007FF73505E66 4C 8B C6 mov r8, rsi ; Length
000007FF73505E69 FF 15 81 A4 03 00 call cs:__imp_RtlCompareMemory
000007FF73505E6F 48 3B C6 cmp rax, rsi ; <-- Pattern found
000007FF73505E72 0F 85 CC 1E 01 00 jnz loc_7FF73517D44
000007FF73505E78
000007FF73505E78 loc_7FF73505E78: ; CODE XREF: MsvpPasswordValidate+3EC9
000007FF73505E78 ; MsvpPasswordValidate+3ED5 ...
000007FF73505E78 B8 01 00 00 00 mov eax, 1
In my opinion this looks as it should be, inception should have no problems finding it.
SysWow64/msv1_0.dll (x86 binary), searching for pattern "83 F8 10 0F 85 ?? ?? ?? ?? B0 01 8B" is found once:
6D48C699 6A 10 push 10h ; Length
6D48C69B 83 C3 34 add ebx, 34h
6D48C69E 53 push ebx ; Source2
6D48C69F 56 push esi ; Source1
6D48C6A0 FF 15 8C 11 48 6D call ds:__imp__RtlCompareMemory@12 ; RtlCompareMemory(x,x,x)
6D48C6A6 83 F8 10 cmp eax, 10h ; <-- Pattern found
6D48C6A9 0F 85 12 B3 00 00 jnz loc_6D4979C1
6D48C6AF loc_6D48C6AF: ; CODE XREF: MsvpPasswordValidate(x,x,x,x,x,x,x)+EBCB
6D48C6AF ; MsvpPasswordValidate(x,x,x,x,x,x,x)+EE5B ...
6D48C6AF B0 01 mov al, 1
6D48C6B1 8B 4D FC mov ecx, [ebp+var_4]
This also looks right.
In both (x86,x64) binaries I'm able to find the pattern with only 1 occurence, in the msvpPasswordValidate function.
At this point I don't know why inception says that it can't find the signature, can you please help me?
I suspect that the offsets field should be extended "[0x2a8, 0x2a1, 0x291, 0x321, 0xe59]", but unfortunately I was unable to comprehend where it's used or what this field for.
NOTE1: I'm sure that the firewire port is working.
NOTE2: This might be unrelated, but sometimes the scan is done under a minute, and sometimes it takes like 15 minutes.
NOTE3: If I run the tool multiple times each other, sometimes it says it found the signature and patched it, but it does not work when I try to confirm it.
Thanks for a detailed issue!
Looks like you've already reverse engineered two new signature offsets. So thanks! I will test them myself but if you replace line 147 in:
inception/modules/unlock.py
with
offsets=[0x2a8, 0x2a1, 0x291, 0x321, 0xe59, 0xe71],
you can test it yourself.
If the scan is done under a minute, it's likely that you were not granted DMA. Use the -v switch to see if you're able to read data (the box on the right in the progress bar should show an excerpt of the data read). I'll have a look myself to confirm, and consider increasing the delay before attacking to help ensure DMA is granted.
Re: NOTE3, I'm not sure what the root cause of this is. I'll investigate.
Thank you for your quick response, I'll test it too. Can you please tell me from where did the "0xE71" offset came from? I'm sure it's something trivial but I don't get it :) 👍
Sure!
In your x64 sample, you posted:
000007FF73505E5A BE 10 00 00 00 mov esi, 10h
000007FF73505E5F 48 8D 55 50 lea rdx, [rbp+50h] ; Source2
000007FF73505E63 48 8B CB mov rcx, rbx ; Source1
000007FF73505E66 4C 8B C6 mov r8, rsi ; Length
000007FF73505E69 FF 15 81 A4 03 00 call cs:__imp_RtlCompareMemory
000007FF73505E6F 48 3B C6 cmp rax, rsi ; <-- Pattern found
000007FF73505E72 0F 85 CC 1E 01 00 jnz loc_7FF73517D44
000007FF73505E78
000007FF73505E78 loc_7FF73505E78: ; CODE XREF: MsvpPasswordValidate+3EC9
000007FF73505E78 ; MsvpPasswordValidate+3ED5 ...
000007FF73505E78 B8 01 00 00 00 mov eax, 1
You've marked that the pattern was found at line 6, in a set of instructions cmp rax, rsi at the address 000007FF73505E6F. However, the pattern starts at byte 3 in the instructions.
As binaries are loaded aligned to page borders in memory (meaning that the start of msv1_0.dll will be at the start of some page in memory), we know that the content of the file will be split into 4KiB chunks and distributed in memory. The 'offset' in inception is simply the internal offset within each page that contains these chunks.
This means that if the start of the pattern had been found at address 000007FF73505E6F, the offset would be the last three bytes of the address:E6F (since 4 KiB = 0x1000). But since our pattern starts 2 bytes later, we add 2 to E6F to get E71.
Not sure that was the best explanation, so let me know if it doesn't make sense.
Thank you for the explanation, it's clear now! Were you able to verify that it work with the new offset? Because it does not work on my side :(
OK, so I updated my Win7 x64 RTM box to the latest patch, and lo and behold, the tool still worked. This had me puzzled.
After some research, it turns out that Windows has two different service branches depending if you install updates through Windows update, Microsoft Update and/or WSUS (you will stay on the normal GDR branch) or install patches manually (you will branch to the LDR branch).
You, my friend, seems to be on the LDR branch, where file versions starts with 6.1.7601.22xxx. While I'm on the GDR branch, where file versions start with 6.1.7601.18xxx. That actually clears up several instances of people reporting inception's inability to locate sigs to me which I've previously attributed to HW errors. So thanks!
I'll see if I can find a way to switch branches, and if it works I'll merge both of the offsets above into a patch for inception (0.4.1) - will close this issue when it's out.
Just a quick check: You're sure you're getting DMA, right? If you run the tool with the -v switch, do you get a output similar to this:
[*] Selected target: Windows 7 MsvpPasswordValidate unlock/privilege escalation
[========> ] 402 MiB ( 20%) {720061006c002200}
e.g., with rapidly changing hex numbers at the end between the { and }?
That's correct, I am getting DMA. I'm able to dump the full memory of the machine.
So is being on the LDR branch answers the issue here? As far as I understand that should not cause Inception to fail :( Because the patterns should match as we observed it.
I'm 90 % sure the root cause of inception failing is that you're on the LDR branch. Still looking into why the new offset doesn't work. It may be a while though, I'm quite busy at the moment.
I can confirm that 0xe71 is the correct offset and I can now successfully unlock such system.
Some other factor might be behind the problems in my situation, because changing the offset didn't really have effect on my test subject.
That's weird. Can you paste the full output of the tool with verbose switched on?
I can't, the said machine is not with me anymore, I'm sorry. Thank you for your help though!
Have a similar issue now.