5aLIVE
October 25th, 2005, 08:30
Quote:
[Originally Posted by LLXX]Well, I've seen a lot of these "home-made" packers before, and they all seem to use some sort of standard compression algorithm, so I wrote a little skeletal program that can use various compression library DLLs to essentially compress or decompress raw data from files. It's also very useful for decompressing software installation packages too. |
Sounds like a neat little tool. Would you be willing to share the source so that I can learn from it please?
Quote:
[Originally Posted by LLXX] If you'd rather not code your own, searching the Internet reveals "demonstration" programs for particular compression libraries, which often allow you to compress and decompress raw data. |
I wouldn't mind coding my own tool some day, but I don't yet have the experience to do it. I am working my way through some C++ books at the moment so with time and practice I should be able to come up with something. I image it's a bit of an advanced project for me at the moment.
Quote:
[Originally Posted by LLXX] |
Quote:
[Originally Posted by LLXX]As for the unpacking... let me tell you that I never touched it with a debugger at all. From reading the paragraph above I think you can already guess what I did. |
Yes, I think so.
Quote:
[Originally Posted by LLXX] In a hex editor I located the start of the compressed data portion (a compressed executable in zlib will start with an end letter of the alphabet like x, y, or z due to the fixed "MZ" header, this particular one begins with 'x'), extracted it into another file and decomp'd it.
|
Now that is an interesting fact, I had no idea a compressed exe begins with x,y or z. You must have learned this from direct experience with ZLib and perhaps a data compression expert? You decomp'd the new file using your custimised tool in this case, yes?
Quote:
[Originally Posted by LLXX]I also noticed the "drop to disk" image, after I'd decompressed the thing already (well, it was kind of fun...). |
Absolutley, I was suprised by this myself (never seen such a "trick". You've just proven that there is more than one way to approach this.
Quote:
[Originally Posted by LLXX] I'd guess both are the same. (I normally, unpack if necessary, examine new software by browsing through it with Notepad (it works well, and easily enables you to see code compactly) to ensure there is nothing particularly malicious or strange in there). Running the dropped image on my system yields an IPF in MFC42.DLL. I presume the dropper initialises the DLL first or does some similar action to prevent this from happening.
|
I wouldn't mind making the comparison to verify if you like. Using notepad as a reversing tool now that is a new one on me. Quite a revelation

I normally use hiew or IDA. I;m afraid I don't understand what you mean by an IPF, what is it?
Some sort of page fault would be my best guess.
Quote:
[Originally Posted by LLXX]The decompressor stub is about 175K but most of that is static data (a lot of hex strings and possible reg keys?) and zlib unpacking routines, so it shouldn't be that much of a bother to reverse and see exactly how it drops the image to disk and then loads it. (There is a CreateProcessA and some file-related imps in the IT, so it's quite obvious what it's doing.)
|
I understand in essence what you are saying but I really need to read up on some of the Win32 APIs to get anywhere close to seeing what makes it tick.
Quote:
[Originally Posted by LLXX]The registration key is encoded in base-64. Figure out how I hypothesized that without actually using a debugger or a disassembler, only using Notepad  |
I can only guess that you made this discovery having seen string data which has a familiar characteristic found in base64 code strings; it looks random but there appears to be some pattern to it. and the case of the ASCII characters changes every so often, with upper case characters occuring in groups of 3. Well that was the case for the test base 64 string I looked at.
Am I right?
LLXX, I really must thank you for taking the time to write such a lengthy and informative reply.
UPDATE:
I found a user name and serial number for an old release of this which looks like base64. I thought if I decode it, it would reveal the the stolen/sniffed user name and password. The decoder gives unexpected ASCII chars like LSÿ›3Ú£4dKAaÌ‹¼1, so I can only assume they are not valid base64 strings or I am assuming the registration scheme is simpler than it actually is. I also tried encoding the user name and password which gives VEZQL216UGFvelFTQldSTFFXSE1pN3d4 which is easier to read but still unitelligible. I won't really know how it works unless I actually try and debug the reg scheme of course. This is proving to be an interesting distraction.
UPDATE :The user name and serial number doesn't even work with the old release so there is probably not much point playing with the base64 de/encoder at this point.
Best regards,
5aLIVE