Hi guys,

first of all: Happy New Year, I wish you all the best.
For me, the new year seems to start quite strange.
I have here a program which uses MD5 to create a part of a serial.
I let the string to be hashed run through and compared the output with my MD5 generator -> the values were different.
I compared the output with an online MD5 generator -> the values were different.
Ok, it's a custom implementation of MD5 I thought and started to examine the algo. Well I didn't find anything custom. So I ripped the code out of the program and wrote a tiny prog around it, just to see what happens. Guess what? -> the values were different! The ripped code produced completely valid MD5.
Somewhat stunned now, I let the program run on one machine and the ripped one on another to compare it step by step. This way I found a really strange thing (at least for me).

It's this line:



The value in ECX is 0x15D0222D and in EDX it's 0x10325476
Computing it it's 15D0222D + 10325476 + E8C7B756 = 0ECA2DF9 (since we have DWORDS).
This is also, what shows in the pane:



So, the value I'd expect to see coming up in EDX is 0ECA2DF9. Well, it's not...
After hitting F8, the value in EDX is 0ECA2E9E !!!
I don't know why. That drives me crazy! I don't even know what I should search for.
So if anyone of you has an idea, I'd be really, really thankful.

Best regards
darkelf


edit says: Nevermind! I found out, that this behavior only occurs when the program is run in Olly. All is well. Nobody was harmed.

Hello, darkelf.

Interesting problem. Did you check for entropy, pseudo-randomness generation routines on the application? They may lead you, if you find them, to a salting issue on the md5 calculation.

broken processor?

Was it some kind of deliberate anti-debugging trick, or just some strange bug in Olly? If you put a breakpoint right after this asm instruction (o.e. instead of single-stepping over it), does it still get the same incorrect value, just by having Olly attached to the process?