+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?