Lesson8.1
--------------------------------------------------------
SPECIAL NOTE: Please excuse the somehow "unshaven"
character of the windows lessons... I'm cracking the
newest Windows '95 applications right now, therefore
at times I had to add "on the fly" some corrections to
the older Windows 3.1 and Windows NT findings.
"homines, dum docent, discunt".
---------------------------------------------------------
-> 1st THING TO REMEMBER
The NE format does give every windows executable the equivalent
of a debug symbol table: A CRACKER BLISS!
-> UNDOCUMENTED DEBUGGING
One of the many feature of Windows based on undocumented
foundations is the "ability to debug".
A word about undocumented functions in the MS-Operating Systems:
Microsoft manipulates its rule and domination of the operating
systems in use to day (MS-DOS, Windows, Windows '95) with two
main wicked aims:
1) getting the concurrence completely bankrupt (that's the
scope of all the using of undocumented functions and
CHANGING them as soon as the concurrence uses them). The
battle against Borland was fought in this way.
2) getting all future "programmers" to use windows as a "black
box" that only Microsoft engineers (if ever) can master, so
that everybody will have to sip the ill-cooked abominations
from Microsoft without ever having a chance to alter or
ameliorate them.
Strange as it may seem, only the sublime cracker community fights
against these intolerable plans. All stupid governments and
lobbies -on the contrary- hide behind the fig-leaf of the
"market" "freedom" in order to ALLOW such heinous developments
(I'm speaking as if they were capable to opposing them even if
they wanted, which they do not. Be assured, they couldn't anyway,
"Governments" are deliberately MADE to serve Gates and all the
remaining suckers, and lobbies are the shield of feudalism. You
can forget "democracy", the only rule existing is a malevolent
oligarchy based on money, personal connections, defect of
culture, lack of knowledge and dictatorship of bad taste through
television in order to keep the slaves tamed... enough now...)
The windows situation is particularly reminiscent of the older
situation in DOS, where for years the key "load but don't
execute" function, used by debuggers, such as [DEBUG], [SYMDEB]
and [CODEVIEW], was "reserved" by Microsoft.
The windows debugging library, WINDEBUG.DLL, a number of
undocumented functions and even the interface it provides are
undocumented! The WinDebug() function is used by all available
windows debuggers, including [CVW] (CodeView for Windows), [TDW]
(TurboDebugger for Windows), [Multiscope] and [Quick C for
Windows] (the last two are GUI, not text debuggers. The use of
WinDebug() doesn't show up in MAPWIN output 'coz debuggers link
to it at run-time via the amazing GetProcAddress() function.
WinDebug() is a hacked 32-bit version, for the old Windows
3.0, of the poorly documented DOSPTrace() function from OS/2 1.x
(study these older Operating Systems! Studying the past you'll
understand EVERYTHING! Sometime I think that the only way to hack
and crack correctly is to be more a software historian than a
programmer... fac sapias et liber eris!). DOSPTrace is, in turn,
based on the ptrace() function in Unix.
Like DosPTrace(), WinDebug() takes commands such as Go,
Single-Step, Write&Read Registers, Write&Read Memory. It returns
to its caller either when the command completes or when a
breakpoint occurs (or a DLL load). These commands and
notifications appear in a large structure whose address is passed
in WinDebug().
WinDebug() was renamed CVWIN.DLL (and TDWIN.DLL) for Windows
3.1., all crackers should study it and get the maximum possible
documentation about it. As you will see in the following, it is
worth to study also TOOLHELP.DLL (what Microsoft would like you
to fiddle with) and INT_41h (the real debugging interface).
Interrupt handling under Windows
Interrupt handling under Windows can be tricky: you need to
use Toolhelp (a rather scaring lobotomy for your programs) or to
have special code for Standard vs. Enhanced modes, because the
information on the stack of an interrupt or exception handler
differs between the two windows modes. In addition, some handlers
would be installed using INT_21h, while others are set up using
DPMI services. Toolhelp has quite a bit of internal code that
"cooks" the interrupts and sends them to you in an easily
digestible form.
Remember that Windows uses GP faults as a "hacker" method
of doing ring transitions that are not allowed with legal 80x86
instructions: the virtual memory system of Enhanced mode is
implemented via the page fault.
Some tools for cracking windows (-> see lesson 9)
----------------- DEBUGGERS
CVW and TDW (you have to know the function's
segment:offset address beforehand in order
to crack a function)
WCB [Windows Codeback] by Leslie Pusztai (it's
a really cool tool!)
WDEB386 Microsoft's WDEB386 (clumsy, and requires a
second monitor)
Soft-Ice/Windows best (BY FAR!) windows debugger! NuMega is
so good I am at times really sorry to crack
their products! [WINICE] is the single,
absolutely essential debugger and snooping
utility for windows crackers. Get it!
----------------- POST MORTEM INSPECTORS
CORONER, etc. (a lot of shareware)
MS-DrWatson Old and clumsy
Borland's Winspector THE BEST! It has the BUILDSYM utility
that allows the creation of a debug
.SYM file from an .EXE without debug
information.
----------------- INSPECTORS
MS-Spy Old
Borland's WinSight (Best one, select "Other")
MicroQuill's Windows DeMystifiers (from Jeff Richter):
VOYEUR (hold SHIFT picking Message Selection), COLONEL,
MECHANIC and ECOLOGIST
----------------- SNOOPERS
[INFSPY.EXE], 231.424 bytes, version 2.05 28/8/1994 by Dean
Software Design, may be the more complete one.
[SUPERSPY.EXE], 24.576 bytes, 10,6,1994, quite handy for quick
informations.
[WINVIEW.EXE], 30.832 bytes, Version 3.00 by Scott McCraw, MS(c)
1990-1992, this is the old MS-Spy, distributed by MS
[TPWSPY.EXE], 9.472 bytes, quite primitive, but you get the
pascal source code with it.
-> INSIDE A WINDOWS '95 DEBUGGER
You can debug a program at the assembly-language level
without any debugging information. The DOS [DEBUG] program does
that, allowing breakpoints and single-stepping, all of which
implies that the hardware must be cooperating. Back in the time
of the 4-MHz Z-80s, you used a debugger that plugged interrupt
op codes into the instruction stream to generate breakpoints.
Nothing has changed. That's how you debug a program on a
80586 (=Pentium). The x86 architecture includes software
interrupts. The 1-byte op code xCC is the INT_03 instruction,
reserved for debuggers. You can put the INT_03 op code in place
of the program instruction op code where the break is to occur
and replace the original op code at the time of the interrupt.
In the 80386 and later, you can set a register flag that tells
the processor to generate a not-intrusive INT_01 instruction for
every machine instruction executed. That device supports single
stepping.
The Win32SDK (Windows '95 software developer's kit) includes
functions that allow one program to launch another program and
debug it. The SDK's debug API takes care of how the interrupts
and interrupt vectors get managed. The logical consequence of
such an approach is that fewer and fewer people will be able to
know what's going on inside an application. The bulk of the
programmers -in few years time- will not be able any more to
reverse engineer an application, unless the few that will still
understand assembler-language do offer them the tools to do it.
Microsoft -it is evident- would like the programmers to use a
"black box" approach to programming, writing nice little "hallo
world" application and leaving to the engineers in Microsoft
alone the capacity to push forward (and sell) real programs that
are not toy application.
The Win32 documentation seems vast, almost luxurious, until
you begin serious work and you discover its shortcomings, like
the fact that extended error codes are not documented, and
numerous APIs are documented either incorrectly or so poorly that
you must burn precious time testing them. What we definitely need
is to find some secret fellows inside Microsoft (like good old
Prometeus) that smuggles to the outside the real documentation
that the Microsoft engineers have reserved for themselves. If you
are reading this and do work for Microsoft, consider the
possibility of double-crossing your masters for the sake of
humanity and smuggle us the secret information.
In windows '95 a debugger program launches a program to be
debugged by calling the _CreateProcess function, specifying in
an argument that the program is to be debugged. Then the debugger
program enters a loop to run the program. At the top of the loop
the debugger calls _WaitForDebugEvent.
Each time _WaitForDebugEvent returns it sets indicators that
tell about the vent that suspended the program being debugged.
This is where the debugger traps breakpoints and single-step
exceptions. _WaitForDebugEvent fills in an event structure that
contains among other things the address that was interrupted end
the event that caused the interrupt.
The debugger calls _GetThreadContext to get the running
context of the debugged program, including the contents of the
registers. The debugger can, as the result of cracker
interaction, modify these values and the contents of the debugged
program's memory.
The debugger sets breakpoints by saving the op code at the
instruction to be intercepted and putting the INT_03 op code at
its place, it's always the same old marmalade. When the
breakpoint occurs, the debugger replaces the original op code in
the program's instruction memory, and decrements the interrupted
program counter in the saved context so that execution resumes
at the instruction that was broken.
To single-step a program, the debugger sets a bit in the
context's flags register that tells the processor to generate an
INT_01 for every instruction cycle. When that interrupt occurs,
the debugger checks to see if the interrupted address is at a new
source-code line number. If not, the debugger continues
execution. Otherwise, the debugger displays the new line in the
IDE and waits for the cracker to take an action that resumes the
program.
While the debugged program is suspended, the debugger
interacts with the cracker and provides full access to the
debugged program's context and memory. This access permits the
cracker to examine and modify part of the code.
To resume the debugged program, the debugger resets the
program's context by calling _SetThreadContext and calls
_ContinueDebugEvent. Then, the debugger returns to the top of the
loop to call _WaitForDebugEvent again.
To extract debug information from a Win32 executable file,
you must understand the format of that file (best thing to do,
to practice yourself, would be to reverse engineer small
programs). The executable file has two sections not found in
other executable files: ".stab" and ".stabstr". How nice
that
they used names that suggest their purpose (nomen est omen).
You'll find them inside a table of fixed-length entries that
include entries for .text, .bss, .data and .idata. Inside these
sections the compilers put different parts of a program.
There are several different formats for encoding debug
information in an executable file. Borland's Turbo Debugger one
format. Microsoft's CodeView another. The gnu-win32 port from
Cygnus the stab format, an acronym meaning "symbol table",
although the table contains much more than just symbol
information.
The .stab section in a portable executable file is a table
of fixed-length entries that represent debugging information in
the stab format. The .stabstr section contains variable-length,
null terminated strings into which the .stab table entries point.
The documentation for the stab format is available in text
format on the Cygnus ftp site (ftp.cygnus.com//pub/gnu-win32).
Stabs contain, in a most cryptic format, the names and
characteristics of all intrinsic and user-defined types, the
memory address of every symbol in external memory and on the
stack, the program counter address of every function, the program
counter address where every brace-surrounded statement block
starts and ends, the memory address of line numbers within
source-code files, and anything else that a debugger needs. The
format is complex and cryptic because it is intended to support
any source-code language. It is the responsibility of a debugger
program to translate the stab entries into something meaningful
to the debugger in the language being debugged.
Windows '95 invokes dozens of INT_21 services from 32-bit
code, including KERNEL32.DLL and possess Krn32Mutex, which
apparently controls access to certain parts of the kernel. Some
of the functions in KERNEL32 can be blocked by the Win16Mutex,
even though Microsoft says this isn't the case.
SO, I WANNA CRACK, WHAT SHOULD I DO?
I'll show you a simple windows crack, so easy it can be done
without WINICE: let's take [WINPGP4.1.] (front-end for PGPing in
windows, by Geib - I must thank "Q" for the idea to work on this
crack).
Using WCB you'll find out quickly that the "CONGRATULATIONS
your registration number is OK" and the "SORRY, your registration
number is not correct" data blocks are at the block starting at
36.38B8 (respectively at 36.38D5 and 36.3937), that relocs to
13.081B.
Looking at 13.0000 and following code, you'll find a push
38D5 (68D538) and a push 3937 (683739) at 13.064D and 13.06AE.
The road to the crack is now open, you just need to find and
"fool" the calling routines. You'll learn the exact procedures
for this kind of WINcracks in part 2 and 3 of -> Lesson 8. Let's
now have a look at the protection scheme (disassembly from WCB):
...
13.0E88 660FBF46F8 movsx eax, word ptr [bp-08]
13.0E8D 668946F4 mov [bp-0C], eax
13.0E91 668B46F4 mov eax, [bp-0C]
13.0E95 6669C00A000300 imul eax, 0003000A
13.0E9C 668946F0 mov [bp-10], eax
13.0EA0 668B4606 mov eax, [bp+06]
13.0EA4 663B46F0 cmp eax, [bp-10]
13.0EA8 7505 jne 0EAF <- beggar_off
13.0EAA B80100 mov ax, 0001 <- flag 1 = "Right!"
13.0EAD EB04 jmp 0EB3 <- and go on
beggar_off:
13.0EAF 33C0 xor ax,ax <- flag 0 = "Nope!"
13.0EB1 EB00 jmp 0EB3 <- and go on
I want you to have a good look at this protection scheme.
IT'S THE SAME OLD SOUP! You do remember lesson 3 and the
protection schemes of the old DOS stupid games of the '80s, don't
you? IT'S THE SAME OLD SOUP! In this "up-to-date" "new"
windows
application, in WINPGP version 4.1 of 1995/1996, exactly the same
kind of protection is used to "conceal" the password!
A) compare user input with memory echo
B) beggar off if not equal with AX=0
C) go on if equal with AX=1... how boring!
Besides, look at all the mov eax, and eax, moves preceding
the compare! That's a typical pattern for these "number_password"
protections! I wrote (years ago) a little crack utility that
searches for code blocks with a "66" as first instruction_byte
repeating in four or more consecutive instructions and it still
allows me to crack more than half of these windows password smuts
in less than three seconds flat. The IMUL instruction creates the
"magic" number, and if you give a closer look at the mathematical
part of the "conceal" routine, it could help you to crack
analogous schemes used in order to protect the "Instant access"
(c) & (tm) time_crippled software :=)
Now you could crack the above code in 101 different ways,
the most elegant one would probably substitute je 0EAF (or jZ
0EAF, that's the same) to the jne 0EAF at 13.0EA8. You just write
a 74 at the place of the 75, like you did for the cracks in
1978... how boring: it's really the same old soup! (But you'll
see some new tricks in the next lessons).
Well, that's it for this lesson, reader. Not all lessons of my
tutorial are on the Web.
You 'll obtain the missing lessons IF AND ONLY IF you mail
me back (via anon.penet.fi) with some tricks of the trade I may
not know that YOU discovered. Mostly I'll actually know them
already, but if they are really new you'll be given full credit,
and even if they are not, should I judge that you "rediscovered"
them with your work, or that you actually did good work on them,
I'll send you the remaining lessons nevertheless. Your
suggestions and critics on the whole crap I wrote are also
welcomed.
+ORC 526164@anon.penet.fi