Introduction
The reason for making this tool (and other) is trying to find a job involving reverse engineering / cybersecurity etc…
In a contrast of having a “blank” CV that merely claims that you know your stuff, I thought, well, better make some projects and open source code to show it off instead.
I have decided to try and test how secure is this (and other) product, and whether can I bypass its protection and possibly make a small project.
Reversing process
Finding memory address
When you run target (surfblock.exe) (and everytime you bring it it up from systray) you are presented with a dialog box asking you to input password.
You input it wrong and get message box prompting you to try again. So there must be some function checking if the password is valid or not before letting you in or displaying message box.
The target is not packed/obfuscated, no anti-debug tricks, no ASLR etc… so not using all this stuff speeds up reversing process.
It also means that all of the strings are in cleartext and visible in a debugger/disassembler, so searching for a “password” keyword or similar seems like an option. But there are many results, so trying to be more specific and searching for a string displayed in a message box gives you only this:
The string is UNICODE, so setting breakpoint on MessageBoxW and backtracing a bit seems like a good way to land you in the password checking function. The trick works, and after you input wrong password and click OK you break at MessageBoxW inside USER32 module.
After returning from USER32 you are here:
but still not inside pass check function. You are in the, what it seems to be,centralized function that deals with diplaying message box stuff.
Step till 00509B8F → RETN 4 and exit this function.
After that scroll a bit up and you are at what it appears to be beginning of some function, presumably password checking function.
Clear MessageBoxW BP and set it at 008B38BC → PUSH EBP.
Input password again, and you break at the beginning of this function.
After stack/register preparing instructions, the function immediately checks if the entered password is correct or not by comparing it with a real password.
008B38F4 E8 4B4AC2FF CALL surfbloc.004D8344 ; length of typed in pass
008B38F9 8B45 FC MOV EAX,DWORD PTR SS:[EBP-4] ; points to typed in pass
008B38FC 8B15 C0568E00 MOV EDX,DWORD PTR DS:[8E56C0]
008B3902 8B12 MOV EDX,DWORD PTR DS:[EDX]
008B3904 8B92 58040000 MOV EDX,DWORD PTR DS:[EDX+458] ; points to correct password
008B390A E8 514FB5FF CALL surfbloc.00408860 ; compare strings
The decrypted password is stored in memory like this:
fixed address → fixed address → dynamic address + 0x458 = pointer to correct password
So in this case its 0x008E56C0 → 0x0090DBB4 → dynamic_address + 0x458
Password decryption
If you look inside Windows Registry (where programs commonly store their settings), you can see that the Surfblocker stores its settings there including encrypted password.
But setting BP on RegQueryValueExW (and other registry functions) didn’t work. I needed different approach.
I have already found memory address where the decrypted password is stored. But how the actual decryption is done and where?
I reloaded target in the debugger, set hardware breakpoint on write (DWORD) at second fixed address (in this case 0x0090DBB4), and run.
After HW break we are here now:
Now we have got dynamic memory address written at 0x0090DBB4, but the password is still not decrypted.
So set another HW breakpoint on write (DWORD) at dynamic_address+0x458, and run.
After second HW break we are here:
At this point, I can see decrypted password in the EDI and ESI registers, but the decryption is already done and this function doesn’t look like a decryption routine.
After executing till return (Ctrl+F9 in Olly) twice we arrive at a rather long function. Near the top of this function we see an interesting call at 0x006ECC42:
Examining this call showed that surfblock.exe is trying to communicate with Internet Protector Service (IProtectorService.exe).
After that call password gets decrypted, so it looks like decryption process is happening somewhere inside this service.
The next step was to attach a debugger to this service and examine what is happening there.
Now, since setting BP on RegQueryValueExW inside surfblock.exe didn’t work, I tried this approach inside service module, thinking it should work now, because before decryption takes place, encrypted password must be loaded in the memory buffer.
That did the trick, and we now break at RegQueryValueExW inside IProtectorService module:
After returning from the call we are here now:
0062FD9F E8 C8E4FFFF CALL IProtect.0062E26C
Call at 0x0062FD9F does the XOR decryption as you can see from inside the function:
Conclusion
That’s it.
We have finished reversing this product and defeating its protection.
I hope you have enjoyed
Visit link below for a project:
Demo here: