+HCU 1997, Project2: Winice cracking
Phase 4

Phase 4

SoftIce 3.01 cracking again, NTIce this time...

         (How EXE checksums work)



------------------------------------------------



When I found Project 2 on Fravia, I said to myself: Great, let's try 

it. But then I thought: I have the full version of SoftIce 3.01 for 

Windows 95 already, so why should I crack the trial version? 

Let's crack the demo of SoftIce 3.01 for Windows NT instead.



As I expected, everything was exactly the same. The only tool I needed 

was HIEW (which is really a great thing, I hope you all know it). 

I took the Project 2 page and searched for the pieces of code described 

there. Within a few minutes the crack of Loader32 was done.



At the time ofd my session only the first part of Project 2 was available, 

so I had to do all the rest by myself. I disassembled the NTICE.SYS (which 

is the NT version of WINICE.EXE) and looked for the substring "time", 

following +ORC's advice in his lesson 4.2. 

I found 2 imported functions: RtlTimeToTimeFields and KeQuerySystemTime. 

The second function looked pretty interesting. Wow! Only one occurence 

in the whole file. A few lines below KeQuerySystemTime I found the call to 

a routine VERY similar to NmGetNumDaysLeft. Well, you know all this from 

+Rcg's essay. So I simply changed the end of the check and thought that 

everything was done. 



But when I tried to start the NTIce, the only result was an error 

messagebox:



System Process - Unable to Load Device Drivers

\SystemRoot\System32\DRIVERS\NTice.sys device driver could not be 

loaded. Error Status was 0xc0000221.



What's this? Does our target hyde some checksum protection inside?



I tried to change some stupid byte inside the string "This program 

cannot be run in DOS mode", in the file header. The result was exactly the 

same - again this nasty message: checksum protection!



OK. I wanted to know where the checksum was counted and checked. 

So I loaded the original (unaltered) version of NTIce - to be able to trace

it, I renamed the "cracked" NTICE.SYS to PNPISA.SYS and tried to fire 

it. Again the same message.



Whenever I started up my version of NTIce (called PNPISA now), my 

computer seemed to do something for a few tenths of second (I have a  

P100). 

So I started it again and pressed CTRL+D immediately afterwards, 

"manually" trying to fish the scheme.

I landed in a piece of code that really looked like some kind of checksum 

counting. I followed... after a while I got here: 



0008:80178A0E  CALL   80187400

0008:80178A13  TEST   AL,AL	

0008:80178A15  JNZ    80178A29

0008:80178A17  JMP    80178A22

0008:80178A19  MOV    EAX,000000001

0008:80178A1E  RET

0008:80178A1F  MOV    ESP,[EBP-18]

0008:80178A22  MOV    DWORD PTR [EBP-1C],C0000221; 



STATUS_IMAGE_CHECKSUM_MISMATCH



0008:80178A29  MOV    DWORD PTR [EBP-04],FFFFFFFF

0008:80178A30  PUSH   DWORD PTR [EBP-24]

0008:80178A33  PUSH   FF

0008:80178A35  CALL   80178AAA

 ...



Where are we? Hey, look! We're not in NTIce, but in 

NTOSKRNL.EXE. So it's not a Numega's protection anymore, 

it's Microsoft's own protection! Interesting.



I run HIEW a looked at NTICE.SYS header description 

- there is a checksum there. I wrote down its value and 

traced inside the checking call (the one at 80178A0E).



I found CMP EAX,EDX at the end of the function. 

The value of EDX was exactly the same as the checksum 

reported by HIEW. That means that EAX must contain the 

REAL checksum. I wrote this value into my NTIce/PNPISA 

header, fired it - and it worked!!! 

So I rebooted -  NTIce was cracked! :-)



Later I searched the Internet for some EXE file description 

-I wanted to know if I had traced the NT kernel just to 

find something everybody knows already. 

I found quite comprehensive PE EXE description at 

http://www.microsoft.com/win32dev/base/pefile.htm.



Let's take a look at it: description of EXE header, PE signature, PE 

header, PE Optional Header - here it is!

  ...

    ULONG   CheckSum;

  ...



Where's its description? Ah, here:

 ...

CheckSum.

A checksum value is used to validate the executable file at load time. 

The value is set and verified by the linker. The algorithm used for 

creating these checksum values is proprietary information and will not be 

published.

 ...



Do you love Microsoft as much as I do?



A pretty scary world... let's take a better look at the algorithm. 

Here's the code from NTOSKRNL.

(Sorry it's written by hand, but I could not disassemble it, because 

WDASM8 crashes down before it reaches this piece of code and 

WDASM7 simply stops around the same position :-(



; this is just a subroutine, the main entry point is a little below...

; ----------------------------------------------------------------------



873C2:  push ebp

        mov edx,[esp+10]           ; number of word components in file

        mov ebp,esp

        mov eax,edx

        push esi

        dec edx

        mov ecx,[ebp+8]            ; always 0

        test eax,eax

        je 873F3

        mov esi,[ebp+0C]           ; buffer address

873D7:  movzx eax,[word ptr esi]   ; LOOP beginning

        add ecx,eax

        add esi,2

        mov eax,ecx                ; in this loop

        and ecx,0ffff              ; the checksum is done

        shr eax,10

        add ecx,eax

        mov eax,edx

        dec edx

        test eax,eax

        jne 873D7                  ; LOOP end



873F3:  mov eax,ecx

        pop esi

        shr eax,10

        pop ebp

        add ax,cx

        retn 0c



;  



You are deep inside fravia's page of reverse engineering, 

choose your way out:






 homepage 

 links 





 anonymity 



 +ORC



 students' essays





 tools

 cocktails




 antismut CGI-tricks





 search_forms



 mailFraVia




 Is software reverse engineering legal?