1. File Analysis with MicroSoft DEBUG
DAT2343
File Analysis with MicroSoft DEBUG
File analysis using MicroSoft’s DEBUG.
DEBUG is a program which has been supplied with every MicroSoft operating system since MS-DOS 1.0.
It enables us to examine low level encoded patterns and operations within a computer running a MicroSoft operating system.
© Alan T. Pinck / Algonquin College; 2003

2. Starting a DOS Window in XP
Start – Run – (command) or
Start – Programs – Accessories
– Command Prompt
(slight variations may exist between this and different installations of XP or other Windows Operating Systems)
DEBUG is always run from within a DOS window.
Therefore the first stage in using DEBUG is to open a DOS window.
Assuming that this has not been set-up as an icon on the desktop or on the Start pop-up, one of two methods will typically be used.
Either
Click “Start” then “Run” and enter “command” in Run’s command text box Or
Click “Start”, then “Programs”, then “Accessories” and finally “Command Prompt”; note that in versions other than Windows XP, “Command Prompt” may be “MS-DOS Prompt” or some other, similar entry.

3. DOS Windows Controls in XP
It is often useful to be able to mark and copy text from a DOS window (to be pasted into some other application file).
By left-clicking on the title bar icon and selecting Edit from the drop-down menu, it is possible to mark and then copy text from a DOS window.
(Other Windows OS’s provide icon tools to do this on the title bar).
Once a DOS window has opened, you can enter DOS commands in response to the standard DOS prompt.
Before doing this however, it may be useful to examine the tools available for this window. In Windows XP, these tools are available through a drop-down menu which can be activated by clicking on the icon on the left side of the DOS window title bar.
The Properties menu item permits you to change the font type and size, the background and foreground colors, and so on.
For our, immediate, purposes, the Edit menu item will be of more interest. Edit supplies a submenu which permits you to mark a block of text in the DOS window, using standard click and drag methodology, and then to copy the marked text to a Copy/Paste buffer, from where it can, later, be pasted into a text file using any normal text or document application (such as NotePad).
Prior to XP, the Mark and Copy functions were supplied as icons in the DOS window title bar.

4. Running DEBUG from the DOS prompt
At the DOS prompt, type:
DEBUG
and hit <Enter>
DEBUG will respond with its prompt symbol, the dash -
In order to run the DEBUG program within an active DOS window, type DEBUG (and hit the Enter key) following a standard DOS prompt. (Note that DOS does not care if characters are entered in upper or lower case; but all examples in these slides will use upper case to improve readability).
Once DEBUG starts running, it will respond with its own prompt, the single dash symbol, indicating that it is waiting for a command to be entered.

5. Examining a File in DEBUG
At the DEBUG prompt, enter:
N followed by the filepath for the file to be examined
This identifies the file Name to DEBUG L
This tells DEBUG to Load the file D
This tells DEBUG to Display or Dump
In order to examine a file in DEBUG, it is necessary to go though a series of steps:
First, identify the name of the file to be used to DEBUG, using the command N (for name) followed by a DOS file path of the file to be used. Note that DEBUG can only use one file at a time; so a second N command will cause the first file name to be lost (as far as DEBUG is concerned).
Second, tell DEBUG to Load the file into memory, using the L command.
Finally, ask DEBUG to Display or “Dump” a block of memory to the DOS window for you to examine, using the D command. The first time you use a D command, you will get a display of an area of memory which contains the beginning of the file; a second D command will result in the next area of memory, a third D command, the area after that and so on.

6. Sample DEBUG File Display
In this slide we see an example of this process. (Note that the user entries have been shown in red, for clarity)
DEBUG has been started.
A file path has be supplied.
A request was made to Load a copy of the file into memory.
And a request was made to Dump the first area of memory into which the file was loaded.
As you can see the Dump is supplied in three major column areas:
On the left, there are memory addresses. Each memory address is composed of two parts a segment value, which does not change and will not be of any interest to us at this time, and an offset. The offset address supplied in the Dump is the offset address of the first of a series of 10 hex (or 16 decimal) bytes. For example, in the third line of the Dump, the offset value of 0120 hex refers to the address of the byte with the value 08 hex; the next byte with value 98 hex would have an offset address of 0121 hex, the byte after that with the value 80 hex would have the offset address of 0122 hex, and so on until the byte at offset address 012F which has a value of 2C.
The middle area shows the contents of memory (which contains a copy of the bit patterns found in the file that was loaded) in hexadecimal. Notice that the dash in the middle of each line in this area, is not anything found in memory (or in the file)… it has been supplied by DEBUG to help in counting offset addresses across the line; the byte to the immediate right of the dash has an offset address which ends in an 8 (in hex).
The area to the right is a decoding of the byte values under the assumption that they are ASCII encoded characters… of course this is not always true, but this area is useful for those cases where the file contents actually are ASCII characters. A period is displayed for any byte which does not have a valid standard ASCII meaning. It is possible to determine the ASCII code for any symbol (except a period) if that symbol appears in this right-most area. For example, in the second line we have an exclamation mark as the fourth character; this corresponds to the fourth byte value in memory (as shown on this line)… the value 21 hex; therefore the ASCII code for an exclamation mark is 21 hex.

7. Copying the Hex Contents for Analysis
Use the DOS Windows controls to copy a few lines of the hexadecimal file contents into a NotePad or similar file to work with; set the font to Courier New or some other non-proportional font:
4A C8 FE
FF FF CD C BA DA CA 0A
FC 3A B0-40 8A 0E C 20 2C
60 A2 C2 96 A A-26 6A A C0
Generally speaking, if we want to analyze a file’s contents (as shown by a copy of those contents from memory as displayed by DEBUG) we normally would copy the center area of a Dump using the DOS windows tools mentioned earlier, into a text document… for example, a text document under NotePad. The standard Windows paste command should work for this, provided you marked and copied the area from the DEBUG display correctly.
In order for the Dump to line-up correctly, the line width should be at least 50 characters (this is not normally a problem) and the text should be displayed using a non-proportional font, such as Courier New.

8. Quitting DEBUG In order to exit or “quit” the DEBUG program, enter Q
at the DEBUG prompt
(Return to the file where you pasted the hexadecimal file contents)
Once you have copied the dump area into a text document, it is safe to return to the DOS window, running DEBUG and quit the DEBUG program’s execution. This is done using the DEBUG command Q (for quit).
…type EXIT (or, in XP, use the “close application” button on the title bar) to end the DOS window session;
then return to the text document.

9. Sample Analysis of the “Dump”
Suppose that the file contained records composed of a 4 (ASCII) character field followed by a (2-byte) integer field (2’s complement, little Endian).
The first two records could be extracted from the dump as: 4A
C8 FE
As an example, suppose the file we just dumped contained records for which we knew the format was:
4 ASCII encoded characters, followed by a
2-byte integer field (in 2’s complement, stored in little endian form… that is, with the lower byte of the number stored first).
You could extract the first 12 bytes of the file content as two 6-byte sequences, as indicated on this slide.
The first record would have an internal pattern composed of 4A, 70, 20, and 33 (hex) for the 4-byte ASCII field
And 45, 20 for the 2-byte integer field (remember that the “normal” way of writing this integer field would be as 2045 hex, since it has been stored in little endian fashion).
Similarly, the second record would be composed of:
64, 52, 35, and 32 as its 4-byte ASCII field and
C8, FE as its 2-byte, little endian, 2’s complement integer field.

10. Analysis of First “Dump” Record
4 ASCII characters: 4A
Using an ASCII table this translates into “Jp 3”
2-byte integer field
45 20 (little Endian form)
Using standard 2’s complement conversion:
2045(hex) = 8261(dec)
As a continuation, of this example, you could decode the 4 ASCII encoded bytes of the first record, using standard ASCII conversion methods… 4A represents the 10th ( or Ath in hex) upper case letter of the alphabet;
70 represents the 16th (or 10th in hex) lower case letter; 20 represents a blank; and 33 represents the digit 3.
Decoding the 2-byte, little endian, 2’s complement field requires reversing the order of the byte values to give a hexadecimal value of 2045 hex… since this is a positive value, the number that it represents is simply the sum of 2x4096 plus 0x256 plus 4x16 plus 5x1, that is, 8261 in decimal.

11. Summary of DEBUG Commands
Nfilepath
Name file to be used L
Load previously named file
D or Dxxxx
Dump/Display memory contents (starting at offset xxxx) Q
Quit DEBUG
For the purposes of file analysis, the significant DEBUG commands are summarized on this slide.
N used to supply a file name or path
L used to ask that a copy of a file’s contents be made in memory
D used to Dump or Display memory… notice that it is possible to supply a starting offset address following the letter D, and this may be necessary if you type several D commands and lose the beginning of your file; should this happen, assuming the file you loaded does not have an extension of .EXE (which is handled in a special way), the copy of the file will always be loaded starting at an offset address of 0100 (hex).
Finally, the most important command for any program: the command that lets you stop the program…
For DEBUG, the letter Q.

12. End of Lecture