this should a little harder than the last one

here is the crackme

this crackme is very very very similar to the previous one. it uses only a slightly different algo.

Name: figugegl
Email: figugegl_2000@yahoo.de
Serial: WYGYGYGPGWPPPPYYPGGWPYPP

and in my opinion there's a bug in it this crackme. in the final calculation routine it uses the length of the string at address 4080D8 instead of the lenght of our modified name.

figugegl

Hi all,

it is an honour for me to post my first message on this messageboard
I agree with figugegl, the 2nd crackme used the same template of the first (and I used the same template for the keygens too
)
I think there is no bug, because, as far as I can remember, the 1st crackme used the same way to loop, although I think the way it loops weird. Maybe the author could do some more optimized iterations..

And about a breakpoint to get in the code, I think the best way to find it is unpacking the proggie and looking the imported functions. I used one breakpoint on a function (can't remember the name right now) and then searched my name and BPMed it.
You could also breakpoint at the comparison routine (it is a well known one)

sorry for my bad english and for my lameness

cya
d4d0

Hey all,

Just a couple of quick n00bish questions (sorry). Anyhoo, I'm experiencing some difficulty unpacking this app. I am attempting to unpack this app manually and I have done all of the standard things...
1) Patch the bytes at raw offset 7CB to E9FBFFFFFF to throw the app into an infinite loop just before it jumps to the original entry point
2) Dump the process while it is in an infininte loop to disk using procdump
3) Edit the entry point of the dumped file using procdump so that it points to the OEP (which I believe should be at RVA 1400)

once I've done all this the app crashes when I try to start it. Now I've noticed a couple of strange things... which I won't waste your time describing, just need to know if I'm on the right track... for some reason the application seems to be doing something funny in kernel32 on startup and when I try to automatically unpack with a tool like Procdump, procdump seems to believe the OEP is somewhere around the base address for kernel32?? This clearly isn't correct... For some reason my approach ain't workin'... any thoughts would be greatly appreciated