Hi!

First of all, I'm a newbie. And english is not really a strength of mine. So I hope, you spend a little patience.

I'm trying to crack a little proggy called tcsync.exe (w*w.tcsync.com). Really not a big one. I thought this could be a good start for me.

For the normal registration procedure,
I have to enter the registration number, which is tested and then written to the registry.
On every start, the program reads this registry-entry and shows unregistered or even not.

I've used w32dasm and found the place where the entered key is evaluated. (search for 'sorry ...')
I've nop'd the je-jump and now the program says 'thanks for registering' at all entries.
But I can't find the registration check at the program start.

Could you give me a hint, how I could find where the registration-key is read and checked from the registry?

Thanks in advance,

hambam

perhaps, my question was a little bit difficult to understand what i want to?

I enter a serial number (what ever i want: 1234 or what ever)
and the program says 'thanks for registering' .
After that the 'Press to register' button disappears and the program heavy looks regged now.
So far, as i quit and restart the program, anything like before.

The entered serial code (1234) is written to the registry.
I believe, on every start, the program checks the serial from the registry again, but i can't find the location.

Could ever somewhere give me a hint, how to find it out, or where the code is located?

Thx in advance!

try setting breakpoints on registry api functions like
RegQueryValueExA or RegCreateKeyExa

This is quite a nice little target, and actually links in with ZaiRoN's floating point crackme/keygenme.

From a patching point of view, i suggest you scroll up slightly

The actual serial verification is done in a separate call, which then returns success/not in eax. A rather large hint is call [ecx+34]. This is rather annoying, as you cant simply trace through to see where it is in the deadlisting, but as youre simply cracking it, why not try looking at other occurances of "call [ecx+34]" and see where u get from there.

That's probably too much help, but hey.

Keygenning it is *much* more fun. And I'm saying that at 5:15am, so don't argue. Ok, its not actually that hard, but as with ZaiRoN's crackme its unusual simply because it uses (exclusively in fact) floating point commands. An excellent debugger to use for this (I found out, cos I couldnt be bothered to reboot to get softice working) is OllyDbg. If you've done ZaiRoN's crackme, and want a real-life routine with fp commands in, take a look at this. A little bit of maths needed too

After that, of course, look at my keygenme (hopefully still on the board, otherwise at h**p://www.crackmes.de under GodsJiva). It uses quite a lot of fp mixed in with some other fun stuff (and no, you *dont* need to bruteforce md5). Still noone has done it, so this is my plug

hmm, it isn't going one step further.

I didn't understand why the call [ecx+34] could be the sub for testing the serial.
But I believe in you.
I found 8 occurences and tried to understand what has been done before this call, but ... looks like it's a little bit too difficult for a very first try?

My very first and easy try was to nop
:00430D80 0F8407010000 je 00430E8D

and the result was turning the prog regged, just as long as it runs.

So my conclusion was, that the prog turns to be regged _after_ the 'succesful'-message. When it is a sub, it must be called 2 times, or not?
If it isn't a sub, the code must be found twice. Am i right?

I wasn't able to find your keygenme nor ZaiRoN's floating point crackme/keygenme. So no support from this direction.

hi hambam,

look at this threads in the mini project area:
h**p://www.woodmann.net/forum/showthread.php?threadid=2475
h**p://www.woodmann.net/forum/showthread.php?threadid=3555

regards,
ZaiRoN

Well I suck at teaching ppl, and dropping hints will prolly do no good if you can't even find ZaiRoN's crackme.

Go to the main page, go to Mini Project Area, top thread (at the mo, may be a lower one by time u read this). Or just follow his links

So I'll do it pretty much for you, but explain it along the way.

Load up OllyDbg (from protools.cjb.net , its free!). Load tcsync.exe. Goto debugging options and disable breaking on exceptions (loads of fp exceptions in this). That's whats stopping you debugging it in w32dasm if you'd tried.

This is my spectacularly lazy way of doing it (if I were going to crack it and not keygen it). But its prolly the easiest to follow.

You've already seen the bad boy jump at 430d80. Look at what its comparing. Get the dump to look at that mem location. Scroll up quite a way, till u think it doesnt look like registration relevant bits. Place a breakpoint (f2). Go to register and put in anything, click ok. When it breaks, stick something random in that memory location using the edit function (select the bytes by click/dragging, then right click and choose edit). Trace using f8. See where it gets turned to zero.

You will (hopefully) find that the last time it gets put to zero happens when you f8 over 430d44, that call [ecx+34] command. So, lets trace *into* it. Place a breakpoint, redo the registration thing, when it breaks, trace in by pressing f7. You will end up at 442470. Look at 4425dc (or around there). The result that gets put in there comes from another memory location. So lets bpx the start of this proc (442470), do the registration again, and start tracing (at this point you may want to try restarting the program with this bp set, you will notice it doesnt break so chances are the main check is another subcall (or the proc is repeated somewhere else, but its not, so forget that for this app)).


[note: from now on, exact offsets hidden so as not to be a simple crack]

If you trace through, you will find the right call is at 4*****. Trace into this, as before, and you end up at 4*****. Breakpoint this and restart the program, and bang, it breaks. So looks like this is the main check. Forget the actual routine, we're (well, you) aren't interested in that. Look at 4*****, near the end of the proc. Its the final check but just patching that won't do (probably), because the subsequent bit relies on eax. So lets patch the bit at 4*****.

5E POP ESI
66:8901 MOV WORD PTR DS:[ECX],AX

...is the code there at the moment. 4***** loads the mem address of the bit we dont want to be 0, else regged=false. So we need to change something so that before that command at 4*****, eax (or ax) is not 0. I leave that to you, with some final hints: xor eax,eax makes eax 0 (in case u didnt know). eax can be anything other than 0 (probably), but you cant rely on it not being 0 before this (or can you? I didn't by nature, but try seeing yourself). the easiest (shortest) way to change a register is the command inc (for increase). and finally, the command 8901 is the same as 668901. (that 66 can be replaced by a 1 byte op in other words).

You can take a horse to water and stuff its head in it, but...

"If it isn't a sub, the code must be found twice. Am i right?"
There are very few hard and fast rules in cracking, because different coders and compilers do things in different ways, and do basically what the hell they like. The best way to crack imho is to *understand* and work out (by testing or whatever) what is going on, and reason what needs to be done.

Have fun,

Oh yes, it's really an easy way with this fine proggy OllyDbg.

So I've found the subcall at 443520 which breaks at program start too.

And '40 inc eax' is the easiest way to patch 44366C.

But to be honest, without your aid ....
(not only because of OllyDbg )

Thx

No problem.

Hopefully by following the method youve started to understand what happens in programs, rather than just looking for jumps near string refs

Glad you like OllyDbg, I do too. Not great for everything, but still useful

Happy reversing!