patch signed exe file (not Dot Net)

[Black_Legion]

Hi

there is an EXE file which is signed (and it's not Dot Net) and it seems that it checks itself after passing the Entry Point. i'm not sure but it may be a CRC check only.
patching the license part, the program starts but it throws an exception and it will close, so i guess here that it checks the signature or CRC
i bypassed the exception and now the program starts with no problem, but now when i try to close it, the window freezes.
tracing for where it freezes, i reach here in olly:

00410B31    .  FF15 40835B00   CALL DWORD PTR DS:[<&KERNEL32.CreateThrea>; \CreateThread
00410B37    .  6A FF           PUSH -1                                   ; /Timeout = INFINITE
00410B39    .  50              PUSH EAX                                  ; |hObject = NULL
00410B3A    .  FF15 44835B00   CALL DWORD PTR DS:[<&KERNEL32.WaitForSing>; \WaitForSingleObject

which at "WaitForSingleObject" the program freezes.

i also tested duP2 as a loader for program and the program works in that way but when i try to open a file with the program, it opens another instance of itself (unpatched) while the loader has been closed before.

does anyone has any advice?

thanks

[Shub-Nigurrath]

Have you scanned the exe with kanal or some other crypto searching tools?
Is it packed with some protectors?

[gigaman]

That WaitForSingleObject waits for a thread to finish (the one created in the previous call). Have you checked what the corresponding thread function does?

[Black_Legion]

thank you

@Shub-Nigurrath
i think the exe is not packed, because i can see all the strings unencrypted and the hex patching works.
scanning with kanal 2.92 says: "Detected 50 crypto signatures" -> 46 CRC, 1 MD5, 1 SHA1, 1 SHA-256, 1 SHA-512

@gigaman
using IDA i can see "__security_check_cookie" around the function which i patched to bypass first check, is it something familiar?

[Shub-Nigurrath]

Hi
two hints: the __security_check_cookie is just another thing, tied to stack canaries (http://www.codeproject.com/Articles/1854/Compiler-Security-Checks-In-Depth) and second, for sure one of the above hash functions is involved in the strange behaviour.

What I would suggest to do (simpler solution, at least from my point of view) is to do an interactive loader that does these steps:

1. load the exe in debug mode
2. put an HW breakpoint in the right place (not a real BP, just to not raise mismatches in the hash checking functions). Place it in a stable place to avoid ASLR (http://en.wikipedia.org/wiki/Address_space_layout_randomization) if you run on Win7 onward, or calculate using stable anchors (for example a BP in an API).
3. start the victim and wait for the HWBP to hit
4. find from there the right place to patch and place another HWBP just after the execution point
5. restore the original code

Quite complex indeed, but not once you know how to do it, and most of all you could find all the required theory in my tutorials on writing loaders available at the ARTeam site.

The alternatives are
1. do the loader direcly in ASM and embed it into a stub of the exe, as an in process injected code
2. defeat all the hash placed in the code.
3. see if you can patch outside the exe itself (for example whe you deal with nags sometimes you can patch the loaded user32:MessageBoxA/W to immediately return)

BR,
Shub

[Black_Legion]

@Shub-Nigurrath
many thanks for the hints
for the loader I will read more as you suggested from your tutorials
and I think to go with the alternative one as I did the same in the past
I will let you know if any progress made

[Conquest]

can you pm me the target. i am willing to take a look into and hopefully i will learn something new from it.