From Collaborative RCE Tool Library

Jump to: navigation, search

TR

Tool name: TR
Rating: 0.0 (0 votes)
Author: Liu Taotao                        
Website: N/A
Current version: 2.52
Last updated: November 30, 1998
Direct D/L link: Locally archived copy
License type: Shareware
Description: Advanced tracer for 16 bit x86 code (DOS programs).

From readme:

If you have used DEBUG, SYMDEB, TD (Turbo Debugger), CV (CodeView) or SoftICE, you should try TR which has more powerful functions than debuggers mentioned above.

TR(tracer) is a debugger based on the CPU simulation technology.

The main features are:

1. Interpret Mode

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



TR runs a program by interpreting its code just like a REAL Intel CPU

would, step by step. TR understands every CPU opcode and will give the

correct result, without INT1, INT3, DR0-DR8, or protected mode.

Theoretically, TR will never be found by any program which is

traced, and you can never find a program which can't be traced :-)





Traditional debuggers or tracers have too many shortages:



(1) Using INT1 and the Trap Flag



Because they use INT1 and TF to step the program, so it's easy

to cheat and detect it!



(2) Using INT3



These debuggers insert INT3(CCh) into the program's code after every

instruction. If the program destroys the INT3 vector or tests

itself, the tracer would not work well :-(



(3) SoftICE doesn't use above two methods, but uses 386 hardware

interrupts instead. SoftICE is very strong but so easy to be

found :(



Overall, traditional debuggers & tracers trace the program using standard

tracing methods which can be found in INTEL's CPU manual. They could

only trace those programs which haven't any anti-debug code. If the

program won't cooperate, they all cannot work well :-( But TR will

trace all the programs that the CPU can deal with, even another TR

session.



On the other hand, traditional debuggers or tracers simply insert a

breakpoint into the program and wait until they catch the control back.

They don't know whether they will get control back or what the program

intends to do. TR runs the program in interpret mode, it controls all

things absolutely. Just because of that, TR can set more and more

complex breakpoints.



Interpret Run is the main difference between TR and all other

debuggers, and this is also why TR has a higher performance.



2.Batch File

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



Although batch is not a new word to you, you can find no one using it

in a debugger. In TR, you can put all your commands in a text file and

use it just like you execute a DOS batch file. TR as well has a special

batch file named "AUTORUN.TR". Just like its name, this file can be

executed automatically every time you start TR.



3.Magic Offset

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



Everyone is used to the "G 100" command which means run and stop at

address CS:100. In general, debuggers do it like this: insert a

breakpoint(INT3/CC) at CS:100 and GO the program. When the CPU meets

the INT3, the program will be stopped. So, the debuggers can only set a

breakpoint at current CS and offset 100. But not TR! TR can stop the

program at every offset 100! What does this mean? It means when IP=100,

the program will be stopped! We call this Magic Offset. Hmm, what's the

use? Too many! Think by yourself :-) One simplest and direct usage is

use "G 100" you can *UNPACK* all .COM files!



4.Assembly Language Command

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



It's a good idea that you can use ASM opcode in your debug environment.

You can accomplish your wish in TR! You may use either "R AX 001A" or

"MOV AX, 001A". Both do the same thing. Remember, all assembly opcode

can be used in TR, e.g. "CLI", "MOV [WORD 1234], 4567", "IN AL,21"...





5.Add Comments During Tracing

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



"CALL 7FDE" is not good compared to "CALL OPEN_FILE". But most tracers

must face such opcodes. Even if you have known what the procedure

would do, you could only write it down on paper. Now TR can write

your comments directly into the program and saved them into another file

automatically. From now on all programs are easy for understand. TR will

as well display comments for most INT21 function calls automatically for

you.



6.Automatic Jump

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



Many protectors use lots of JMP codes to make the decryptor of their

protection unreadable. In most situations, you can only see some JMPs in

the code window. At the target address, in general, you can't see the

correct disassemble opcode because the protect programs likely insert

some DATA in front of that address, so, it's difficult to understand

these programs. With the Automatic Jump feature, TR displays the correct

code at the JMP address in code window instead of displaying a "JMP

xxxx". This way you can see the correct codes sequence but not lots of

jumps: the code is easy to read!





7.Log

=====



TR could save all CS:IP on interpret-run. This makes it possible to

analyse the program easily. If the program exits with an error, you can

find the problem by backtracing your LOG. Command 'LOGPRO' can get all

the key opcode program run. The program will have no secret after you

LOG it. Refer to the commands LOG, LOGS, VLOG and LOGPRO.



8.Write EXE file from memory

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



You can find many universal unpackers on the net, but what would you do

if they tell you "I can't unpack it"? Unpack functions should be in

debuggers. TR's MKEXE function let you make EXE file easy!



9.Various Complex breakpoints, One-time breakpoints

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



All other debuggers' breakpoints are what INTEL prepared. They cannot

fit the need of modern trace technology. TR has many revolutionary

breakpoints:



(1) BP conditions

Conditional break-point. ex.:



BP IP>4000

BP ah=2 dl=80 ch>30



(2) BPINT intnum [conditions]

Interrupt break-point.



(3) BPXB bytes [conditions]

Break-point if ??? code is encountered. For example, "MOV AX,????"

is assembled in HEX "B8????", so you can use



BPXB b8



to break on all "mov ax,????" opcodes. Other examples:



BPXB cd ;all interrupt

BPXB 33 c0 ;xor ax,ax



(4) BPREG REG|SEG [conditions]

Break if the given register changes. You can use



BPREG cs



to get all code segment changes (jmp far,retf...). As well, you can

use something like



BPREG cs ax=0 es=# ;# means PSP seg



to get the kernel of a shelled program.



(5) BPM [seg:]offset

Break if specified memory is accessed.



BPM 20



will stop at 'mov ax,[20]'.



(6) BPW SEG:OFFSET

Break-point if memory changes. Some opcode's changing memory

could only be found by repeatedly compare.



(7) BPIO port [conditions]



(8) BPKNL [count]

Break-point to find new program kernel.



The most important is: if you only use one break-point onetime,

you can change the break-point command 'BP???' to 'GO???' to run.

By using this one-time break-point, you need not to set any

break-point.



These break-point function make it more and more easy to track a

program. You need not to do any hard work!



TR is a real tracing, tracking, debug program. We have DEBUG,SYMDEB,

TD,CV,S-ICE, but they are all not such real tracing debug programs.

DEBUG & SYMDEB aren't, because I think a real debug software should

be full-screen. TD cannot process command line input. No mouse

clicks could replace a command line like 'F CS:DX,DX+CX 00'. In

DEBUG you can use 'L 100 0 0 1' to check floopy boot, and use

'L 400' or 'W 400' to load a program to memory or write memory to

file. In SYMDEB you could use '>' to save the unassemble result.

All these useful functions cannot be found in another debug program.

I think TD & CV are not standalone debug programs. They just debug

their C program. S-ICE is great! But it looks like that 386CPU's

debug function is for S-ICE, and that S-ICE is just a demo of this

function. Only TR does what you think, rises 9 great new ideals in

tracing technology, for the first time make TRACING an easy job.

TR is a real tracing debug program!
Related URLs: No related URLs have been submitted for this tool yet


RSS feed Feed containing all updates for this tool.

You are welcome to add your own useful notes about this tool, for others to see!



If you find that any information for the tool above is missing, outdated or incorrect, please edit it!
(please also edit it if you think it fits well in some additional category, since this can also be controlled)


Views
Category Navigation Tree
   Code Coverage Tools  (13)
   Code Ripping Tools  (2)
   Helper Tools  (3)
   Hex Editors  (13)
   Memory Patchers  (7)
   Packers  (20)
   Profiler Tools  (11)
   String Finders  (10)
   Tool Hiding Tools  (7)
   Tracers  (22)
   .NET Tracers  (4)
   Needs New Category  (3)