nikolatesla20
June 25th, 2002, 19:51
To look at the newest Milkshape 3d build. (1.6.0)
Found at:
h**p://www.swissquake.ch/chumbalum-soft/ms3d/download.html
OK The BASICS:
Make sure you have the newest regmon or a regmon that has the window class name patched. Otherwise milkshape will close it on you if you try using it.
REGMON gives us:
The date check is easy to defeat - there are 3 registry keys under HKCR\xxxxxxxxxx where the "x's" are a encrypted string, which is different on different systems (my theory is they are based off of OS product ID) this is so you can't build a generic loader unless you knew their algorithm of course. Easy to build a single loader per machine basis tho to kill them to start your 30 days over.
But this is besides the point here. Let's look at the file itself. MS3D.exe.
There appear to be a few interesting items. Now go easy on me it's been a little while since I've looked at packed apps (a few months).
Ok Ok today I have a headache and I haven't tried too hard but I was just looking at it anyway.
To begin with there is a filename check being done. Change the filename and it won't run anymore. Going on:
Also, it "appears" to be protected by ASprotect (possible new strain) , because if you run Revirgin on it all of the conventional KERNEL32.dll calls, etc are using the "mov eax, [xxxxxxxx]" technique. But since other things are going on too, I am not 100% sure yet. Maybe it is UPX or something like that.
The biggest item to encounter is a SOftICE debugger detection. I have to tell you that of all the programs out there that supposedly have detection, I have rarely encountered one that actually seems to work, especially in Win98. This is one of them. The other would be The Sims game. NOw, we all know of the conventional detection methods of course. It doesn't look like IceDUMP or FrogsICE protects softICE this time. I remember reading once that an idea for Win98 would be to simply check the autoexec.bat file for the Softice run command. Well guess what, this programmer must be reading the RCE messageboards because I found on my 98 machine that this is what it does. Boot up your computer with SI on it, and then simply delete the line referring to softice in autoexec.bat, and you are off to the races, goodbye detection. Nice try
I'm still not sure how to get around in it in Win2k yet though, I haven't tried it yet.
Just for your entertainment, the "30 day check" is simply after the unregistered messagebox. And I mean RIGHT after.
0044758F cmp ESI, 1E
If this compare is less than 30, it clears AL (xor al, al)
If this compare comes out greater, it moves 1 into AL here:
0044776A mov AL, 01
So all you need to do really is mem patch this to move a zero (xor al,al). You could have a loader watch for the days left box and then patch. I tried using PELG (the best loader ever!) but it doesn't work since it renames the file, and there is a filename check. LOL.
Some resources look to be encrypted until the program starts. For example, when the messagebox comes up to say how many days remain, you cannot dump from there and examine the resources. But if you dump after the program runs, at least the bitmap resources come out fine. So you would have to paste these in manually later of course. THIS ALSO points to ASProtect because the messagebox telling you the time left is most likely a callback from asprotect into the program, after which the whole program is actually decompressed and run normally.
Anyway the biggest thing that actually throws me on this one is the file size. The program is only 500Kb. If you use ProcDump on it, it comes out to 50 MB ! Open this baby up in LordPE or in PEditor and you will see a strange thing, which I haven't seen before - The last few sections are at VA 33F0000 and higher. OK let me explain. There are six sections to this file. The third section is the queer one. It has a raw size of only 1C600 but the virtual size if set up to be 335D000. Why the heck is that so big? I have no idea. That is a lot of padding. And then the fourth section then starts at 33F0000. It's almost as though the program is going to be unpacked in this huge space? I've never seen this type of thing yet so feel free to give me your input. I "almost" seems like a trick to fool ProcDUMP. maybe. In either case your dump ends up huge.
Anyway, if you guys need something to do maybe you can join me in examining this target.
-nt20
Found at:
h**p://www.swissquake.ch/chumbalum-soft/ms3d/download.html
OK The BASICS:
Make sure you have the newest regmon or a regmon that has the window class name patched. Otherwise milkshape will close it on you if you try using it.
REGMON gives us:
The date check is easy to defeat - there are 3 registry keys under HKCR\xxxxxxxxxx where the "x's" are a encrypted string, which is different on different systems (my theory is they are based off of OS product ID) this is so you can't build a generic loader unless you knew their algorithm of course. Easy to build a single loader per machine basis tho to kill them to start your 30 days over.
But this is besides the point here. Let's look at the file itself. MS3D.exe.
There appear to be a few interesting items. Now go easy on me it's been a little while since I've looked at packed apps (a few months).
Ok Ok today I have a headache and I haven't tried too hard but I was just looking at it anyway.
To begin with there is a filename check being done. Change the filename and it won't run anymore. Going on:
Also, it "appears" to be protected by ASprotect (possible new strain) , because if you run Revirgin on it all of the conventional KERNEL32.dll calls, etc are using the "mov eax, [xxxxxxxx]" technique. But since other things are going on too, I am not 100% sure yet. Maybe it is UPX or something like that.
The biggest item to encounter is a SOftICE debugger detection. I have to tell you that of all the programs out there that supposedly have detection, I have rarely encountered one that actually seems to work, especially in Win98. This is one of them. The other would be The Sims game. NOw, we all know of the conventional detection methods of course. It doesn't look like IceDUMP or FrogsICE protects softICE this time. I remember reading once that an idea for Win98 would be to simply check the autoexec.bat file for the Softice run command. Well guess what, this programmer must be reading the RCE messageboards because I found on my 98 machine that this is what it does. Boot up your computer with SI on it, and then simply delete the line referring to softice in autoexec.bat, and you are off to the races, goodbye detection. Nice try

Just for your entertainment, the "30 day check" is simply after the unregistered messagebox. And I mean RIGHT after.
0044758F cmp ESI, 1E
If this compare is less than 30, it clears AL (xor al, al)
If this compare comes out greater, it moves 1 into AL here:
0044776A mov AL, 01
So all you need to do really is mem patch this to move a zero (xor al,al). You could have a loader watch for the days left box and then patch. I tried using PELG (the best loader ever!) but it doesn't work since it renames the file, and there is a filename check. LOL.
Some resources look to be encrypted until the program starts. For example, when the messagebox comes up to say how many days remain, you cannot dump from there and examine the resources. But if you dump after the program runs, at least the bitmap resources come out fine. So you would have to paste these in manually later of course. THIS ALSO points to ASProtect because the messagebox telling you the time left is most likely a callback from asprotect into the program, after which the whole program is actually decompressed and run normally.
Anyway the biggest thing that actually throws me on this one is the file size. The program is only 500Kb. If you use ProcDump on it, it comes out to 50 MB ! Open this baby up in LordPE or in PEditor and you will see a strange thing, which I haven't seen before - The last few sections are at VA 33F0000 and higher. OK let me explain. There are six sections to this file. The third section is the queer one. It has a raw size of only 1C600 but the virtual size if set up to be 335D000. Why the heck is that so big? I have no idea. That is a lot of padding. And then the fourth section then starts at 33F0000. It's almost as though the program is going to be unpacked in this huge space? I've never seen this type of thing yet so feel free to give me your input. I "almost" seems like a trick to fool ProcDUMP. maybe. In either case your dump ends up huge.
Anyway, if you guys need something to do maybe you can join me in examining this target.
-nt20