From Collaborative RCE Tool Library
16 bit and DOS Tracers
Tracers for those good old DOS programs (and other 16-bit x86 code).
| Tool name: | TR |
| ||
|---|---|---|---|---|
| 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! | |||
| Also listed in: | (Not listed in any other category) | |||
| More details: | Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry) | |||
Feed containing all updates and additions for this category.
Feed containing all updates and additions for this category, including sub-categories.
