|Hmm, this looks crypto'y|
I took a few of the above constants; 28955B88h 173848AAh 242070DBh 3E423112h and threw them in to Google to see what I could find.
|We have a winner! :>|
After seeing the reference to MD5 I quickly remembered my GUID related post where I found two values that appeared to be the stringified versions of two md5 hashes. I highly suspect this function is used to generate that GUID. I'm still doing static analysis at this point, my next post will probably clarify what is going on by setting bp's in the debugger while it runs. So we have md5, awesome. No one codes their own MD5, so I bet myself that I could find the source they used... For that I headed over to koders code search. I selected C from the language and converted the hex value (28955B88h) to it's decimal form which is 606105819d.
md5.c from RSA. Can't get any more obvious than that. By finding the direct source, I was able to re-label four functions that are the assembly versions of the C code. Here are snippits of the asm alongside the C source:
So we now have four of the md5 functions accounted for and labeled. But continuing my search, I also noticed another function with some pretty unique looking values. Using the same technique above, I took the 9D2C5680h and 0EFC60000h values and koders searched them. To my surprise it turned out to be the Mersenne Twister algorithm, also known as rand() in some languages :>. So now I have two more functions re-labeled to sgenrand(seed) and genrand().
|rand()? Why thank you, don't mind if I do!|
Overall, a pretty successful find, took longer to write this post than it did to get everything discovered and re-labeled, but hey that's the price you pay for documentation!