Hi all

I just recently started reversing (although I think that's an expensive word for what I really do), and have done only disassembler approaches (dead listings). I thought it was easy enough to reverse some jumps and make the progs think they were registered. Now I was thinking about trying some serial fishing. Judging from the tutorials and posts I read, it seemed simple enough and it was a way to progress from just the jump reversing.
So I got myself a file, since it could be useful to the work too, and tried to fish it.
Just so you now (and if you want to see the code, cause I don't have it here - I'm writing from work), the program is Target Name and Addy Removed So, I disassembled it, and found the famous GetWindowTextA. And then I made myself debug it (I used OllyDbg), set a breakpoint on GetWindowTextA and the program stopped there when I tried to register.
As far as I could understand, the first time it stopped was to get my username. So far, so good. It gets the user, and starts making call after call inside call, and then I get lost. I managed to see that the prog was converting each letter of the user to hex, but not its real value in hex, instead something xored.
The prog does something similar with the serial, but I can't seem to follow the logic.
I've been around it for two weeks and with no success. Can't find the compare to the real serial, can't find an error message no reverse the jump (exescope shows a window of "Registration Failed", but I never get to see it), can't find the correct serial in memory although I have traced into ALL the calls and have been watching the stack and dump windows os OllyDbg...
I used fileinspectorXL to see if it was packed, and it says it's packed with Shrinker 3.2, but DeShrink says otherwise.
I would be really thankfull if anyone could point me in the right direction.

Oh, by the way, I'm not asking for a serial or crack, just some tips. I'm sorry I can't paste de code here, but it would be too large anyway, cause I don't understand most of it. I tried to avoid posting stupid questions, but I have nothing but stupid questions.

Sorry for the long post, just trying to make it clear for everyone. Excuse my english.
Thanks all.

First of all: Remove the name of the program.
Second: Try some simple crackmes first. Try hxxp://www.crackmes.de

boy, talk about fast moderation/answering!

I'm sorry for the references I made to the program, but I see it's been taken care of.
Anyway, I think I'll follow that crackmes advice... better to start from the beginning and have a learning curve less abrupt than I'm having.
Thanks.

Now a days, very few programs construct or hold the 'real' serial in memory and do a daylight, direct comparison with your fake serial. It is just to easy to track, by placing breakpoints into compare_string like APIs.
Based in what you describe, your target was calculating a hash of the fake serial and comparing it to a hash for what it was suppossed to be.
Hashes are more or less irreversible transformations, in which given the serial is straightforward to obtain the hash, but the oposite operation, given the hash, it is complicated or impossible to extract the serial.

strangely enough, I think I understood your explanation
So, if I could (cause I can't) recreate the process of making the hash and reverse it, considering the hypothetical situation in which I could determine where it creates the hash for the REAL serial, I would then obtain the serial number...
I really enjoyed writing all these expensive terms... hope I'll someday be able to make it happen...
This target needs serious reversing, thank you for explaining.

This does not increase the security, since the real serial obviously needs to be present in memory at some point if a hash is calculated from it (unless of course valid serials are not dynamically calculated, but instead only picked from a limited pool of static serials, in which case the static hashes of the valid serials could be stored in the program directly, thus limiting the possibilities of extracting a valid serial from the program, but since this "static pool" of serials would in turn introduce a big security hole itself I really wouldn't recommend it anyway ).

The 'Hash' of the real serial does not need to be calculated from a hard copy of a serial, it may be derived from your user name, hard-disk serial, a security code some other defined variable or combinations there of.

And in exactly what way would it then be related to the "hash" that you are comparing to the "hash of the real serial"? Sounds to me like you're back to describing a normal serial again. Remember that it is implied in the term "hash" that you should not be able to easily derive two different datasets that have equal hashes, and that applies to shareware authors too.

Guess I was using the term hash too loosely, but I think buf got the idea.

you're right, I did get the idea...
meanwhile, I registered at crackmes.de and already cracked 2 crackmes AND without patching, both serial fishing... hope I'll get good at it, eventually.
By the way, from what dELTA said, about the serial having to be stored somewhere in memory, I read something about a "point h", which is equal to HMEMCPY but for XP. Can any of you try to explain me how to find that "point h"? or this question too lame and I should be severely spanked?
And another thing... kind of off topic from the serial fishing issue, but related to the software I was trying to reverse: how can I determine if the file is packed and which packer was used?
thanks in advance.

You can use PEiD to determine which packer is being used.

thank you, i'll get that PEiD now. I used FileInspectorXL once, but the result was totally wrong, so I don't trust it.
as for the "point h" bit, any tip?
thanks