I hope everyone gets the old reference

OK, I put my foot into it. Big Time. Everyone seemed to be having so much fun with Merak Mail I decided to get into the fray. And I got frayed.

SICE detection - simple MeltIce protection

CRC check - break on CreateFileA/ReadFile. Seems to read in config.exe in 2 parts. A few calls after the 2nd Read is a CMP. Change it and you're (apparently) free to go. Interestingly there's a check if the file NAME is changed and you get the same CRC error message. This is understandable because config.exe is called by a Control Panel extension anyway and it needs to find it.

Somewhere in there I tried accessing my registry to take a look at HKLM\Software\Microsoft\Windows\CurrentVersion
(the program uses this value in it's reg check), and lo and behold I get a message saying that "Registry Editing has been disabled by your Administrator"

Oh, Oh. Now I'M the Administrator and I'd never do that to myself. So I had my suspicions and checked wininit.ini before rebooting to make sure the program wasn't going to start deleting things on startup and it looked OK.

What the heck, maybe it's a glitch I thought, I mean, this IS Windows. Reboot and I get a very polite Message Box saying "Warning you have tried a cracked program on this computer. The software people have been notified by this..."

Well, that's bull, BUT, suddenly Ping.exe appeared in my C:\ directory. Now the message won't go away and I still can't access my registry with regedit. Other files (regclean, etc.) CAN access my registry however, but TweakUI is also disabled.

Why don't you restore your registry you say? I'd love to, but my default backups seemed to have disappeared... And unfortunately I cleaned house recently of OTHER backups before defragging and never got around to making new backups.

I don't know WHERE this nasty message box may be coming from. Startup Manager (which checks Run/RunOnce/RunServices etc) doesn't show anything. StartMenu/Startup doesn't show anything. SoftIce however (oh beloved SI) shows that the Message Box (which appears just before the Icons on your Desktop appear) is created by Mprexe.exe, a standard Win98 task that always seems to be running. So I assume some little registry snippet is calling mprexe.exe and giving it that string, or maybe the string is stored elsewhere in a file. A fresh bootlog.txt doesn't show anything untowards that I can see. Bootup in SafeMode is OK - no message.

I'm just about to d/l one of those programs that allows you to change Administrator settings in Windows and hope it reverses the registry editing disabling. If it does, then I need to wipe out what's calling that Message Box.

Anyway, this is a warning to anyone who wants to "just have a little fun" with this program. I'm not complaining, I deserve it (beat me, whip me, I love it ;p and if worse comes to worse it's about time for a complete housecleaning anyway.

But if anyone has any suggestions...

BTW, I did get the program to say "Thanks for Registering", but this was only the Message Box call.

Kayaker >(

Whew! Back in business. I d/l a great little freeware program called Key 2000 which allows you to disable all system restrictions. Just happens to be by a guy called Goh Kayak (gotta love it

As it turns out the Message Box was being generated from:

[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Winlogon]
"DontDisplayLastUserName"="0"
"LegalNoticeCaption"="Illegal software installed on this computer."
"LegalNoticeText"="Warning! You have tried a cracked program on this computer... The software people have been notified by this..."

And the restriction on Regedit from:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\System]
"DisableRegistryTools"=dword:00000000
"NoDispCPL"=dword:00000000
"NoDispBackgroundPage"=dword:00000000
"NoDispScrSavPage"=dword:00000000
"NoDispAppearancePage"=dword:00000000
"NoDispSettingsPage"=dword:00000000
"NoSecCPL"=dword:00000000
"NoPwdPage"=dword:00000000
"NoAdminPage"=dword:00000000
"NoProfilePage"=dword:00000000
"NoDevMgrPage"=dword:00000000
"NoConfigPage"=dword:00000000
"NoFileSysPage"=dword:00000000
"NoVirtMemPage"=dword:00000000


Well, that was a nice little lesson in Policy settings and a new location for things starting up on logon. Kudos to Merak Mail.

If I was smart I'd leave well enough alone now...

Yah, Right. Heheh

Kayaker

Kayaker my friend that was pretty cool
Merak Mail people were actually thinking when they wrote this program, well I'm glad you got evertyhing to work now. I'm hoping this little setback will make you want to rape this program even more

good luck
goatass

Regedit is easily fooled. Hexedit the program and you'll find that policy key it checks.. disableregistrytools or whatever it is. Just change the name of the key it checks In fact, anywhere that you don't have the admin rights.......

Hi Kayaker,
Sounds like key 2000 might be useful, appreciate a url for it.
regards
hz

goatass - You can be assured Sir, that this personal affront, this violation, shall not be forgotten. The gauntlet has been dropped. Ze Duel, she begin at Dawn...

hz et al - You can get Key 2000 at www.softseek.com under Utilities/System (2nd page I think)

cronos - Oh the String/Registry references are definitely there in a hex editor. The 1st thing I want to do is see if the "problem" was caused by the initial CRC check, or if there's a 2nd "quiet" one around that caused the problem.

I figure I'll do a Trace between 004753F1 AFTER doing a fresh patch to bypass the CRC check so it's not triggered even once, and a BPX RegOpenKeyExA. If a Key is opened and is either of
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Winlogon]
or
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\System]
"DisableRegistryTools"=dword:00000000

and something nasty is being written into them, I'll assume there's a 2nd check somewhere in that Trace.

There's also an interesting Flag set at 00475404 if the check is bad that I'd like to know what its function is. I'd take a guess and say that if the Flag was set to 00, the registry entries might not be written even if the CRC check failed (could be wrong though).


Here's the relevant code:

SoftIce Check ('MeltIce' protection documented in FrogsIce):
:0049758C FF92B4000000 call dword ptr [edx+000000B4] ; \\.\SICE check
:00497592 84C0 test al, al ; I changed this to 32C0 xor al,al
:00497594 740F je 004975A5
\\.\NTICE check follows

CRC Check (break on CreateFileA/ReadFile):
:004753D4 E8EBFDFFFF call 004751C4 ; looks like it could be the checksum for config.exe (lots of ROL ROR SHL SHR in a big loop)
:004753D9 8BF0 mov ESI, eax ; need to confirm ESI contains the value used in the later CMP
:004753DB 8D55F8 lea edx, dword ptr [ebp-08]
:004753DE 33C0 xor eax, eax
:004753E0 E8F7D5F8FF call 004029DC ; call to GetModuleFileNameA (!)
:004753E5 8B55F8 mov edx, dword ptr [ebp-08]
:004753E8 8BC3 mov eax, ebx
:004753EA E815FDFFFF call 00475104 ; calculate correct checksum

EAX=4F355C1E (correct checksum) ESI=4C3F1C50 (SICE-patch checksum)

:004753EF 3BF0 CMP ESI, EAX
:004753F1 7415 je 00475408 ; change to EB15 jmp 475408
:004753F3 66837B2A00 cmp word ptr [ebx+2A], 0000 ; ?
:004753F8 740A je 00475404
:004753FA 33C9 xor ecx, ecx
:004753FC 8BD3 mov edx, ebx
:004753FE 8B432C mov eax, dword ptr [ebx+2C]
:00475401 FF5328 call [ebx+28] ; CRC Nag

* Referenced by a (U)nconditional or (C)onditional Jump at Address:
|:004753F8(C)
|
:00475404 C6434401 mov [ebx+44], 01 ; Flag used for??

* Referenced by a (U)nconditional or (C)onditional Jump at Address:
|:004753F1(C)
|
:00475408 33C0 xor eax, eax ; passed CRC check
:0047540A 5A pop edx
:0047540B 59 pop ecx
:0047540C 59 pop ecx
:0047540D 648910 mov dword ptr fs:[eax], edx
:00475410 682A544700 push 0047542A

* Referenced by a (U)nconditional or (C)onditional Jump at Address:
|:00475428(U)
|
:00475415 8D45F8 lea eax, dword ptr [ebp-08]
:00475418 BA02000000 mov edx, 00000002
:0047541D E8F6E8F8FF call 00403D18
:00475422 C3 ret

The fun continues...

Kayaker

Hi Kayaker,
EAX=4F355C1E (correct checksum) ESI=4C3F1C50 (SICE-patch checksum)

How to calculate this checksum ,I'm stupid
hehe.
I just found that after deleting settings.cfg
it returns to 30 days.the reference key is
your windows registered key with just a
C-Pro !

Y'know, this 4098 character limit for posts is real annoying, especially with all the code we tend to generate...

Hi Esther,

I played around with it a bit tonight and found a few things out about the checksum routine. Here's the start of the routine I mentioned in my last post:

:004753D4 CALL 004751C4 ; calculate checksum of config.exe
:004753D9 MOV ESI,EAX ; checksum returned
:004753DB LEA EDX,[EBP-08]
:004753DE XOR EAX,EAX
:004753E0 CALL 004029DC ; GetModuleFileNameA (config.exe)
:004753E5 MOV EDX,[EBP-08]
:004753E8 MOV EAX,EBX
:004753EA CALL 00475104 ; retrieve hard-coded checksum
:004753EF CMP ESI,EAX ; cmp the two
:004753F1 JZ 00475408 ; Oh, Oh, you're a bad boy!

If you set a BP at 004753D4 and then set a
BPX CreateFileA do "dd esp->4"
as you F10 over it, SI will break and display the path of the file 'config.exe' in the data window.
Then if you set and break on
BPX ReadFile and display the stack with "dd SS:ESP"
(it's actually ESP before the call but ESP+4 if you've already broken into the call, and the "SS:" isn't really needed)

:0076FA9C 00000020 014D0004 0012CA00 0076FAB0
:0076FAAC 00000000

you see the 5 DWORDS corresponding to the ReadFile parameters being PUSHed

BOOL ReadFile(

HANDLE hFile, // handle of file to read
LPVOID lpBuffer, // address of buffer that receives data
DWORD nNumberOfBytesToRead, // number of bytes to read
LPDWORD lpNumberOfBytesRead, // address of number of bytes read
LPOVERLAPPED lpOverlapped // address of structure for data
);

If you display 014D0004 (address of buffer that receives data) in the Data window, you'll see the file being read in. 0012CA00 (number of bytes to read ) is the size of the full exe file, and after returning from the Call, 0076FAB0 will show that 0012CA00 bytes were indeed read in.

Now, if you trace a bit after returning from ReadFile, you reach the heart of the checksum routine. I've shown the registers before and after the loop. As this is an untouched file, the final checksum shown in ESI is the "true" checksum.

EAX=00000000 EBX=00000000 ECX=00000000 EDX=0004B280 ESI=0012CA00
EDI=0012CA04 EBP=0076FC40 ESP=0076FAC8 EIP=004752A7

:004752A7 MOV EAX,ECX
:004752A9 SHL EAX,02
:004752AC ADD EAX,[EBP-10] ; [ebp-10] = 014D0004
:004752AF MOV EAX,[EAX]
:004752B1 CMP EBX,00000158 ; skips over 4 bytes at 158h in the file - why? - this is the hard coded checksum
:004752B7 JZ 004752DA
:004752B9 MOV [EBP-04],EAX
:004752BC ROR DWORD PTR [EBP-04],0A
:004752C0 SHR DWORD PTR [EBP-04],03
:004752C4 ROL DWORD PTR [EBP-04],07
:004752C8 XOR [EBP-04],EAX
:004752CB MOV ESI,[EBP-0C]
:004752CE XOR ESI,[EBP-04]
:004752D1 ADD ESI,[EBP-14]
:004752D4 MOV [EBP-0C],ESI
:004752D7 MOV [EBP-14],EAX
:004752DA ADD EBX,04
:004752DD INC ECX ; final value is 4B280
:004752DE DEC EDX ; initial value is 4B280
:004752DF JNZ 004752A7

EAX=014D0004 EBX=0012CA00 ECX=0004B280 EDX=00000000 ESI=4F355C1E
EDI=0012CA04 EBP=0076FC40 ESP=0076FAC8 EIP=004752E4

...and on to Part deux...

So what's happening here is that every 4 bytes in the entire file undergoes the ROR SHR ROL etc. routine and the cumulative checksum is stored in ESI. 4 bytes at 158h in the file is skipped because this contains the hard-coded checksum value (1E5C354F). 4B280 times through the loop at 4 bytes apiece = 12CA00 = size of file.


You can monitor the reading of the hard-coded checksum value at 004753EA by setting breakpoints on SetFilePointer and then ReadFile. The ReadFile function reads data from a file, starting at the position indicated by the file pointer.

Display the SetFilePointer stack with "dd SS:ESP"

:0076FACC 00000020 00000158 00000000 00000000

and you see stack param. 2 specifies the number of bytes to move the file pointer (158) and
stack param. 4, which is the starting point for the file pointer move, is set to the beginning of the file.

DWORD SetFilePointer(

HANDLE hFile, // handle of file
LONG lDistanceToMove, // number of bytes to move file pointer
PLONG lpDistanceToMoveHigh, // address of high-order word of distance to move
DWORD dwMoveMethod // how to move
);

Doing the same at the ReadFile break shows that 4 bytes are to be read in beginning at 158h, which lo and behold is 1E5C354F.

Now I don't know what checksum algorithm this routine corresponds to. I generated checksums on the file (sans those 4 bytes) using Hex Workshop and the value doesn't match any of the standard ones built into HW.

So all this brings up an interesting twist on a keygen. You could code a keygen which would read the file after you've made all your patches and generate a new checksum using the program's routine, which you could then insert at 158h.

There's a file at h*tp://www.createwindow.com called CRCtext.exe which generates a (0's compliment I think) CRC32 checksum of a file and source code is available. It might be a fun little project.

Cheers,

Kayaker

Hi Kayaker,

Thanks for the input,I er hm slow learner hehhe
must put more time understand this CRC checks...
Please don't use force,she'll screamm d:P

cheers
with respect
esther

Hi Kayaker,
>There's lots of info on CRC/checksum stuff, >but here's a nice, gentle doc called
>A PAINLESS GUIDE TO CRC ERROR DETECTION >ALGORITHMS guaranteed not to make you scream
>http://www.repairfaq.org/filipg/LINK/F_crc_v>3.html

Hey not me her I did'nt even rip her clothes off,you did
thanks for the url REEEEl GOOODDD

>Anarchriz did a tut on CRC and how to >Reverse it if you're feeling masochistic, I >haven't even TRIED to digest it! I think >I've also seen an ASM representation of a >true CRC-32 check by some reversing guru >somewhere or another.

Hard to understand hehe,I have read it.
should read the doc you recommmend.
I found the CRC-32.txt in ftp site
the url is in Anarchriz's tut
Great thanks again
Busy like hell in real life hehhe
maybe laterzzzzz
best regards
esther