Hello,

playing around with an aspack protected application after unpacking it I've found that the application at a certain point generates the correct regcode for the provided name and compares it with the user's one. I'd like to write a "keygen" that takes advantage of this fact (in fact I read sometime ago a post about someone that did the same thing but I just can't manage to find it anywhere) to obtain the correct regcode directly from the application.

I was thinking of writing a loader that:
1) requests a name from the user
2) writes it in the registry where the target application places the name and regcode to verify them at startup
3) loads the target application
4) patches it so that the correct regcode once calculated by the application will be sent to my "keygen"
5) displays the correct regcode on the "keygen" (or directly write it to the registry value used by the application)

What I'm missing are the following:
1) how to block the application as soon as it has been unpacked so that I can patch it before it runs???
2) what interprocess communication mechanism???

About the interprocess communication I was thinking that I should use APIs that the application already uses (I admit I wouldn't know how to add one or more functions to the target's IAT).

Any contribution is appreciated.

yaa

To make the program stop "after unpacking" you should probably use some kind of tracer (not necessarily tracing every instruction, but possibly just using a series of breakpoints from a debug loop). If you can find some API that is used closely before the point you would like to stop the program at, you can hook this API and break into the execution flow this way instead.

As for "interprocess communication", I suggest that you simply stop the program with a breakpoint (not from a third party debugger, but using a debug loop in your loader) at the right point just after the serial is calculated, and then simply read it directly out of the memory of the target process (traverse the stack based on ESP if needed).

Having come that far, you could most likely make it a generic aspack loader instead, patching the serial check code at the same point as you would read the calculated serial from memory, but I can see that a keygen might be more fun. Hell, why don't do both as a fun exercise.


dELTA

dELTA hooking an API near the regcode generation algo is something I did not think about and it is in fact a good idea (although it is not a generic solution requiring having to adapt the keygen to each specific aspack protected target).
But I'd like to ask you if you could say something more about "traversing the stack based on ESP". Could you please provide some hints on what that would typically involve or be accomplished? As you may have understood I'm not a master on these subjects although I'm trying hard to understand and learn ....

yaa

I meant that if the serial is located on a stack/heap address that will for some reason be different on different executions or between different instances of packed programs, this memory location (or a pointer to it) will most likely be located at a fixed distance from the current value of the ESP register (i.e. the stack pointer, which you will read from the target process context after getting the break on your desired code location).

I've always known I should have read that "Debugging Applications" book I bought time ago. Unfortunately, I believe "stack walking" is a little bit too far of what is reasonably in my reach.

yaa

Nah, it's not really hard at all, it's just like accessing local variables, but in another process. If you are not familiar with the concepts of registers, stack, heap and basic assembly programming, I understand it could be hard, but in that case I'd recommend something else than writing a loader in any case.

You will really benefit from learning some basic assembly programming before doing any cracking. After that this should not be an impossible project at all, and you will most likely learn a lot of useful things from it.

For info regarding how to debug processes in Win32, the following tutorials over at Iczelion's site is a very nice start:

hxxp://spiff.tripnet.se/~iczelion/tut28.html
hxxp://spiff.tripnet.se/~iczelion/tut29.html
hxxp://spiff.tripnet.se/~iczelion/tut30.html

The other tutorials at Iczelion's page are very good too, but they discuss Windows API (assembly) programming rather than general assembly programming, and you will need the general parts first for it to be really useful. But you should indeed look at all the Win32 assembly tutorials at Iczelion's after that:

hxxp://spiff.tripnet.se/~iczelion/tutorials.html


Anyway, come back when you are ready, and we'll continue with your project then, no hurry.

dELTA I'm no master, but I'm no novice either. Still it is true that I'm no expert of all those topics that matt pietrek or john robbins used to deal with in their articles. I will start coding this thing and will try out all of these ideas. When I get stuck I'll search around for reference material and help.

Thank you for the encouragement, the info and the pointers.

yaa

Hi,
I did write a little loader for the crackme discussed in this thread: http://www.woodmann.net/forum/showthread.php?t=5107
It involves some of the things you need to write your loader.. maybe, it could help you a little.

Ciao,
ZaiRoN

Molto gentile ZaiRoN.

But I do have a small question: you first say that 0x0041A001 is the OEP and then you say that 411C30 is the entry point of the unpacked crackme. Looking at you code it seems that 411C30 is the OEP while 41A001 is the packed crackme EP. Am I right?

yaa

Yes, it's my fault, sorry.
File updated.

ZaiRoN

what about a loader whitch joins the already runing program and changes the bytes in memmory i had done it on win98 but still working on winxp

Hi dee.
Yes, you are right but this works if and only if the code you want to patch is not been executed yet ;-)

ZaiRoN

the code can be executed but it must be in a cycle or program must go thru the same code you are trying to change again,
lets say it is looking for something (Dongle) untill it will be insterted and the loader joins the process returns the good values,
or just loader waiting till the process will execute and then will join the process and patch the code,
you will ask why not to patch directly in the file - well this kind of loader can be used on instaliation then on setup start it is looking for dongle, program extracts some exe files in Temp and executes them (you cant replace them there becase they are used).
And to make the patch for user for this kind of instalaition is difficult, you need to rebuild the setup files, so this kind of the loader i think is a good solution, what do you think?

Oh yes, I thought you will have understood this from what I wrote

ciao,
ZaiRoN

Hello dee, how would you code a loader such as the one you are describing???

yaa

just an idea......... but why not use a program to dump the program from memory to disk when loaded and unpacked - then use ida to dissasemble - then identify and rip out the routine that generates the serial (and its support routines), fix it up so that it assembles properly and then use somewhen else's keygen routine for all the window crap.

Zaza

2 Zaza:

for serial protection it is easy, just need to find where it checks it.

and if setup is looking for dongle? keygen wont help you

2 yaa:

i had already done the loader like i described before but it works only on win98 i'm still wotking to make it work on winxp

it works like this
CreateToolhelp32Snapshot
Process32First
Process32Next
ReadProcessMemory - to find the processs i'm looking for by original bytes
WriteProcessMemory - to change the bytes

true but i think its neater to generate a valid serial and enter it into the program rather than patch the app on every execution. (im talkin' about yaa's original target rather than the crackme)

which i was under the impression wasnt looking for a dongle

2 Zaza

yes you are right ofcourse if it is a serial only protection there is no need of loader you need just find the right serial

zaza what you are proposing (dump the program from memory to disk when loaded and unpacked - then use ida to dissasemble - then identify and rip out the routine that generates the serial and its support routines, fix it up so that it assembles properly and then use somewhen else's keygen routine for all the window crap) isn't THAT EASY!!!

Honestly having found where the application generates the correct serial for the provided name, it seems much easier to try to make a loader-keygen as I thought it.

dee ok for the CreateToolhelp32Snapshot, but if you have snapshoted the correct process why the need for the Process32First, Process32Next???

Hi!CreateToolhelp32Snapshot takes a snapshot of the specified processes in the system, as well as the heaps, modules, and threads used by these processes.After that, if you want to find a specific process, you have to walk through the processes list using Process32Next function (no need to use Process32First).

As an example, if you want to change some bytes from a running process you can follow this simple scheme:

hSnapShot = CreateToolhelp32Snapshot(...)
while (Process32Next(hSnapShot,...))
begin
Is this the process I am looking for?
Yes: begin
handle = OpenProcess(...)
WriteProcessMemory(handle,...) // to patch the file
CloseHandle(handle)
quit...
end
No: try with the next process
end
CloseHandle(hSnapShot)

ZaiRoN