China DOS Union

This File is Write in Chinese.
Welcome to use the interpreted trace debugging software ---- TR
————Liu Taotao
IV. Assembly instructions as commands
People who do assembly language are full of assembly in their minds, and may not be willing to remember complex debugging commands. It is certainly a good idea to use assembly instructions as commands. It is good to use R AX 1234, and it is more interesting to use MOV AX, 1234? Other CLI\MOV ,4567\IN AL,21 are all good commands.
V. Allow comments on the debugging program
VI. Automatic jump
VII. History record
TR can record each CS:IP that has been executed for static analysis. If the program is wrong, you can check the history record and go back to find the problem. There is also the powerful LOGPRO, which can sort out the key instructions of the program. The traced program has no secrets.
See commands LOG, LOGS, VLOG, LOGPRO.
VIII. Write the memory code into an EXE file
IX. Complex breakpoints, one-time breakpoints.
(1) BP CONDITIONS
Conditional breakpoint. For example: BP IP>4000 ; The code is long, only track the second half
BP AH=2 DL=80 CH>30
(2) BPINT intnum Interrupt breakpoint
(3) BPXB BYTES
Stop when the specified instruction is encountered. For example: The machine code of MOV AX,???? is B8????, which can be used
BPXB b8
Other:
BPXB cd ; All interrupts
BPXB 33 C0 ; XOR AX,AX
(4) BPREG REG|SEG
If the specified register changes, pause. BPREG CS can find all segment jumps.
BPREG CS AX=0 ES=# ; # refers to the current PSP
You can find the real start with the shell program.
(5) BPM OFFSET
Pause if the specified address is accessed. For example, BPM 20 will stop MOV AX,.
(6) BPW SEG:OFFSET
Pause if the specified address changes. Some operations (such as INT) can only find whether the memory has changed by checking again and again.
(7) BPIO port
(8) BPKNL
Pause if a new program kernel is found.
It is particularly important that if a breakpoint is only used once, change 'BP' in front of the breakpoint setting command to 'GO' or 'GS' to execute directly. With this one-time breakpoint, generally no special breakpoint needs to be set.
Author: Liu Taotao
Address: Henan Anyang Colored Glass Company Information Room
Postcode: 455000
Telephone: 0372-3932916-2273
EMAIL: ayliutt@hotmail.com
ayliutt@nease.net
Homepage: http://www.nease.net/~ayliutt
ICQ UIN: 3434573
97.10.21
----------------------------------------------------------------------
NOTICE
I. TR supports Turber Debuger debugging information. If you are debugging a C language program with debugging information, you can use g _main to quickly enter the scene.
II. Support 32-bit instructions (see command r32)
III. After exiting TR, all interrupts modified by the user program will be automatically restored, and the occupied memory will be automatically released.
IV. If the system has XMS, TR automatically uses it to save some memory space.
V. All digital inputs are in hexadecimal.
Running TR requires a CPU above 386, running under DOS, and can also run in the DOS window of WINDOWS and WINDOWS95, but the speed will be slower. Compatible with HIMEM or EMM386 or any other XMS/EMS memory management software. It can run well under SOFT-ICE. TR will only track DOS programs in real mode and knows nothing about protected mode and WINDOWS programs.
I. Register area
The top of the screen is the register area. The default is 16-bit mode display. You can use the R32 command to change to 32-bit mode.
Use the R command to set the register value, such as:
R AX 1234
R ebx 12321456
R ch 87
R dl ah
R ip ip+1
R fl z
For the flag register, use ODISZAPCT, and the recently changed registers are displayed in different colors.
II. Memory area.
Use WD num to change the number of lines in the memory area.
There are two display methods in the memory area. One is the ordinary method where the segment remains unchanged and the offset changes continuously. The other is the method where the segment changes by 10H and the offset is 0. In the normal mode, use the E command to move the cursor to the memory area. If the current OFFSET is less than 0F, press the up arrow to change to the second display method. Use the D command to restore.
III. Code area
The center of the screen is the code area, which displays the assembly code of the program. Supports 386 instructions, can display labels and comments, and explain common interrupts.
IV. Command area
Used to enter commands. You can press the F5 key to zoom in, and use the left, right, up, down, page up and down, HOME, END and other keys to move the cursor, and use DEL and BACKSPACE to modify.
If you want to execute a command multiple times, put the cursor on that command and press ENTER.
V. Status line
Display whether the command is executed normally.
VI. The above are the main windows of TR. In addition, there is F4 to display the user screen, VIEW command to list the file content, STACK command to display the STACK window, VLOG to display the history window, etc.
----------------------------------------------------------------------
Commonly used keys
<F8> Execute an assembly instruction, equivalent to command T.
<F10> Execute a procedure, equivalent to command P.
<F4> Display the user screen, equivalent to command RS.
<F6> Command window <--> code window.
<F7> If the cursor is in the code window, execute to the cursor position (HERE).
<F5> Maximize the current window. The current window can be the command window, code window, or memory window.
<F9> If the cursor is in the code window, set (or clear) the cursor position as a breakpoint.
Ctrl+D Pause the running of the program and return to TR. Note that TR will only stay in the code of the traced program and will not stay in the system code, so sometimes it will not return immediately after pressing the hotkey Ctrl+D.
----------------------------------------------------------------------
Commonly used symbols
<$>:
In TR's command, you can use the dollar sign '$' to represent the current CS:IP. Command
D CS:IP
And command
D $
Are equivalent. The command U $ can be replaced by the command.
<*>:
In TR's command, the asterisk '*' represents the operation address of the current instruction. If the current CS:IP is
****:**** mov ax, ;1234:5678=****
And at this time DS=1234, DI=5678, then the command D *
Equivalent to command D DS:DI
Or D 1234:5678.
<@>:
Pointer to get the address. For example, if
1234:5678 11 22 33 44
Then @1234:5678 represents 4433:2211.
You can use @0:21*4 to represent the address of interrupt 21.
If you just entered a CALL FAR or INT, you can return with @ss:sp.
<#>:
In TR's command, the pound sign '#' represents the PSP value of the current program.
Example: D #:0
<;>:
Semicolon ';' represents a comment, and the part after the semicolon in the command will not be interpreted.
AUTORUN.TR:
Every time TR runs, it will automatically execute the commands in the file AUTORUN.TR in the current directory. Add the commands you always want to execute to AUTORUN.TR. Such as R32, AUTOINT1 ON, etc.
---------------------TR customized commands--------------------
COLOR
If no parameters are brought, the current color setting of TR is displayed. If parameters are brought, there must be 9 values, which respectively represent
1: Register area register name
2: Register area register value
3: Register area changed register value
4: Code area general code
5: Code area current CS:IP
6: Code area label or comment
7: Code area breakpoint
8: Command area general command
9: Command area comment
a: Status bar
For example: color 7 b e 7 e 2 4 17 36 76
MSG
Display the information window. Mainly used in DO command files for demonstration. The following commands are all used as information to be displayed, and an empty return returns. X, Y are the positions of the information box, -1 is automatically in the upper right corner, and -2 is centered. Example:
msg 20 5
this is first line message
THIS IS SECOND LINE
And third
; Empty return

VER
Display version information.

R32
Switch between 16-bit registers/32-bit registers. If it is in 16-bit state, the register window is displayed as
AX=1234 BX=1234 CX=1234 DX=1234 SP=1234 BP=1234 SI=1234 DI=1234
DS=1234 ES=1234 SS=1234 CS=1234 IP=1234 o d i s z a p c t
The display in 32-bit state is:
EAX=12345678 EBX=12345678 ECX=12345678 EDX=12345678 SP=1234
EBP=12345678 ESI=12345678 EDI=12345678 FS=1234 GS=1234
DS=1234 ES=1234 SS=1234 CS=1234 IP=1234 o d i s z a p c t
Regardless of the state, it does not affect the system operation. The default is 16-bit. If you like 32-bit state, add R32 to the file AUTORUN.TR.

REDRAW
Redraw the screen.

WD
Set the number of lines in the memory window.

---------------------Input/output commands--------------------
A
Assembly. Although the code window can recognize 32-bit code, the A command cannot handle 32-bit code for the time being.
It will be improved in future versions. You can directly use the method of 'BEGIN:' to define labels.
A cs:0
start: ;define label
mov ax,bx ;any asm code
;return to command mode
D ]
Display memory in hexadecimal and ASCII code. Add the '>' sign to output the result to a file, such as:
D cs:ip
D *
D 1234:5678>myfile.txt
D cs:0lffff>file
D >file
The default length is 40H.
E bytes]
Memory modification. If no parameters are brought, the cursor moves to the data area. At this time, you can press the left, right, up, down, page up and down, HOME, END and other keys to move the cursor, press the alphanumeric keys to modify the memory, and press the TAB key to convert between hexadecimal and ASCII code. Example:
E cs:0 12 23 45 'abc'
E b800:200 36 24
E 234 'def',0d,0a,'$'
The default segment is DS.
F range bytes
Fill. Fill the memory area with the given string, such as
F cs:0,ffff 12 23 45 'abc'
F b800:0L200 36 24
F 234 'def',0d,0a,'$'
If the length is not specified, the given string is filled at least once, which is equivalent to the E command.
The default segment is DS.
L :OFFSET]
Read the file into memory. Note the difference from RELOAD. L just reads the file into the specified memory area, while RELOAD finds a free memory to transfer in, establish PSP, set registers, and prepare to execute.
The default segment is DS, and the default address is DS:100.
Example: N c:\autoexec.bat
L 100
N c:\command.com
L 200
L DS:300 MYFILE.BIN
L :OFFSET DRIVE STARTSECTER SECTERS
Read the specified physical sector from the specified physical drive.
Example: L 100 0 0 1 ; Read the A drive BOOT area
L 100 2 0 1 ; Read the C drive BOOT area
N
If no parameters are brought, the current file name is displayed. If parameters are brought, the file name is set. Such as:
N MYFILE.EXT
See: W, L, RELOAD

RELOAD
Reload the file. If the file name has been modified by the N command, the new file is loaded.
Reset all interrupt vectors, memory areas, and registers.
Sometimes the memory applied for by the program last time cannot be completely released, resulting in failure to transfer in. You can exit TR and enter again, EXE2, RELOAD, and still be able to MKEXE.
U ]
Disassemble. Add the '>' sign to output the disassembly result to a file, such as:
u cs:ip
u $
u 1234:5678>myfile
u cs:0lffff>file
u >file
If the disassembly length is not given, the default is 20H.
If the specified file does not exist, it is automatically generated; if it already exists, it is appended.
W
W :OFFSET
W :OFFSET filename
W :OFFSET length filename
Write memory to a file. The file length is BX:CX or length.
The default segment is DS, and the default address is DS:100.
Example: N test.com
W 200
W es:300 myfile.com
W cs:ip dx test.com
W :OFFSET DRIVE STARTSECTER SECTERS
Write the specified physical sector to the specified physical drive.
Example: W 100 0 0 1 ; Write the A drive BOOT area
WREG filename
Write the current register area content to a file. If the file exists, it is appended.
WMEM filename
Write the current memory window content to a file. If the file exists, it is appended.
WCOD filename
Write the current code window content to a file. If the file exists, it is appended.
WCMD filename
Write the current command window content to a file. If the file exists, it is appended.
---------------------RUNTIME commands--------------------
DELAY
Used in DO command files to play a delay role. If the DELAY state is changed in the command file, remember to restore it with DELAY 0 at the end of the file.
Note that the delay is set in hexadecimal.
DO filename *New concept*
Execute batch processing. Specify a text file, which can contain all legal TR commands (even another DO), and let TR execute automatically. Every time TR runs, it will automatically execute the commands in the file AUTORUN.TR in the current directory, which is equivalent to every time TR starts, it will automatically execute a
DO AUTORUN.TR
In the batch file, if a command line starts with a space, TR directly processes the command without displaying it in the command window (the first space is removed).
Special usage: Add an A <enter> in front of an assembly program to let TR assemble it.
See: DELAY, KEY
KEY num
Used in DO batch processing files to simulate key presses. The given value is the value returned by MOV AX,0\INT 16, such as: KEY 1C0D ；Carriage return
---------------------Other commands--------------------
All assembly instructions
TR supports almost all assembly instructions as commands. Although we don't have to do this, sometimes it is really convenient. Try the following commands:
mov ah,4c
jmp 200
cli
Define labels or procedure names:
In the command line, enter a string plus a colon to define the current CS:IP as the given label.
In the assembly state after the A command, the defined is the address currently being assembled.
Example, if the current IP=100, enter 'START:', then CS:100 is START, and all JMP 100 will be translated as JMP START.
In the command line, this is a short form of 'LABEL CS:IP labelname'.
See: LABEL, CMT
.
Display the current CS:IP in the code window.
Equivalent to U CS:IP or U $.
?
Help. If no parameters are brought, TR automatically ZOOMs the command window and briefly displays the syntax and function of each command. You can use Up/Down/PageUp/PageDown to scroll up and down the window, and F5 to restore.
If parameters are brought, TR calculates and displays the result of the parameters, such as:
? ax Display the content of AX
? cx+dx Display the result of CX+DX
? # Display the current PSP
? @0:21*4
? $+5 Display CS:IP+5
CMT OFFSET COMMENT_STRING *New concept*
Annotate the program.
If the segment address is not provided, the default is the current CS. If the address is less than PSP:0 or greater than PSP+2000:0, it is considered a relative address, otherwise it is considered an absolute address.
The annotation string can be any length of string, but the total length of the command cannot exceed 79. If it contains spaces or reserved lowercase letters, use single quotes ''.
All annotations made to the program are stored in the file 'current file name.cmt', which is a text file that can be edited directly. It is automatically loaded when TR is transferred in next time.
If the current CS:IP name is defined, you can directly use 'label name:'.
Example:
cmt cs:200 'This is my comment string'
PROC1:
See: LABEL, SYMBOLS
LABEL OFFSET LABEL_NAME *New concept*
Define a label or procedure name.
If a label or procedure name is defined, the name will be displayed in a line before the address in the code window, and all JMP and CALL statements to this procedure will be translated as 'CALL procedure name' instead of the usual 'CALL ????'.
The program labels are all stored in the file 'current file name.cmt', which is a text file that can be edited directly. It is automatically loaded when TR is transferred in next time.
Example:
LABEL cs:200 file_open
See: cmt, SYMBOLS
LOG *New concept*
Whether to record history. If LOG ON, TR will record the address of each instruction executed later, which can be viewed with the VLOG command. This command only records the last 25 addresses. If you want all records, use the LOGS command.
Using TR's LOG function can use a new method to analyze the program, that is, "go through the back door".
For example, if a program exits in error, if you use the usual method to track from the beginning of the program, it will take a long way to find the problem. And with TR's LOG function, you can analyze what process the program executed last after the program exits abnormally and quickly find the key.
LOGS *New concept*
Whether to record history. If LOGS ON, TR will create a file LOG.DAT in the current directory and store the address of each instruction executed later in hexadecimal in this file. It is convenient to analyze the program flow later. Depending on the complexity of the program, this file may be very long. Please use a special hexadecimal browser to view this file, or use TR's VIEW command.
When LOGS ON, because each instruction is executed once and then saved, the speed is slow. In general, LOG ON is enough. When LOGS ON, LOG is automatically ON.
LOGPRO *New concept*
Function: Record the key code executed by the program for easy analysis. Especially suitable for comparing the correct process and the error process.
If no parameters are brought, the current option is displayed. The meanings of each option are:
0: No LOG
1: Only LOG the following instructions call, ret
2: Only LOG the following instructions call, ret, condition jmp, jmp far
Note: Only when the condition is true for CONDITION JMP is LOG
f: LOG all instructions
LOGPRO stores the LOG instructions in the file LOGPRO.DAT, and each record is 16 bytes long, in the format:
Position Size Meaning
0 DW IP
2 DW CS
4 DW SP
6 DB ?
7 DB ?
8 8 byte Instruction code
Execute LOGPRO.EXE at the DOS prompt, read LOGPRO.DAT, and generate LOGPRO.TXT.
This is the key code of the program.
Special thanks to LX for first proposing this idea.
M RANGE :OFFSET
Memory copy. Such as:
M $L200 8000:100 ; Copy from CS:IP starting length 200 to 8000:100
M DS:0,800 ES:200 ; Copy from DS:0,800 to ES:200
Q
Exit TR. You can also press ALT+X.
All interrupts modified by the user program will be automatically restored, and the occupied memory will be automatically released.
R REG
Change the register value. It can be 8-bit 16-bit 32-bit general register, flag register FL or segment register.
The operation on the flag register can be ODISZAPCT.
Example: R ax 1234
R ebx 12321456
R ch 87
R dl ah
R fl z
RS
Display the user screen (Restore Screen), hotkey F4. Press any key to return.
S range bytes
Find the specified content in memory, such as:
s cs:0,ffff 12 34 45 ; Find 12 34 45 in CS:0 to ffff
s ds:200l100 23 ; Find 23 in DS:200 length 100
SYM
Whether to load the debugging information of the EXE file. The default is ON. If you don't want to load the debugging information of the file, first execute TR without parameters, then:
SYM OFF
N myfilename
RELOAD
Because some wrong debugging information will make TR go crazy.
SYMBOLS
If the program has debugging information or uses the label, cmt command to customize symbols, all symbol names will be displayed.
See: CMT, LABEL
VLOG
Display the historical information recorded by the LOG ON or LOGS ON command.
VIEW filename.ext
Browse the file. You can view the file content in hexadecimal and ASCII mode.
STACK *New concept*
Display the current subroutine nesting status.
For example, you can use GOIO 378 to find the key instruction, use STACK to see how many times the current CS:IP has been called through CALL, and quickly find the key subroutine.
See: PRET
---------------------------------------------------------------------
Trace execution commands
G
G offset
G conditions *New concept*
Execute the program, and can also use the command GO. If the condition is satisfied, pause.
Note: Adding INT3 in the program will not stop the operation of the G command.
Especially recommended: G OFFSET. As long as the IP in the program execution is equal to the set OFFSET, it will stop. You don't have to worry about where the segment address is and whether the code is generated dynamically. As long as you know it will pass there, it will stop. Example:
G 100
G CS:100
G BX
G AH=4C
G AX=0 BX=0 CX=0
G IP>400
See: GS
GO??? *New concept*
Any breakpoint setting command BP??? can be used with GO??? as a one-time breakpoint.
Example: GOREG CS
GOINT 21 AH=30
GOW ES:DI
GOXB CD 13 AH=2
See: GS???
GS
The G command will restore the user screen before execution and save the user screen after execution. Some programs have damaged the BIOS, and the saved screen information cannot be restored normally. TR has not found a good solution to this problem, so a GS command is added. The GS command is equivalent to the G command, but it does not restore the screen.
Equivalent to executing multiple T.
GS???
Same as GO??? command, just does not restore the screen. See: GS GO???
T
Execute an assembly instruction, equivalent to pressing F8.
Note that TR's T command is not the same as other debuggers. TR will not really execute this instruction, but only complete the function of each instruction. If you encounter an instruction that TR cannot recognize, you can only use the TT command.
If an INT instruction is encountered, the T command will not enter the system's interrupt routine, because I think we are generally interested in the traced program, not the system. If the program modifies the INT address, the T command will enter the modified address. If you really need to enter the interrupt, you can use GG, such as
GG @0:21*4 ；Enter INT21
GG OFFSET]
Execute unconditionally, and TR does not control the execution process.
The default segment is CS. If the specified address is specified, then TR inserts a CALL FAR instruction at the specified address, and then JMPs to the application to hope that it can execute to this CALL FAR to be re-controlled by TR. The reason for not using INT3 is to prevent the application from modifying the INT3 interrupt vector.
Because the execution of the program is no longer the interpreted execution of TR at this time, the running speed is normal.
Still hope that CTRL+D can return to TR's control.
P
Execute a procedure (F10). If the current instruction is a CALL or CALL FAR, execute the entire process until it returns. If it is another instruction, it is the same as T.
If you really want to execute until the next instruction, such as encountering a LOOP, use the command PP.
PP
Execute until the next instruction. Equivalent to G IP+ this instruction length.
PRET
Execute the program until the RET, RETF or IRET instruction. Used to quickly exit the subroutine.
See: STACK
TT
Execute an instruction using a single-step interrupt.
Not recommended.
See: int1
AUTOINT1
This is a flag that can be set to ON or OFF. The default is OFF.
When it is ON, if TR encounters an unrecognizable instruction, it will automatically use the INT1 single-step interrupt to execute.
See: TT, INT1
INT1
This is a flag that can be set to ON or OFF. The default is OFF.
When it is ON, TR no longer interprets each instruction, but uses the INT1 single-step interrupt to execute.
Not recommended to use the ON state. If you are sure that TR has an error in the interpretation of a certain instruction, you can continue to execute with the state ON. If you only execute one instruction in this state, use the command TT.
Affected commands: T, G, P, etc.
See: TT, AUTOINT1
AUTOJMP *New concept*
Set whether to automatically jump. If it is ON, during the execution process, TR will not display the JMP instruction, but directly put the instruction after JMP in the original position of the JMP instruction, and add a "—>" symbol in front of the instruction to distinguish it. This can make you easy to stay awake in some cases where there are too many JMPs. If you are not used to it, let it OFF.
The default is ON.
---------------------------------------------------------------------
Breakpoint commands
**** If the breakpoint is only used once, change BP???? to GO???? or GS???? ****
BL
List all breakpoints. Up to 8 breakpoints can be set.
Actually, there are 9 breakpoints, and breakpoint 0 is occupied by the GO series commands.
BC
Clear all breakpoints or specified breakpoints.
BD
DISABLE all or specified breakpoints.
BE
Allow all or specified breakpoints.
BPW segment:offset *New concept*
Monitor memory changes. If the word (WORD) at the specified position changes, pause.
If such a breakpoint is set, TR will make a comparison after each instruction is executed.
BP offset *New concept*
Pause if CS:IP=SEG:OFFSET or IP=OFFSET is executed.
When using BP seg:offset, TR will not insert an INT3 like a normal debugging program. TR never does that, so don't worry that the application will find or destroy the INT3 address and cannot return.
Using BP offset is a good idea, so you don't have to care about how its segment address changes, how much code is twisted before that, and whether the breakpoint area is generated dynamically. You don't have to worry about it. As long as the IP=offset during the program execution process, it will stop.
This breakpoint is actually a special case of the following BP conditions, and can also be written as
BP ip=?? cs=??
TR treats them as a situation for processing.
Idiomatic usage: For COM file unpacking, use BP 100 or directly G 100.
Example: bp cs:200
bp $+20
bp dx
BP ip>200
BP conditions *New concept*
Pause if the specified condition is satisfied, such as
bp ax=1234 ; Stop when ax is equal to 1234H
bp ax=0 bx=0 cx=0 ; Stop when AX, BX, CX are all 0
bp ah=3 dx=80
Three conditions can be set at the same time, and they are only valid if they are all satisfied.
The condition judgment can use =, !=, >, <, >=, <=. The first parameter uses a register, and the second parameter uses an immediate number (if a register is used, the value is taken).
BPREG REG|SEG
Pause if the specified register changes and the condition is satisfied.
Any 16bit general register or segment register can be specified.
It is particularly recommended to use bpreg cs AX=0 DX=0 ES=#, which can generally be used to quickly find the real start of the shell program.
Condition setting refers to BP.
BPXB bytes
Pause if the specified machine code is executed. For example, since the machine code of NOP is 90H, so
BPXB 90
Stop when NOP is encountered during operation. For another example, the machine code of MOV AX,???? is B8????, which can be used
BPXB b8
Other:
BPXB cd ; All interrupts
BPXB 33 C0 ; XOR AX,AX
The specified machine code length should not exceed 8 bytes. Conditions can also be added, such as
BPXB cd 13 ah=3
Condition setting refers to BP.
BPINT intnum
Interrupt breakpoint. Pause if the specified interrupt is executed. For example:
BPINT 21 AH=30
BPINT 13 AX=201 CH>30 DX=1
BPKNL *New concept*
Pause if AX=BX=SI=DI=BP=0, DS=ES=<PSP>, IP=0 or IP=100 or CS has just changed (meaning there has been a JMP FAR or RET FAR). Generally used to find the program kernel with a shell. Note that some shell software does not strictly meet this condition, and this method may miss it. If you have a better idea, please let me know.
The universal method is often not the best method.
---------------------------------------------------------------------
Other commands
EXE1
EXE2
WEXE1
WEXE2
GETKNL
See the following "How to output EXE file"

---------------------------------------------------------------------
How to output EXE file

Sometimes we track a shell-type program. We not only want to be able to track to the real start of the file, but also hope to restore the source file. To this end, TR provides the function of generating an EXE file. Because the COM file is relatively simple, you can write the memory to the file with W. The following focuses on the process of generating the EXE file.
I. Manual completion
First, to write the code in memory into a file, you should know the size of the file. To achieve this purpose, first use the command EXE1 to clear the memory, then use RELOAD to transfer in again, so that the used memory area when writing to the disk is the area to be saved to the file.
Then, use various tracking commands to track the program. For a general shell, use
goreg cs ax=0 bx=0
或 goknl
Several times can find the real file header, use WEXE1 to save the disk, and generate the file MEM1.DAT.
In order to handle the relocation of the EXE file, it is necessary to transfer the program into another memory address for comparison. Use the command EXE2, squeeze out a little memory and clear it, RELOAD.
Still use the above tracking steps to track to the file header, use WEXE2 to save the disk, and generate the file MEM2.DAT.
Use the Q command to exit TR, execute the file MKEXE, automatically read the information in MEM1.DAT and MEM2.DAT, generate the EXE file MEM.EXE, and you can try to execute it!
II. Let TR do it automatically
Use TR to transfer the program in, use the command
GETKNL
Where count is the number of layers to unpack, the default is 1. TR will automatically run:
exe1
reload
goknl count
wexe1
exe2
reload
goknl count
wexe2
q
TR generates two files mem1.dat and mem2.dat and exits. Run mkexe at the DOS prompt
The file mem.exe will be generated, which is the unpacked file!
The reason why MKEXE is made into a separate file instead of being included in TR is to give everyone room for expansion. If you are interested in MKEXE, you can request the source program (C++) of MKEXE.
MEM1.DAT and MEM2.DAT contain a 0x20 long file header:
Offset Size Content
00 word 0xac,0xbc flag
02 word PSP+0x10, which is the starting segment address of the program code in memory
MEM1.DAT and MEM2.DAT should be different to determine relocation
04 word CS-PSP-0x10, the code segment offset, the two files should be equal.
06 word IP value, the two files should be equal.
08 word SS-PSP-0x10, stack segment offset, the two files should be equal.
0a word SP value, the two files should be equal.
0c word The length of the program memory block, in sections (10H) as the unit
dw 09h dup(0) The rest are 0
The memory code follows.
Don't expect the EXE file generated by MKEXE to be exactly the same as the source file, which is impossible. They are the same in function. If you choose the wrong time to generate the EXE, not exactly the original start of the program, you need to add a segment of code to restore each register value.
If the original file has an OVERLAY or checks itself during execution, the new EXE file may not be able to execute directly. You can let MKEXE add a segment of code before the EXE to modify the environment block so that the program thinks that the unpacked program is running. Usage: MKEXE ORGFILE.EXE, the file name does not bring a path. When executing, put the unpacked file and the unpacked file in the same directory to execute.
Special usage: You can open a COM file,
tr mycom.com
exe1
reload
wexe1
exe2
reload
wexe2
q
mkexe
ren mem.exe myexe.exe
This is COM2EXE, which turns a COM file into an EXE file!

I haven't used TR for a long time, and I've forgotten all the commands in it.
I would use it occasionally when there was Win98 before.
In recent years, the machines have all been installed with XP
98 has faded from sight.
Although the software comes with a little simple help
It's more comfortable to read the text help, heh heh.
I searched online,
Almost all are extinct,
Fortunately, there was it in the old hard drive,
Dig it out and post it,
Maybe I can still find it here when I need to find it in the future.

Also, Tr.exe also has the tool mkexe.exe,
I don't know if it can still be found online.
I didn't collect it in my hard drive.

Add 1-3:

Welcome to use the interpretive trace debugging software ---- TR

If you have used DEBUG, SYMDEB, TD (TURBO DEBUG), CV (CODE VIEW) or SOFT-ICE, you should try TR.

TR (will) has all the functions of the above debugging software and supports all their commands. Moreover, the most important thing is that TR puts forward nine new ideas:

I. Interpretive Trace
TR interprets and executes the program. TR is like a CPU, which can read and correctly interpret and execute each line of program code. It does not need to use INT1, INT3, does not need to use 386 debugging registers DR0-DR7, and does not need to enter protected mode (it won't). Theoretically, TR will never be discovered by the application program, and there will never be a program that cannot be traced. Because all programs are handed over to the CPU for interpretation and execution. As long as the instructions recognized by the CPU, TR must also recognize. TR will imagine what the CPU would do in this state, and then I will do the same. If you find that TR is wrong, it means that TR is still to be improved.

Traditional trace methods have too many drawbacks:
(1) Those debugging software that use the single-step interrupt INT1, because they monopolize INT1 and TF, those application programs that need INT1 cannot be traced, and the application program can also detect TF to find out whether it is being traced.
(2) Those debugging software that use the breakpoint interrupt INT3 need to insert the code INT3 (0CCH) in the application program. If the application program destroys the interrupt vector of INT3 or detects its own code, it cannot be traced.
(3) SOFT-ICE does not use the above two methods, but uses 386 hardware interrupts, which is much better. It is not a problem to trace those programs that know nothing about 386. However, the operation of many software requiring EMM386, DPMI, DOS4GW, etc. is greatly restricted, and even cannot be executed under SOFT-ICE at all. More importantly, SOFT-ICE is very easy to be discovered.


In short, the existing trace debugging software all work by using the standard debugging methods provided in the INTEL CPU manual. They are only suitable for debugging those well-behaved programs that are willing to be traced and debugged. If the application program does not cooperate, it cannot be traced. TR is different. TR wants to trace all programs that the CPU can handle, and even TR can nest and trace another TR.
On the other hand, the traditional trace method is to set some breakpoints (no matter what kind of breakpoints), then GO to the application program to execute, and expect the program to run to an appropriate place, and the CPU can generate an interrupt and return to the main program. As for whether it can return or what the program does before returning, only God knows. With the interpretive trace method, the control is always firmly in the hands of TR, monitoring all program processes, and thus can set some highly complex breakpoints.
Interpretive trace is the most essential difference between TR and other debugging software. It is also the fundamental reason for TR's high performance.

II. Batch Processing
Although the concept of batch processing has been around for a long time and is widely used in various software, no one has incorporated it into the debugging software. In TR, you can put the command sequence to be executed into a text file and execute it with the DO command. Of course, there is also an automatic batch processing AUTORUN.TR.

III. G OFFSET
For the G 100 command, everyone knows that it stops when it is executed to 100. Other debugging software thinks that it stops at 100 of the current segment, but TR doesn't care about the segment address. It stops as long as the IP is 100. In this way, a general COM shell can be solved with only one G 100. This function seems simple, but it is extremely useful. With this command, there is no need to remember the complex trace path. Just record the current traced IP, and the next time you press G, you will reach it.

IV. Assembly Instructions as Commands

THKS.
The original article had three sections deleted when saving. Because the main parts needed for debugging are in the following sections.
I didn't expect the person upstairs also has this article. Then it's complete! Hehe...
Since there is the article,
May I ask if there is a complete TR software package?
Can you upload it to share?

The article is from Google, and I don't understand anything about it, heh heh.

But since it's a famous and useful tool, there should be software packages for download on the internet.

You can find version 2.52 online, but it's the shareware version.

It has been uploaded to the cloud disk.
http://lianjiang2004.ys168.com/

Just now I just learned about TR, I'm really out of touch, heh heh.
Used it, TR is really great, with very powerful functions.
Can track many encrypted shells.
I thought TR is so powerful, then how to anti-TR tracking.
Let's talk about the idea.
========================
TR program runs by interpreting the target program.
This small program uses a far jump JMP far XXXX:XXXX to achieve
the transfer of the next statement of the program. The next statement is definitely not
the next code that follows, TR program can't interpret where the next executed
statement is, so it makes a mistake and can't continue tracking.
When TR interprets the jmp far xxxx:xxxx statement, sometimes it
directly jumps to the xxxx:xxxx place to track execution, for example, in
the Xxxx:xxxx place, it tracks to retf, then returns, so
TR won't lose track of the program.
However, sometimes, jmp far xxxx:xxxx, TR doesn't continue
to track what's executed after the jmp, but seems to be near the original place of
jmp far, such as looking for a breakpoint at the next statement, obviously can't find it, after jmp far, it will definitely not
return to the original place.
So, this jmp far xxxx:xxxx address is groped out.
I have had the address after several jmp far, TR still tracked there,
clearly showing a RETF statement, which surprised me.
But after groping and modifying, currently in the program, jumping to the parent process,
it seems that TR judges that Xxxx:xxxx is the system area, then doesn't continue
to track and expects it to return naturally, however, using this point, I don't
return naturally to the original place, it's very easy to make TR lose track.

Actually, jmp far jumps to a retf statement, and places the place to return from retf in the stack in advance (definitely not returning to the next of jmp far, but can deliberately return to a few statements away, or even return to a very far place.) TR faces jmp far and can't know
the next statement is in the stack. Therefore @$!@%@#%，TR is an
interpretive machine, it's not as smart as a human brain, it can't continue to interpret......
In this regard, TR can only use GG to force running.
You know GG directly executes the target program, not interpretively executes.
GG execution also can't set complex breakpoints.
This program doesn't do anti-tracking for directly executing programs, can be combined with many other kinds of anti-tracking code shells that directly run the target program, combined with my
small program, can both anti-TR and anti-tracking of other debugging programs.

Actually, when using jmp far transfer, replace jmp far with
retf, even iret, or call to a very far place, then return not
the next statement of the call statement. If TR can't track the statements one by one after call, then an error will occur. In some cases, can't enter the subroutine after call, then the subroutine plays tricks and doesn't return
the next of call, TR will make a mistake. Or use some other strange
jumps, also will make TR have difficulties when interpreting and running.
=============================
Anti-TR tracking program download
http://upload.cn-dos.net/img/1879.rar

TR is after all loaded into memory under the DOS system, and it is not completely invisible to application programs.
For example, similar to sofo-ice, an application program can load lock.sys after DOS starts.
Loading a locked sys program, no one did this in the actual era of using DOS before,
and I'm just putting forward a purely technical idea.
The application program jumps back and forth irregularly between lock.sys, or calls the lock.sys interface to generate a random jump address. Then for TR, it can no longer continue to interpret and execute. Because TR only interprets each statement of the application program, and for the function of lock.sys, it thinks it is a system call and cannot track each one. Then the random jump address generated by lock.sys cannot be tracked by TR.
Assuming that TR also tracks system calls. That is impossible, and it is easy to cause system crash.
For example, if TR tracks int 21h, it is easy to cause the DOS non-reentrant error,
and also stack errors and so on.
In addition, the application program can also check the relevant memory. If it finds strings of assembly code such as mov, movsb, etc., and also int, cli, sti, that is to say, all strings of assembly code are within the scope of inspection. If there are these strings in the memory, there is no doubt that there is a disassembler and debugger resident in the memory. Because if a debugger has a U command to disassemble, it is impossible not to retain these assembly code strings in the data area. So once these strings are detected, the encryption program refuses to execute, and thus achieves the purpose of anti-debugging and tracking.

This is after all a program from ten years ago. Now, I think that if a virtual machine provides a debugging interface, it will be the best method for debugging, tracking, and anti-encryption. For example, VM workstation, as long as it provides an interface and the values of all registers of the virtual machine, and another interface to access the memory of the virtual machine. Then it is very easy to write a debugging program. You can even debug the BIOS module of the virtual machine. For the program executing in the virtual machine, your debugging program is equivalent to a hardware debugging card plugged into the virtual machine, and the program in the virtual machine is completely unaware of this.

It doesn't have much practical value...

The 2.52 version downloaded online has the mkexe.exe tool. If the landlord needs it, I can pass it to you.

Virtual Machine Debugger: BOCHS
==============
Debugging NTLDR with Bochs

For a PC installed with a Windows NT series operating system, after pressing the power switch, the BIOS first runs in the CPU, then the MBR, then the boot sector, and then NTLDR. ntoskrnl.exe and hal.dll are both loaded by NTLDR. That is to say, when running NTLDR, there are no applications or drivers in the system, so there are no software-based debuggers available. Of course, the all-powerful hardware debugger is possible, but unfortunately we don't have a hardware debugger.

Fortunately, there is Bochs. Bochs is an open-source x86 virtual machine software based on LGPL. Bochs' CPU instructions are completely simulated by itself. The disadvantage of this method is that the speed is relatively slow; the advantage is that it has unparalleled portability: where there is Gcc, there can be Bochs. Even Bochs running on PocketPC already exists.

The current version of Bochs has realized a certain degree of debugging functions. Although it cannot match WinDbg and SoftICE in terms of ease of use and functions, the advantage is also very obvious: for the code running in Bochs, this is a "hardware debugger".

For the Windows version of Bochs, bochsdbg.exe in the installation directory is the debugging version of Bochs. Use it to run the Bochs virtual machine to perform "hardware debugging".

The debugging command style of Bochs is designed according to the GDB habit. This is undoubtedly painful for those who are used to WinDbg. Fortunately, this is an open-source software. If you are not satisfied, you can consider modifying it yourself.

The debugging commands supported by the current version of Bochs (Version 2.1.1) are as follows:



1. There are great errors and omissions between the usage instructions in the Bochs documentation and help information and the real situation. The following command descriptions are supplemented and corrected according to the source code.

2. The numbers such as seg (segment), off (offset), addr (address), val (value) involved can use hexadecimal, decimal or octal, but must be written in the following forms:

Hexadecimal 0xCDEF0123

Octal 01234567

Decimal 123456789

In particular, Bochs cannot automatically recognize hexadecimal numbers and does not accept writing in the form of 12345678h.



c|cont Execute downward, equivalent to "g" in WinDBG.

s|step|stepi Execute step by step, equivalent to "t" in WinDBG. The count defaults to 1.

p|n|next Execute step by step, similar to "p" in WinDBG.

q|quit|exit Exit debugging and close the virtual machine.

Ctrl-C End the execution state and return to the debugger prompt.

Ctrl-D if at empty line on command line, exit

(At least in the Windows version, I didn't find any function of Ctrl-D)



vb|vbreak Set a breakpoint at the virtual address.

lb|lbreak Set a breakpoint at the linear address, equivalent to "bp" in WinDBG.

pb|pbreak|b|break Set a breakpoint at the physical address. (For compatibility with GDB syntax, a "*" can be added in front of the address).

blist Display breakpoint status, equivalent to "bl" in WinDBG.

bpd|bpe Disable/enable breakpoint, "be" and "bd" in WinDBG. num is the breakpoint number, which can be queried with the blist command.

d|del|delete Delete breakpoint, equivalent to "bc" in WinDBG. mum is the breakpoint number, which can be queried with the blist command.



watch read Set a read breakpoint.

watch write Set a write breakpoint.

unwatch read Clear the read breakpoint.

unwatch write Clear the write breakpoint.

watch Display all current read-write breakpoints.

unwatch Clear all current read-write breakpoints.

watch stop|continue Switch option, set to interrupt when encountering a read-write breakpoint or display but continue running.




x /nuf Display the content of the linear address

xp /nuf Display the content of the physical address

n Number of units to display

u Size of each display unit. u can be one of the following:

b BYTE

h WORD

w DWORD

g DWORD64

Note: This naming method is according to the GDB habit, not according to the inter specification.

f Display format. f can be one of the following:

x Display in hexadecimal

d Display in decimal

u Display in unsigned decimal

o Display in octal

t Display in binary

c Display as a character

n, f, u are optional parameters. If not specified, u defaults to w and f defaults to x. If the x or xp command is used before, it will be according to the values used in the last x or xp command. n defaults to 1. addr is also an optional parameter. If not specified, addr is 0. If the x or xp command is used before and n=i is specified, then when executed again, n defaults to i+1.

setpmem Set the content of a physical memory address.

It should be noted that at most one DWORD can be set at a time:

This is okay:

<bochs:1> setpmem 0x00000000 0x4 0x11223344

<bochs:2> x /4 0x00000000

:

0x00000000 <bogus+ 0>: 0x11223344 0x00000000 0x00000000 0x00000000

This is also okay:

<bochs:1> setpmem 0x00000000 0x2 0x11223344

<bochs:2> x /4 0x00000000

:

0x00000000 <bogus+ 0>: 0x00003344 0x00000000 0x00000000 0x00000000

Or:

<bochs:1> setpmem 0x00000000 0x1 0x20

<bochs:2> x /4 0x00000000

:

0x00000000 <bogus+ 0>: 0x00000020 0x00000000 0x00000000 0x00000000

The following practices will all lead to errors:

<bochs:1> setpmem 0x00000000 0x3 0x112233

Error: setpmem: bad length value = 3

<bochs:2> setpmem 0x00000000 0x8 0x11223344

Error: setpmem: bad length value = 8

crc Display the CRC of the data between the physical addresses start and end.




set $reg = val Set the value of the register. The registers that can be set in the current version include:

eax ecx edx ebx esp ebp esi edi

Temporarily cannot be set:

eflags cs ss ds es fs gs

r|reg|registers reg = val The same as above.

dump_cpu Display complete CPU information.

set_cpu Set CPU status. Here, all CPU status that can be displayed by dump_cpu can be set.



u|disas|disassemble

Disassemble the code between the physical addresses start and end. If no parameters are specified, the code pointed to by the current EIP is disassembled. num is an optional parameter, specifying the amount of code to process.

set $disassemble_size = 0|16|32 The $disassemble_size variable specifies the segment size used for disassembly.

set $auto_disassemble = 0|1 The $auto_disassemble determines whether to disassemble the current instruction when interrupted (for example, when encountering a breakpoint, Ctrl-C, etc.) each time.



trace-on|trace-off When the Tracing switch is turned on, the disassembled result will be displayed for each executed instruction.

ptime Display the number of instructions executed by Bochs since this run.

sb Interrupt after executing val more instructions. val is a 64-bit integer, ending with L, such as "1000L"

sba Interrupt when executing to the val-th instruction since this run of Bochs. val is a 64-bit integer, ending with L, such as "1000L"

modebp Set to interrupt when switching to v86 mode.

record Record the entered debugging instructions to a file. The file name must contain quotes.

playback Play back the recorded file of record. The file name must contain quotes.

print-stack Display the stack. num defaults to 16, indicating the number of lines to print.

?|calc Similar to the "?" command in WinDBG, calculate the value of the expression.

load-symbols filename

Load the symbol file. If the "global" keyword is set, the symbol is valid for all contexts. offset will be added to all symbol addresses by default. The format of the symbol file is: "%x %s".



info program Display the execution situation of the program.

info registers|reg|r Display register information.

info pb|pbreak|b|break Equivalent to blist

info dirty Display the page address of the dirty page.

info cpu Display the values of all CPU registers.

info fpu Display the values of all FPU registers.

info idt Display IDT.

info gdt Display GDT.

info ldt Display LDT.

info tss Display TSS.

info pic Display PIC.

info ivt Display IVT.

info flags Display the status register.

info cr Display CR series registers.

info symbols Display symbol information.

info ne2k|ne2000 Display the information of the virtual ne2k network card.


After understanding the debugging commands, you can start the debugging work of NTLDR. The following work is implemented on the Windows version of Bochs 2.1.1. We assume that the reader understands the basic usage methods and terms of Bochs.

First, install a Windows NT 4 Bochs virtual machine.

1. Create a virtual hard disk.

Run bximage.exe to create a 500M, flat-mode virtual hard disk file "C.img".

2. Create an ISO file "nt.iso" of the Windows NT installation CD.

If you plan to install directly from the CD, you can skip this step.

3. Create bochsrc.txt

The content can refer to the following:

###############################################################

megs: 32

romimage: file=$BXSHARE\BIOS-bochs-latest, address=0xf0000

vgaromimage: $BXSHARE\VGABIOS-lgpl-latest

ata0: enabled=1, ioaddr1=0x1f0, ioaddr2=0x3f0, irq=14

ata0-master: type=disk, path="C.img", mode=flat, cylinders=1015, heads=16, spt=63

ata0-slave: type=cdrom, path="nt.iso", status=inserted

newharddrivesupport: enabled=1

boot: cdrom

log: nul

mouse: enabled=1

clock: sync=realtime, time0=local

###############################################################

4. Create start.bat

The content is as follows:

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

::Assuming your Bochs is installed in D:\Program\Bochs

set BXSHARE=D:\Program\Bochs

%BXSHARE%\bochs.exe -q -f bochsrc.txt

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

Put C.img, nt.iso, bochsrc.txt, start.bat in the same directory, run start.bat, and install Windows NT.

In fact, if you only want to debug MBR, boot sector and NTLDR, there is no need to install a complete operating system. As long as there are files such as ntldr in the root directory. The reason why Windows NT is installed here instead of Windows 2000 or a higher version is, on the one hand, considering the speed issue, and on the other hand, Windows NT can be ensured to be installed smoothly on Bochs. If you want to debug the NTLDR of Windows 2000/XP/2003, just replace the ntldr file of these operating systems with that of Windows NT.

After installing Windows NT, you can debug NTLDR. Replace "bochs.exe" in start.bat with "bochsdbg.exe". Then run start.bat.

The following is the screen copy of the operation:

========================================================================

Bochs x86 Emulator 2.1.1

February 08, 2004

========================================================================

00000000000i reading configuration from bochsrc.txt

00000000000i installing win32 module as the Bochs GUI

00000000000i Warning: no rc file specified.

00000000000i using log file nul

Next at t=0 //Start bochsdbg.exe, and will automatically stop at the first instruction of Bios.

(0) context not implemented because BX_HAVE_HASH_MAP=0

f000:fff0 (unk. ctxt): jmp f000:e05b ; ea5be000f0

<bochs:1> b 0x00007c00 //MBR and boot sector will be loaded at 0000:7c00.

<bochs:2> c

(0) Breakpoint 1, 0x7c00 in ?? () //The first time it will be interrupted on MBR.

Next at t=772567

(0) 0000:7c00 (unk. ctxt): cli ; fa

<bochs:3> c

(0) Breakpoint 1, 0x7c00 in ?? () //The second time it will be interrupted on the boot sector.

Next at t=773872

(0) 0000:7c00 (unk. ctxt): jmp 0x7c5d ; eb5b

<bochs:4>b 0x00020000 //ntldr will be loaded at 2000:0000. In fact, whether it is CDFS, NTFS or FAT,

//Windows loads the boot file at this address.

<bochs:5> c

(0) Breakpoint 2, 0x20000 in ?? () //Break down at the first instruction of NTLDR, and can start debugging.

Next at t=861712

(0) 2000:0000 (unk. ctxt): jmp 0x1f6 ; e9f301


Now, we can, like God overlooking the masses, watch the operating system start up step by step, everything is in sight, and even see the situation where the real mode switches to the protected mode during the system startup process:

(0). 2000:0247 (unk. ctxt): opsize or eax, 0x1 ; 6683c801

(0). 2000:024b (unk. ctxt): mov cr0, eax ; 0f22c0

(0). 2000:0000024e (unk. ctxt): xchg bx, bx ; 87db

(0). 2000:00000250 (unk. ctxt): jmp 0x253 ; eb01

(0). 2000:00000253 (unk. ctxt): push 0x58 ; 6a58

(0). 2000:00000255 (unk. ctxt): push 0x259 ; 685902

(0). 2000:00000258 (unk. ctxt): retf ; cb

<b>today is my last working day in foxconn</b>