About this Essay...

This 'essay' is still UNFINISHED and still in a rough draft form, I've posted it on my homepage so that what information has already been covered will at least help you now until I've been able to finish it.
 
    

 

 
 
About Dead Listings...

There is no mystery or secrecy surrounding 'Dead Listings' yet they remain under used and often ignored by many novice crackers.  Lets see if we can dispel a few mis-conceptions and bring this useful form of information right into the open where it belongs.

Dead listings refer to the fact that we can create a dissembled listing ( the source code ) of almost any program currently available, regardless of wether  it's a MS-DOS or Windows program.  Some, but not all, Dissasemblers have restrictions on what programs they can dissasemble, it's always best to check the associate help files for these programs for any limitations.
 
Dead listings comprises of a single text file that describes in the form of Assembly Language, every instruction that the target program is expected to use or execute. Contrary to popular belief, you don't need to understand Assembly Language inside out to use dead listings, in fact, knowing only a few important Assembly instructions and combining these with a few guidelines will help you to understand your target program far better than just using Softice on it's own!.

Think of 'dead listings' as a map to an unexplored city, it will tell you where all the code routines are in relation to each other and from a cracker's point of view. They can tell you where all the important sections of code that are related to your target program's protection system(s) are kept.  Not everyone can read a map but almost everyone can understand that a road is a road and a building is building so in dead listings we can see what Shareware messages there are, such as "Pease register..." and "You 30 days evaluation period has expired".  Dead listings more often than not will not only show you these messages but many more besides.  Think of these messages or text strings as they are often reffered to as sign posts that give you a pretty good idea what the surrounding code does and how it is used.

Before examining the actual 'dead listings' themselves in any detail lets us first look at the advantages and dis-advantages of using the 'live'  and 'passive' approaches to cracking.

Cracking by 'passive' and 'live' approaches.

There are two approaches we can use to *cracking* a program, the first is often called the 'live' approach, which involves using a Debugger such as Softice to trace through the program's code step-by-step as the program is running on your computer.  The second approach is commonly known as the 'passive' approach, where instead of using a debugger such as Softice to trace through the program's code we instead, use a program such as W32Dasm to create a 'Dead listing' of our target program, where we can then try and work out how the program operates.

 
The 'Live' approach to cracking....

In general, it's accepted that we will be using a debugger such as Softice to take full control over our target program, by full control I mean we can follow each Assembly instruction the program takes one step at a time if we choose.
 
Softice is a program that runs in the background of Windows, it has to in order that it can take full control over our target program and Windows itself. Like any software you use, understanding how it works is only part of being able to use it properly, you also have to have a fair understanding on the information it gives you!. What's the point in assigning a value to say the EAX register if you don't know the reasons why!
 
 
Main advantages of 'live' cracking over 'passive' cracking .

In 'live' cracking... You can directly control the way the program 'thinks' and therefore 'behaves' by manipulating the values contained within your computer's 'Registers'.

In passive cracking.. You have no control what-so-ever over the target program and therefore no access to any of your computer's registers.
 
In 'live' cracking... Softice automatically takes our attention to other sections of code within the target program as we follow it line-by-line, instruction-by-instruction. Mistakes in following the program's normal path of execution is rare. 

In passive cracking.. We must take extra care in following all the *possible* combinations of decision branches the target program makes in order to minimize mistakes in identifying possible routines connected with the protection system. Many protection systems use 'dummy' sections of code that lead nowhere in order to try and wear down the cracker before they reach the 'bingo' code!

In 'live' cracking... We can 'test' possible patches to the program without worrying about changing the program stored on our hard disk. Changes to the program in memory remain only so long as the program is running. As soon as we quite the program then any/all changes to the target program's code is also lost, therefore allowing us to quickly and with minimal fuss, make as many changes to the target program as we like without consequence.
 
In passive cracking.. Our task is not to try out any patches, only to identify *possible* program locations that could be patched to suite our needs.

In 'live' cracking... We can go and explore almost any type of program code such as .DLL (Dynamic Linked Library) files that increasingly play an important role in many programs currently available today. .DLL's are treated differently to normal .EXE files and being able to easily examine these files helps considerable our understanding of some programs that rely on these types of files for their protection systems.  TimeLock32 is the name of a well known Protection System favored by many Software Houses to protect their 'software' which uses the TL32V2.DLL file to house it's protection system in.

In passive cracking.. DLL files are not always correctly disassembled  (Certainly true for W32Dasm) in so much that it's not always possible to know where this file will be loaded into the computer's memory.  Therefore the 'offset Addresses' shown will be wrong which then makes life a little difficult if you wish to patch this type of file.  Another BIG problem associated with Dead Listings is that they can't correctly disassemble any file (EXE,DLL) that has been compressed or encrypted, while in 'live' cracking this is not a problem since the compressed/encrypted code will already be de-compressed/unencypted by the time Softice breaks in.
 
 
 
 

The 'Passive' approach to cracking....

In the 'Crackers' community it's generally accepted that there are only two possible programs that produce *good* dead listings,  IDA Pro and W32Dasm.

IDA Pro is the favorite Disassembler of the more *experienced* crackers though not always.  W32Dasm, because it runs in Win'95 (IDA Pro is a MS-DOS program) and produces IMO much better Dead Listings than IDA Pro and therefore, makes it easier to follow is the preferred tool for newbies including myself.
 
 
Main advantages of  'passive' cracking over 'live' cracking...
 
In passive cracking.. We have an ASCII text file in the form of a 'dead listing' of our target program,  which in turn allows to us to load this text file into a text editor such as Ultra Edit (Notepad can't handle files greater than 64K, while our dead listings can and often be many megabytes in size) for the purpose of adding comments to code sections, or to perform lightning searches of specific code instructions. If, you know that a particular routine within the target program performs a task such as the printing of text messages then you can update all occurrences of any jump or call instructions that sends the program to this message routine and replace the calling address to say "Display text Message".

Example 1.

Change all occurrences of address 0040345 to "Display text Message"

                    Call 00401345  -----------> Call Display text Message
                    JZ  00401345  -----------> JZ Display text Message
                    JNZ 00401345 -----------> JNZ Display text message
 
 

In 'live' cracking... What you see is what you get.  Yes you can perform searches on code instructions but unless you know exactly where your target program starts in memory and where it ends then any searches you make will also include areas of memory outside of the target program's code. Unless you have the source code to your target program (highly unlikely!) then the only visual 'clues' you'll get from the target program's code will be from the system calls to functions such as MessageBox(A), getLocalTime(A), GetWindowtext(A) etc which will only be seen if you've setup Softice properly at Bootup time through it's Winice.DAT file.

In passive cracking.. We can produce 'hard copys' from our dead listing using a printer, this is not always necessary but it's nice to know the facility is there if you do need it.  If your writing an essay about cracking a particular program then having a 'Dead Listing' that you can cut and paste sections of code into your .HTM document makes a difficult job of manually typing the code by hand into a doddle.
 
In 'live' cracking... Making hard copy's of your target program is not possible but more importantly, it's not necessary, since we're must always remember that 'live' cracking is on-going project that lends itself better to you making notes by hand as you examine in detail, the inner void of your target program.
 
    

 
 A general introduction to 'Sections' found within Dead Listings.
     
Typically, a dead listing will be split up into many different sections.

For example, many programs rely on using routines or functions (sections of code that perform a specific task) that are already available outside of the program itself and are kept in special files called .DLL's (Dynamic Linked Library's).

Windows 3.X and above uses many such files and saves the programmer(s) from having to create these routines over and over again in their programs if all they have to do is call upon the routine(s) stored within a .DLL file. Visual Basic programs are a classic example of programs running almost entirely on .DLL files.

So in a typical W32Dasm dead listing we have a section of code that shows us what .DLL files are used by the target program and just as importantly, what functions or routines are used.
 

Example 1.

This section of our dead listing shows us what .DLL files are used by our target program.
 

+++++++++++++++++++ IMPORTED FUNCTIONS ++++++++++++++++++
Number of Imported Modules =    3 (decimal)

   Import Module 001: KERNEL32.dll
   Import Module 002: USER32.dll
   Import Module 003: ADVAPI32.dll
 
 

Example 2.

This section of our dead listing shows us what functions or routines are used from the above .DLL files shown above.

+++++++++++++++++++ IMPORT MODULE DETAILS +++++++++++++++

   Import Module 001: KERNEL32.dll

 Addr:00018346 hint(0000) Name: VirtualQuery
 Addr:00018356 hint(0000) Name: HeapFree
 Addr:00018362 hint(0000) Name: GlobalAlloc
 Addr:00018370 hint(0000) Name: WideCharToMultiByte
 Addr:00018386 hint(0000) Name: HeapAlloc
 Addr:00018392 hint(0000) Name: CloseHandle
 Addr:000183A0 hint(0000) Name: GetFileSize
 Addr:000183AE hint(0000) Name: GlobalUnlock
 Addr:000183BE hint(0000) Name: WriteFile
 Addr:000183CA hint(0000) Name: ExitProcess
 Addr:000183D8 hint(0000) Name: FindResourceA
 Addr:000183E8 hint(0000) Name: FreeEnvironmentStringsA
 Addr:00018402 hint(0000) Name: FreeResource
 Addr:00018412 hint(0000) Name: GetACP
 Addr:0001841C hint(0000) Name: GetCPInfo
 Addr:00018428 hint(0000) Name: CreateFileA
 Addr:00018436 hint(0000) Name: GlobalMemoryStatus
 Addr:0001844C hint(0000) Name: GlobalFree
 Addr:0001845A hint(0000) Name: GetVersionExA
 Addr:0001846A hint(0000) Name: lstrcatA
 Addr:00018476 hint(0000) Name: GetFileType
 Addr:00018704 hint(0000) Name: Sleep
 Addr:0001870C hint(0000) Name: TlsAlloc
 Addr:00018718 hint(0000) Name: TlsFree
 Addr:00018722 hint(0000) Name: TlsGetValue
 Addr:00018730 hint(0000) Name: TlsSetValue
 Addr:0001873E hint(0000) Name: UnhandledExceptionFilter
 Addr:0001875A hint(0000) Name: VirtualAlloc
 Addr:0001876A hint(0000) Name: VirtualFree

   Import Module 002: USER32.dll

 Addr:00018778 hint(0000) Name: SetWindowPos
 Addr:00018788 hint(0000) Name: SetTimer
 Addr:00018794 hint(0000) Name: SetFocus
 Addr:000187A0 hint(0000) Name: SetDlgItemTextA
 Addr:000187B2 hint(0000) Name: PostThreadMessageA
 Addr:000187C8 hint(0000) Name: MessageBoxA ; A good Softice breakpoint
 Addr:000187D6 hint(0000) Name: LoadStringA
 Addr:000187E4 hint(0000) Name: GetWindowRect
 Addr:000187F4 hint(0000) Name: GetFocus
 Addr:00018800 hint(0000) Name: GetDlgItemTextA ; A good Softice breakpoint
 Addr:00018812 hint(0000) Name: GetDlgItem
 Addr:00018820 hint(0000) Name: EnumThreadWindows
 Addr:00018834 hint(0000) Name: EndDialog
 Addr:00018840 hint(0000) Name: KillTimer
 Addr:0001884C hint(0000) Name: EnableWindow
 Addr:0001885C hint(0000) Name: DialogBoxParamA
 Addr:0001886E hint(0000) Name: SetWindowTextA

   Import Module 003: ADVAPI32.dll
* These functions handle the reading and writing of information to our *
* System Registry file, and can sometimes make good softice breakpoints *

 Addr:00018880 hint(0000) Name: RegSetValueExA
 Addr:00018892 hint(0000) Name: RegDeleteKeyA
 Addr:000188A2 hint(0000) Name: RegQueryValueExA
 Addr:000188B6 hint(0000) Name: RegEnumKeyExA
 Addr:000188C6 hint(0000) Name: RegCreateKeyExA
 Addr:000188D8 hint(0000) Name: RegCloseKey
 

So knowing what functions\Routines we can and can't use in Softice is worth knowing but from our point of view it's not all that important.

The next thing you'll need to know...

+++++++++++++++++++ ASSEMBLY CODE LISTING ++++++++++++++++++
//********************** Start of Code in Object CODE **************
Program Entry Point = 00401000 (Validate.dll File Offset:0000FC00)
 

In W32Dasm we are told  where the program's code starts in memory, however, this does NOT mean 'where' the program will begin executing from when it's first run, this could be anywhere and is rarely  the same for different programs.
 
    

 

A general introduction to how memory (RAM) is organized.
     
Confusion raises it's ugly head amongst newbies on how the assembly code relates to memory address in our computers and from just my daily emails this type of question is asked many times in as many ways. Well ok, here goes my simplified explanation of this mystery and how I make sense of all this..

When you create a dead listing W32Dasm has no way of knowing exactly where our target program will be loaded into our computers memory, this factor depends on the following conditions:-

1. The amount of overall RAM (Random Access memory) which Win 3.X or above has at its disposal.

2. The number of 'other' programs you may have silently running in the background like NotePad or Word for Windows or Softice etc are given priority over your target program so that Windows then has to find 'other' free memory locations to run your target program. Since your computer's memory is mapped into pre-defined memory blocks, each capable of running a single program we have no way of guaranteeing which of these 'blocks' our target program will be assigned to.

In order to better visualize the computer's memory try thinking of your computer's memory as an empty book.

Now within this book are a number of blank pages, and on each page is the Page Number, which in computer terms is known as Memory Address.

In order to help you further, this book has each page of this book line numbered, starting from 00000000 to FFFFFFFF which in computer terms is known as Memory Offset Address.

So we have a Page No known as Memory Address and the line numbering of each page known as Memory Offset Address.
 

Example 3.  - A 'Page' Of Memory.

<Memory Address>    < Colon>    <Memory offset Address>

0000013F                           :            00000001
0000013F                           :            00000002
0000013F                           :            00000003
0000013F                           :            00000004
 

So that the computer doesn't get confused we us a COLON <:>  to signify the end of the <Memory Address> and the start of the <Memory Offset Address>.

Here's what a full memory location address might look like:-

Memory Address Colon Memory Offset Address

      00F45324               :             00400000

 <Page No>                  :            <Line No>
 

In dead listings we don't care where Windows will be placing our target program, ie in which 'Page', because in whichever  'page' it loads our target program the Line renumbering <Memory Offset Address>  will ALWAYS be the same, and it's this <Memory Offset Addresses> that W32Dasm uses in it's dead listings.

Don't worry about how big these 'pages' of memory are, or how many lines of code we can have on each 'page' just accept for now that as far as we're concerned, Memory offset Addresses are no more than line numbers and that W32Dasm uses line numbers in the Assembly code listing (called Dead Listings) to calculate where  jumps and calls statements will take the program to.

ALL computer programs regardless wether it's a game or utility or whatever are all made up of Decisions then followed by TWO possible Actions.  If you press a button or type something from your keyboard then the program will Decide what course of Action it will take based on what YOU just did.
 

Example 4.  - Decisions followed by two possible Actions.

If you type in a serial number into a program then press the OK button then the program may make the following decisions and Actions:-

Question: Did you press the 'Cancel' button?

Answer 1.  If YES then ignore serial number and display a warning type message.
Answer 2.  If NO then lets check the serial number to see if its valid.

Question: Is serial number valid?

Answer 1. If NO then display a message telling you to try again.
Answer 2. If YES then allow program to be registered.
 
 

The above is an extremely simple overview of what a program does, in reality it does these sort of decisions and actions all the time the program is running and in much more depth but at least I hope, you'll start to understand the general concept of decisions followed by one of two possible outcomes.
 
    

 

     
About W32Dasm
 
The two most popular programs used by crackers to create 'Dead Listings' are:-

W32Dasm V8.9
IDA Pro V3.75

For this introduction I shall concentrate on using W32Dasm as our major source of creating 'Dead Listings' although much of this essay can be converted over to IDA with perhaps only minor changes in operations.

So what is W32Dasm?.

W32DASM

Synopsis: W32DASM v.8.9 is a combined disassembler/debugger that totals up to 2.13MB. The disassembler allows viewing of one file at a time; starting a debug
process allows the disassembled file to be run and patched in memory (debug mode
commands are marked with D, below). Features include import and export function
tables, reference tables for strings, menus, and dialog boxes, hex dumps of data and code segments, and jump/call branching. The debugger is standard fare with the added features of in-memory code patching and Windows API call "detailing"--a valuable feature that gives the parameters and returns of any API call made by the program.

Usage: W32Dasm has a user-friendly interface that is pretty easy to figure out. The key  points are to check out the Refs and Functions menu items, each of which gives a list of relocations/resources within the disassembled file that may be jumped to by double-clicking the list item. The Hex Data item would be more useful if it included resources (for all those Delphi/VB apps out there), but it does allow you to re-interpret the code and data (in your head) if need be. Execute Text and Goto are both worth checking out; the first allows you to follow jumps and calls (also available via keystrokes and on-screen buttons), the second will jump immediately to the entry point or a specific code location (no file header, unfortunately).

Debugger: W32Dasm has a serviceable debugger that has some nice features, but is rather difficult ot use. The benefits include a data display that allows you to easily browse the data pointed to by different registers (e.g., ecx, ecx+0004, ecx +, 0008, etc), an API feature that displays the parameters and returns of API calls made by the program, and an integrated "copy" option that allows either of the two data displays, a list of active .DLLs, a message/command history, and a current register or memory location to be copied to the Windows clipboard. The downside is that the User Interface is a nightmare; the combination of the three staggered windows (reminiscent of newer "visual" IDEs) and the swarm of tiny check boxes and buttons makes the whole thing visual disorienting you pretty much have to go in with BRW and modify the UI to suit your taste.

                                 Shortcuts

 Ctrl-L    Load Process                Ctrl-T   Terminate Process (D)
 F5        Auto Step Into(D)           F6       Auto Step Over(D)
 F7        Step Into(D)                F8       Step Over(D)
 F9        Run Process(D)              Space    Pause Process(D)
 F2        Breakpoint Toggle (D)       Ctrl-C   Copy Selection
 Ctrl-S,F  Find Text                   F3       Find Next
 Ctrl-S    Goto Code Start             F10      Goto Entry Point
 F11       Goto Page                   F12      Goto Code Location
 Lft Arrow Execute Jump                Ctrl Rt  Arrow Return From Jump
 Lft Arrow Execute Call                Rt Arrow Return From Call

W32Dasm is a Windows 95 program, much preferred by newbies because it has an easy to understand interface and the dead listings created are also in an easy-to-understand format.  You cannot disassemble MS-DOS programs with W32Dasm.

IDA Pro on the other hand is a MS-DOS program, it's very much more powerful than W32Dasm and is often able to show difficult sections of code that W32Dasm fails to handle properly. IDA's interface is rather dated and will look quite daunting to those not familiar with such programs and the output too will also look unfamiliar to those used to seeing W32Dasm's smart looking dead listings.
 
    

 
 
     
 NOT YET FINISHED....

Please keep checking in for additions..

Please send comments/ommisions etc about this essay to:  The Sandman
 

Essay by:          The Sandman
Page Created: 4th August 1998