326 lines
17 KiB
Plaintext
326 lines
17 KiB
Plaintext
|
|
HOW TO CRACK, by +ORC, A TUTORIAL
|
|
|
|
Lesson 8.1: How to crack Windows, an approach
|
|
|
|
--------------------------------------------------------
|
|
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
|