Log in

View Full Version : Ladies and gentlemen, I invite you.


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

Lbolt99
June 26th, 2002, 02:00
Sounds interesting, will check it out soon, unforuntately am on vacation so can't do much till next monday..

One idea might be to try just the simple /dump command in Icedump.. that way you can specify the size.. not sure if that would work but it gives more control over /pedump.procdump

Very interesting on the softice check.. almost to the point of lame, but it did throw you off for awhile.. there is another program I know of with an "interesting" softice trick.. CacheX by MSOW software - it's easily defeated with icedump, BUT without using icedump - if you simply start the program, run until you get to the check, skip over it.. proggy crashes It ties something having to do with the softice check into the decryption it does on segments of the code.. pretty neat

Woodmann
June 26th, 2002, 03:00
nikola,

I hope we can see a "paper" written about this by you :-)

Peace, Woodmann

nikolatesla20
June 26th, 2002, 04:30
Ok I have a few more updates.

OEP is 0047C745

I couldn't use my ProcDUMP on my win98, the file seems to take forever to load (it's like 52 megs) so I just used IceDUMP.

Base: 00400000 - size: 0341E000

After dumping don't forget to realign the file (In PEditor, use the dumpfixer, VO = RO and VS = RS). Now your icon will show up properly.

I fired up Revirgin and got almost all of the imports, the conventional ASProtect ones, I did it manually in SI to be safe. Revirgin likes to crash my Win98 sometimes, and you can't trace mov eax, [xxxxxxxx] instructions anyway, you look at their return value and see what it should be.

So far I ran into one API that looks funny. It calls to 049DCEB8. If you U the code there, this is what you will see. This is in ASProtect memory area.

Code:


015F:049DCEB8 55 PUSH EBP
015F:049DCEB9 8BEC MOV EBP,ESP
015F:049DCEBB 53 PUSH EBX
015F:049DCEBC 8B5D08 MOV EBX,[EBP+08]
015F:049DCEBF 8B4518 MOV EAX,[EBP+18]
015F:049DCEC2 50 PUSH EAX
015F:049DCEC3 8B4514 MOV EAX,[EBP+14]
015F:049DCEC6 50 PUSH EAX
015F:049DCEC7 8B4510 MOV EAX,[EBP+10]
015F:049DCECA 50 PUSH EAX
015F:049DCECB 6A05 PUSH 05
015F:049DCECD 8B450C MOV EAX,[EBP+0C]
015F:049DCED0 50 PUSH EAX
015F:049DCED1 53 PUSH EBX
015F:049DCED2 E86175FFFF CALL KERNEL32!FindResourceA
015F:049DCED7 50 PUSH EAX
015F:049DCED8 53 PUSH EBX
015F:049DCED9 E8CA75FFFF CALL KERNEL32!LoadResource
015F:049DCEDE 50 PUSH EAX
015F:049DCEDF E8CC75FFFF CALL KERNEL32!LockResource
015F:049DCEE4 50 PUSH EAX
015F:049DCEE5 53 PUSH EBX
015F:049DCEE6 E8DD75FFFF CALL USER32!DialogBoxIndirectParamA
015F:049DCEEB 5B POP EBX
015F:049DCEEC 5D POP EBP
015F:049DCEED C21400 RET 0014



This almost looks like a new API that ASprotect offers, the ability to display a Dialog Box with DialogBoxParamA. Actually, I set up a BPMB (using SuperBPM) on this call, and it only executes when you click the "About" menu. The "About" and Registration entry dialogs are created through this call. This would be simple to paste this code into your EXE after dumping and redirect it to the correct location so it works. But the about box has bitmap resources on it too so make sure they are unencrypted. (I say don't click on about )

There are "other" API's on the end of my IAT yet, but my theory is they might just be junk that I have to trim off. I have to look at the real size of the IAT in SI yet.

That's the progress so far. At least I got the OEP for sure

BTW : This program WILL detect SI if you aren't using IceDUMP in Win98. But now if you fire up IceDUMP, Milkshape 3d won't give you the messagebox anymore, but it will just exit. This is because it sees the reference to winice.exe in your autoexec.bat file. That's right, it checks autoexec.bat.

The solution I came up with was to simply create another batch file (I called it RUNDEBUG.BAT) with the call to winice.exe in it, and then just CALL this batch file from autoexec.bat (at the end of autoexec.bat, put CALL RUNDEBUG.BAT). That way autoexec.bat has no winice.exe references in it. A simple redirection. Problem solved for good. They aren't the only ones who can redirect !


-nt20

Kilby
June 26th, 2002, 11:48
The 52 meg image size in ram may be an attempt to prevent dumping.

In some recent securom wrapped games the damn things had a 115 meg footprint in RAM.

icedump, procdump lord pe et al totally failed on my machine, and I had to use my own dumper to do the job.

After optimising the dump it came down to a more manageable 950 KB

Regards

Kilby...

Far from home and sitting infront of a mac (Yeuch !!!!!!)

nikolatesla20
June 26th, 2002, 15:01
OK I got it unpacked and running without a problem it seems, pretty much nothing new I guess, just same old *SProtect unpacking job. , just a larger file than normal that's all.

I like having Win98 for dumping and tracing, and I use Win2K for import rebuilding because it's more stable. If i have a question about an import I use the 98 machine to trace look at it in SI first.

The benefit is in Win98 SI is more easily hidden from most detections.

Yeah the file is still 52 megs I'll see if I can optimize it now without breaking it. Looks like it runs now tho.

-nt20

nikolatesla20
June 26th, 2002, 19:24
Fixed the file size / name check. Turns out to be actually in one of the DLLS the the file loads, "msModelLib.dll".

There is some checking going on, who knows, but who cares, we just don't want it to kill the app. Here is the code I found that does so:

Code:
0167:03991362 7414 JZ 03991378 ﷓
0167:03991364 6A00 PUSH 00
0167:03991366 6A00 PUSH 00
0167:03991368 6A12 PUSH 12
0167:0399136A 56 PUSH ESI
0167:0399136B FF1504A19903 CALL [USER32!SendMessageA]
0167:03991371 56 PUSH ESI
0167:03991372 FF1500A19903 CALL [USER32!DestroyWindow]
0167:03991378 6A00 PUSH 00
0167:0399137A FF15FCA09903 CALL [USER32!PostQuitMessage]
0167:03991380 6A00 PUSH 00
0167:03991382 E80E1E0000 CALL 03993195
0167:03991387 8B8C242C010000 MOV ECX,[ESP+0000012C]
0167:0399138E B801000000 MOV EAX,00000001
0167:03991393 5E POP ESI
0167:03991394 64890D00000000 MOV FS:[00000000],ECX
0167:0399139B 81C434010000 ADD ESP,00000134
0167:039913A1 C20C00 RET 000C
0167:039913A4 90 NOP
0167:039913A5 90 NOP
0167:039913A6 90 NOP
0167:039913A7 90 NOP
0167:039913A8 90 NOP
0167:039913A9 90 NOP
0167:039913AA 90 NOP
0167:039913AB 90 NOP


The PostQuitMessage we DO NOT want to do. So we want to just skip it. AND the code right after it we don't want either (the CALL after it) because that does a GetCurrentProcess and TerminateProcess. We want to just skip all of this and jump to that 03991387 address.

Edit the bytes at 03991378 to be EB 0D instead of 6A 00. (a nice little jump). By the way, this would be file offset 1378.

Now the proggie will run no matter what its name is, or what its size is. yay !

Another nice effort by the shareware programmer. A cross-referenced check.

-nt20

Tola
June 26th, 2002, 21:36
here's what i remember from v1.5.x (which was not packed at all, iirc).
one of the date check keys was dependent on the system's hard disk (probably used the volume serial number, there's a call to GetVolumeInformation somewhere). moreover, it created a file containing the same information in your win/system dir.
date check/registration specific messages were initialised in a temp. buffer before displaying them so there are no string refs.
there were 3 crc checks, one in the executable, one in a dll checking the executable and another one in another dll checking the first dll
btw, try this:
create a textfile and rename it to 'w32dasm.txt'. use notepad to open it and try to run milkshape

i didn't yet check out the new version, though.

nikolatesla20
June 27th, 2002, 03:42
There is only one "CRC" check in this version that I've seen so far. It's in the msModelLib.dll and it checks the filename/ size of the executable, and exits if it's not right. I simply patched the DLL to not ExitProcess. Now it works fine.

No CRC's in the actual executable at all. I've patched almost all of the "bugs", I removed the Windasm check. I haven't removed SoftICE checks at all, nor the date check yet, but I suspect that won't be too hard.

I have the file naked and realigned with LordPE on my hard disk now, it's only about 1.1 Megs after realinging, and it runs fine.

There's a string "decryption" routine at 00447780 that gets called from everywhere - if you see any of the strings in the resources be warned: they are not used. The strings are actually hardcoded in the EXe with mov instructions, such as mov [esp+123], 54. The "54" of course is not the REAL ascii hex 54, it is "encrypted", it goes to the routine above and then you get your real message. All the messageboxes use this technique or their messages, so not really that hard now to track them down, just look for a bunch of mov byte ptr instructions.

I have to say this author actually seems to know what he is doing, he checks for almost every tool RCE's use. I found references in his program (In encrypted code strings) to SoftICE, NTICE, FROGSICE, WinDASM,FileMon, and RegMon so far.

Quite well done. *But not well enough yet * I'm almost done correcting all the flaws..

*ONE SMALL NOTE **

I looks as though most of the import / export DLLS are loaded dynamically, and they appear to be based off of a template, which does the CRC check. All of the dlls can kill the process it looks like. SO that means you would have to patch all of the dlls. Maybe it's worth the 20 $ LOL

-nt20

Lbolt99
June 27th, 2002, 04:25
Awesome work so far, sounds like a really interesting protection.. will definantely have to take a took at it when I'm back from vacation. Sounds kinda similar to the problem I've ran into with Quick To-Do Pro v3.7, concerning possibly encrypted strings.. although I don't think that's the case cause I changed one of them w/resource hacker and it changed in the program.. that was for the about box.. still haven't been able to do anything about the startup nag.. which displays proper code, but it only appears to be a routine to randomize the button placement in the nag window

I am almost certain that the author of Q T-D pro has somehow mucked the resources to throw off dede when looking at the form create code for the about box (and also possibly the startup nag) . is it possible that he could have done something to make Dede start disassembling the form create process 'after' the interesting code, making it look like there's nothing important at the routine? Not sure what else they can do, the code has to execute somewhere

Quote:
Originally posted by nikolatesla20

There's a string "decryption" routine at 00447780 that gets called from everywhere - if you see any of the strings in the resources be warned: they are not used. The strings are actually hardcoded in the EXe with mov instructions, such as mov [esp+123], 54. The "54" of course is not the REAL ascii hex 54, it is "encrypted", it goes to the routine above and then you get your real message. All the messageboxes use this technique or their messages, so not really that hard now to track them down, just look for a bunch of mov byte ptr instructions.

I have to say this author actually seems to know what he is doing, he checks for almost every tool RCE's use. I found references in his program (In encrypted code strings) to SoftICE, NTICE, FROGSICE, WinDASM,FileMon, and RegMon so far.

Quite well done. *But not well enough yet * I'm almost done correcting all the flaws..

*ONE SMALL NOTE **

I looks as though most of the import / export DLLS are loaded dynamically, and they appear to be based off of a template, which does the CRC check. All of the dlls can kill the process it looks like. SO that means you would have to patch all of the dlls. Maybe it's worth the 20 $ LOL

-nt20

nikolatesla20
June 28th, 2002, 19:01
Well, it's finished

msModelLib.dll has TWO CRC checks in it, one gets called when you first start the program, and the other gets called whenever you try to use some of the plugins. Not all of the plugins caused it to trigger, but most of them. I removed that check as well and now everything works just fine. Well, didn't actually Remove it, I just jump over the routine that tells it to exitprocess.

Speaking of the encrypted strings, as I mentioned before they are all hardcoded into the actual eXE as code (mov byte ptr instructions). I personally can't believe someone went to that much work, but hey to each his own. By the way, the "decryption" routine is nothing more than a simple add eax,1B. It just takes the "encrypted" byte and adds 1B hex to it to get the actual byte. Not complicated, but it would keep spying eyes from just finding it in the file, as would having it hardcoded as well anyway.

I put a breakpoint after the string decryption routine to see the strings that came thru and yes right before the program starts you get string references to \\.\SICE, \\.\NTICE, and \\.\FROGSICE. I took a look at the stack ("d esp" to see where the call came from that called the decryption. The caller had the bytes right before the call obviously, which I could right down their RVA and then I just went in and edited one of the bytes to a different value to change the driver it tries to make. Goodbye SI detection for good.

I also looked at other strings that came through, such as the "<UNREGISTERED> string that gets shown on the title bar. It comes from the hardcoded bytes as well. I just found that and changed the first character to a hex 00 (NULL). Basically it's an empty string. Did the same for "EXPIRED>". No more title bar ugliness now.

The program also detects WinDasm if it's running, I patched that detection to never exit as well. ( it still detects it, but I jump over the exit routine)

There is a date check which, when you set the clock forward, run the program, and then set the date back, and run it again, comes up with a messagebox that says "Somebody set back the date blah blah blah This program is expired". Well , in the code right after this messagebox it moves a 1 into al (mov AL, 01). If you change that to move a zero it doesn't care and continues on. In fact, it seemed that by patching this one boolean it fixes that date check altogether forever.

All done and it seems to work just fine, I can import / export just fine, tested it with Half Life, Sims, Serious Sam, Rogue Spear, 3DS, OBJ, model formats and it works ok.

This program had a lot of checks in it, and he checks for all the tools we use. I must say I enjoyed working on it.

-nt20

cyberheg
June 29th, 2002, 10:54
You mentioned the mov byte ptr stuff and also noted that it would be insane to do it manually.
Without having looked at the actual program I can't say if I am correct but I am pretty sure from what it sounds that it's just local data.

Often data specified within a function becomes reinitialized every time the function is run. Then it will be put on stack and used from there. This could look like the following:

push ebp
mov ebp, esp
sub esp, <amount of bytes needed for local data>
mov byte ptr [ebp+<displacement>], 'T'
mov byte ptr [ebp+<displacement> +1], 'e'
mov byte ptr [ebp+<displacement> +2], 's'
mov byte ptr [ebp+<displacement> +3], 't'

<rest of the function>

leave
ret

So it might not even be intentionally done.

nikolatesla20
June 29th, 2002, 19:08
Good point cyberheg, I didn't even think of that. I think you are probably correct. He is probably allocating a local character array, and this is how the compiler builds it in the program.

Obviously he wouldn't be handcoding the asm instructions ! Thanks for your input

-nt20

jsteed
July 3rd, 2002, 04:28
Take a look at the serial number registration routine (00448DA0). It is a model of obsfucation. It is really a very simple substitution cipher with a modular division after that. Only the first 5 characters of the reg. number are checked. All the hash table calculations that are carried out in this routine are unnecessary!
jsteed

nikolatesla20
July 3rd, 2002, 13:59
Thanks for the information, jsteed.

Unfortunately, keygenning is not really one of my stronger suits Sometimes I just get lost in the ASM.

Also, can you tell me, if the program is keygenned, does it still check for precense of SI and WinDasm, etc?

That's a good reason to unpack it, to remove these stupid checks. Hands off my system !!!

-nt20

Attn Shareware authors:

*I reserve the right to remove your virus "protection" from my system*

jsteed
July 3rd, 2002, 15:24
Giving the program the correct registration number does not disable all the debugger/disassembler/monitor checks. It simply gets rid of the 31 day limit. IMHO removing aspr and the security checks takes much more effort than the keygen reversal, so I'm sure you can do it easily. Here are a few hints. If the name you type into the registration box is less than 20 characters then the program makes a string with the name repeated over and over again until there are at least 20 characters present. This is the loop at 00448E3B. The next loop at 00448EFC is the simple substitution cipher based on the new name string. The outer loop at 00449001 is where the modular division takes place. The inner loop is where the unecessary hash table is filled and can be ignored. The final registration number is created in the call at 00449142. This call is also full of unimportant hash table filling and other useless calculations. In fact if you look closely at the results of the modular division and the output of that call I think you will easily see the pattern. You won't even have to look around in the call at all.
The programmer took incredible pains to protect his program, but made one incredible error. After the registration number is calculated in the routine at 00448DA0, It is compared with the registration number that was entered with a simple cmp instruction. What an amazing blunder!
Try keygenning this one, it's very good practice.
jsteed

jsteed
July 3rd, 2002, 15:35
I almost forgot to ask, dose this program phone home? Looking at the RegMon output, it appears as if it trying to communicate with someone. By the way, the RegMon ooutput shows where the secret entries are for this program. They are not removed when the program is uninstalled and contain encrypted information about whether the program is correctly registered and when it was first installed.
jsteed

foxthree
July 3rd, 2002, 15:57
The best way to detect whether the app calls home would be to run the program in the presence of firewalls like ZoneAlarm/ BlackICE . They'd immediately indicate whether the application is accessing your network ... which you can conveniently deny (if you intend to).

Another way would be to see if the application has imported WinSock Calls. However the clever programmer might use GetProcAddress ... (dynamic linking).

Yet another way would be to hook WinSock calls in the target and see if they're triggered anywhere. Obviously, a graphic program like MilkShape shouldn't make any network connections... but who knows

Signed,
-- FoxThree

jsteed
July 3rd, 2002, 16:13
Thanks Foxthree.
Yes indeed, it does try to phone home to: 64.136.8.130: pop3 The protective layers in this program just know no end.
jsteed

foxthree
July 3rd, 2002, 16:48
POP3 is the old "insecure" mail protocol for downloading mails. Interesting... Why does the application intend to talk POP3. What does a traffic grab say? It might have some interesting data... like "u-know-what"

Signed,
-- FoxThree

nikolatesla20
July 3rd, 2002, 19:30
I reverse queried that IP and yes it says it's a pop server.

I have no idea why the program would do that - um, when does it do it, when you click "register", or when the program starts up?

Like I said, protections are a virus...

-nt20

*ahem* it's repackaged already *ahem* so its a little late..


jsteed
July 3rd, 2002, 22:52
The program automatically tries to phone home. It will only do so if it is or thinks it's registered. No user actions are necessary. I think it sends the file info.txt. It contains encrypted info. I will decrypt it and let you know what sort of data is sent.
jsteed

jsteed
July 4th, 2002, 01:25
The info.txt file contains the version number of the program(?), the date the file was created X2 and the registration name and registration number. The encryption routine is diiferent from that used to calculate the registration number. It can be found at 0040E530.
NT20, did you find the delayed SI check? It occurs at random times after the program has been open for about 30 sec.
jsteed

nikolatesla20
July 4th, 2002, 01:33
It shouldn't matter how often it tries to detect SI..., in my unpacked file I removed most of the detection methods. For example, I recoded the NTICE and WINICE strings to XTICE and XINICE. Therefore, meltice checks will not work, for example. Plus I patched all of the exitprocess calls that the program tries to make when it detects a debugger.

However, I did neglect to recode the FROGSICE string, but I never use FROGSICE, it sux. Crashs my win98 computer, and it doesn't work on win2k when I tried to use it before either.

I've used the unpacked version on my machine with SI naked (without using ICEDump), and it doesn't detect it, last I checked anyway....

That whole pop3 thing is a bunch of crap if you ask me. Bastards, doing stuff behind your back. That's called spyware, and they deserve to be *racked then.

-nt20

nikolatesla20
July 4th, 2002, 01:46
LOL

Oops I just thought of something - I patched the strings with an X - and if I remember Spl/\j's little guide to patching SI in win2K to not be detected he used ascii x's.

haha so if anyone followed his directions and is running SI, my version of MilkShape might still detect it...:P

oh well, little details

-nt20

disavowed
July 4th, 2002, 18:29
Quote:
Originally posted by nikolatesla20

I remember reading once that an idea for Win98 would be to simply check the autoexec.bat file for the Softice run command.



i'll take the credit for posting that
(2 or 3 years ago, probably)

ftw
August 13th, 2002, 15:57
Quote:
Originally posted by jsteed
Take a look at the serial number registration routine (00448DA0). It is a model of obsfucation. It is really a very simple substitution cipher with a modular division after that. Only the first 5 characters of the reg. number are checked. All the hash table calculations that are carried out in this routine are unnecessary!
jsteed


hmmm...
Are you sure you accomplished what you think you did?
Did you set your date ahead by 31 days? And did the
proggie still act like it was registered when you started it?

I 'fixed' Milkshape3d ver 1.5.7 quite awhile ago,
nopping 2 bytes makes it think/act like it's registered.

But after reading this thread on ms3d v1.6.0, I decided to go back and
try some other 'fixes' on my v1.5.7

I first set about making the 30 day countdown restart
without patching the proggie itself.
Accomplished that fix, found the registry values that needed to
be deleted.And found a file in the WINDOWS\SYSTEM dir, that needed
to be deleted.

Then I set out fishing for the serial.I didn't follow the code
that created the serial key, the asm was hurting my little mind.
But I could see the simple code that was comparing the 'real' serial with
my made up serial.And it did only check the first 5 characters of the serial.
Although it does also check that the length of 2nd part of serial# is 6,
and the 3rd part of the serial# is length 7.

So I input the correct code(the 5 characters created by the proggie and the rest
I made up) and the proggie acted like I registered it and thanked me.
But when I move ahead the date on my computer by 30 or more days and I
restart ms3d it comes up with a dialogbox that says something like "You seem to have registered after this proggie expired!Please run ms3d for 2 minutes...blah blah"

And I had found this on Milkshape's Bugs forum, written by the author
of the proggie(some people were complaining about getting the above dlgbox message).
QUOTE START
"Hi,

it doesn't matter, if you register before or after the trial period. The 2 minutes thing is only to confuse hackers and it seems to work, since there is no working keygen out there ;-) "
QUOTE END

So I'm thinking that the rest of the real serial# is needed and is created and
checked somewhere else in the proggie,
probably when the app starts up, I've been looking but can't find it.

So when you followed the serial# generation code did you see it create the other
parts of the serial# besides the 1st 5 characters ?

Please let me know if you did in fact get a valid serial#,
if it worked for you then I'll look more into the serial# generation code,
otherwise I'll keep looking elsewhere.

Thanks,
ftw

stealthFIGHTER
August 14th, 2002, 21:59
Milkshape 3D v1.6.3:

I've registered Milkshape (not unpacked) with fake (as author said) serial (format: xxxxx-xxxxxx-xxxxxxx). Then I've set my date month ahead and when I run the prog. bla bla message (as ftw said).

I used CreateFile breakpoint to break once the prog. reads the info.txt and came here:

Code:

0167:0044992C 8A0D52F64E00 MOV CL,[004EF652]
0167:00449932 50 PUSH EAX
0167:00449933 33C0 XOR EAX,EAX
0167:00449935 52 PUSH EDX
0167:00449936 A053F64E00 MOV AL,[004EF653]
0167:0044993B 33D2 XOR EDX,EDX
0167:0044993D 8A154DF64E00 MOV DL,[004EF64D]


You can see registers CL, AL and DL being filled with some values.
This value is '0' or '1' (probably True/False).
So I've changed values in these registers (at programs startup) to '1'.
And once I restared the program ... huh ... program is fully registered, no silly messages. I also tried to set the date ahead and it is still registered.

The last 4 values in info.txt were also been changed (by the prog.).

Regards,
sF

jsteed
August 15th, 2002, 16:02
Yes, the keygen I made worked whether I set the clock 30 days or 5 years ahead. Perhaps 1.57 is slightly different in how it uses the serial number.

SilberFuchs
September 26th, 2002, 17:55
on this prog:

i made a "CC" at normal Entrypoint, switch to Sice: bpint 3,starting the prog, but Sice is not breaking!
okay, i found the CRC in the MSMODELLIB.dll (this dll kills the execution of the .exe)

i made a "CC" on EP of MSMODELLIB.dll and when i start the exe, first Breakpoint reached is the CC in the DLL. Ok, bypass the CRC and Sice breaks the nexttime on "CC" (EP) of the EXE.

Question:
How it is possible, that the MSMODELLIB.dll is executed before the .exe??????....
in other words: when i start the exe, i expect to break with sice on Entrypoint of the EXE, not on the Entrypoint of DLL.

any idea?

ciao
SilberFuchs

foxthree
September 27th, 2002, 03:25
Hiya:

You need to look at Dll Initialization by the Windoze OS ... specifically DllInit(...)

Signed,
-- FoxThree

figugegl
September 27th, 2002, 13:57
Quote:
Originally posted by jsteed
Yes, the keygen I made worked whether I set the clock 30 days or 5 years ahead. Perhaps 1.57 is slightly different in how it uses the serial number.


are you sure of that?

i keygened the latest version of milkshape (1.6.4) and it checks ALL THREE PARTS of the serial. the first check is only there to let us think it's fully registered . after the success message it tells you to restart the program. then there is a startup nag telling us to run the proggie for at least 2 minutes. and it's within these two minutes that the serial-checking is done.

it took me so long to reverse the app that in the end i decided to ripp the entire algo, including all the unnecessary code. i've never seen anything similar before in a 20$ app. the programmer must have spent days on this protection. unbelievable! it's a pretty successful protection, as there are many nonworking cracks available for this proggie

unfortunately i didn't search this forum, it would have saved me a couple of hours. i already wrote a (german) paper on how to make a working dump and i'm thinking of writing another one to explain all the different anti-xxyy tricks.

jsteed
September 27th, 2002, 16:47
figugegl,
Yes, I'm sure. Setting the clock ahead had no adverse effect. Also, I never saw the nag message that says wait 2 minutes. I removed the program from my computer long ago, but the version I looked at was 1.60. I agree that the efforts the programmer took to protect his software were incredible. He must be a very paranoid individual. It sounds as if his protection scheme is very much a work in progress. If I have time this weekend, I will take a look at version 1.64. I assume I can download a trial version. From your investigations, can you determine if the only added protection is the additional serial check?
By the way what happens after the 2 minutes expire?

jsteed

figugegl
September 27th, 2002, 20:57
jsteed:
i haven't cracked other versions than 1.6.4. i found a tut from an older version (1.5.x if i remember correctly) and it was a simple three-byte patch. must have been one of those non-working releases

some of the nice tricks the app uses (as already mentioned in this thread):

* meltice
* checks "winice.exe" in autoexec.bat
* checks uninstall string in registry
* fake strings in exe
* crypted strings (lame algo though)
* frogsice, w32dasm detection
* regmon, filemon detection - but i didn't find the strings in the exe, only in memory. i've patched my filemon/regmon anyway, so i don't care

to detect the crypted strings, i wrote a little proggie that scanned the entire exe.

when registering, the app reads the serial and checks the first part. if ok it encrypts name, serial, installdate and some more infos and stores a string in the registry (3 times), in a txt-file and appended at the end of a dll. for unregistering the app you have to delete all of them.

after restarting the programm there's this nag telling us to run the program for at least 2 minutes. after maybe 20 seconds the first part of the serial is checked, 20 seconds later the second part, then the third part and finally the format of our name.

the main problem is to find these checks. the algo for the two remaining parts is trivial. the first part is very long, i haven't reversed it properly. but it might as well be similar to the other two in the end. i was too tired to do more reversing, and i ripped the entire code.

if all is ok you are allowed to save and export you work. otherwise the proggie complains, but only after the trial period has ended. when starting the program, it always asks for the two minutes. when properly registered, this is not the case anymore.

i haven't seen any crc-check, my dump (size = 1164 kb) runs fine. the only thing i did was to patch the annoying sice-checks. but that's not even necessary when icedump is running! a messagebox appears ("there's a problem with your system debugger, please read the faq! closing...", we simply ignore that and DON'T close the messagebox. the program works fine anyway

jsteed
September 27th, 2002, 23:06
figugegl,
Yes, those checks are all in version 1.60. However, I'm surprised you were able to patch the program and run it. The CRC check is in a dll named MsModLib.dll. A bpx PostQuitMessage allows you to find the routine that needs to be patched to bypass this check. If you are patching the program in memory, I guess you will never have to bother with this check.
I'll download the program this weekend and have a look at the new serial checks.

jsteed

jsteed
October 2nd, 2002, 04:42
I took a look at version 1.64. The blunder of having the 1st part of the serial in plain view is repeated for the other two! Nothing like consistancy.

Here's how to find the serial and make a key gen. First I found the piece of code that makes the first part of the serial. It is at 0044CFA0.
* Referenced by a CALL at Addresses:
|:004040CA , :0040CC55
|
:0044CFA0 6AFF push FFFFFFFF
:0044CFA2 64A100000000 mov eax, dword ptr fs:[00000000]
:0044CFA8 680B0A4900 push 00490A0B
:0044CFAD 50 push eax
:0044CFAE B818100000 mov eax, 00001018

Notice that there are 2 calls to this function. The first is to check the serial you enter via the About box. The comparison between the 1st 5 characters of the real serial and the one we enter is done at:
:004040E0 8A17 mov dl, byte ptr [edi] ;real serial
:004040E2 8ACA mov cl, dl
:004040E4 3A10 cmp dl, byte ptr [eax] ;our serial
:004040E6 751C jne 00404104
:004040E8 84C9 test cl, cl
:004040EA 7414 je 00404100
:004040EC 8A5701 mov dl, byte ptr [edi+01]
:004040EF 8ACA mov cl, dl
:004040F1 3A5001 cmp dl, byte ptr [eax+01]
:004040F4 750E jne 00404104
:004040F6 83C702 add edi, 00000002
:004040F9 83C002 add eax, 00000002
:004040FC 84C9 test cl, cl
:004040FE 75E0 jne 004040E0

The second call at 0040CC55 is used to check the serial after 30 days. Enter a serial with the 1st 5 real characters. Set the clock ahead by one month and start the program again. We see the "wait two minutes.." message. Set a bpx on 0040CC55. After about 20 sec, SI breaks so we know we are in the delayed checking routine. The actual check is done at 0040CC94. Now we need to find where the other two pieces of the serial are checked.
Looking at the disassembly of the code around 0040CC94, we find that at the same serial checking code at 0040CD86, (2nd part), and at 0040CE38, (3rd part). The code to create these parts are in the calls just above the checks. They use nearly the algorithm as the 1st part but do not contain the obsfucation code.
There is a delay of about 20 sec between each check.

A note for all the Asprotect afficienados, (version 1.2). I could not use Imprec or Revirgin to rebuild the IAT. I had to do it manually. Imprec gave me an error saying that there was not enough space to add a new section. The dump is 53 meg. Is this a limitation of Imprec, or am I doing something wrong here? I had no problem using Imprec with version 1.60, (52 meg). Revirgin would add a new section but it was corrupted and did not properly point to the correct addresses. Once again, is this a size limitation or another dumb mistake on my part?

All in all, this is a fun target. The author has really gone the extra mile to protect his program, but even so, his mistakes make it fairly easy to reverse. In addition to the serial in plain view, there is also a simple 2 byte patch to bypass the serial check.

Cheers, jsteed

Stone()
October 2nd, 2002, 10:49
No no error of Imprec or RV, add with a Hexeditor 1000h bytes of zero's to the last section and Imprec will write the Import table.

Don't forget to adjust then the gneral Image size afterwards with LordPe.

Dump 53 Mb? Yes, but I would save each section to disk then cut all the 0's from the 3rd section, then it will shrink to 368 Kbs, glue everything together, realign, add the 1000h bytes to last section, uncheck 'add to last section' enter the RVA (VOffset of last section) for the Import table and it should work.

jsteed
October 2nd, 2002, 17:02
Thanks Stone().
The 0 bytes are just what was needed. First I realigned the file with LordPE. That reduced the size to a respectable 1.1 meg. Then I added 2k of 0 bytes -- it's a large IAT. Now Imprec has no problem adding the IAT.

jsteed