Determining Start Point Of Doc Check Routine

What you need to do is find the start of the actual doc check. Most programs are written with Top/Down design in mind. In other words, each function is a collection of other functions. For example, the doc check procedure may make calls to several other procedures as shown in the following flowchart of a typical doc check. (figure 1) 

No. DOC CHECK

1. Clear screen
2. Display locator info
3. Get input
4. Clear screen
5. Check input
Figure 1

As it is obvious, by calling the doc check procedure, you actually call 5 others (and in turn, the doc check may be a part of another procedure). Now, a way we can tell we are inside the doc check procedure is by waiting for an individual step to occur. For example if the program displays the locator info but returns to the debugger (SoftIce) instead of waiting for input you can assume that you are in the doc check routine.

The object now, is to simply get back to the top. To do this, just keep jumping over instructions until you reach a RET, RETF or IRET command. You can trace through this and you’ll be at the next instruction after the call to the doc check routine. You should write down this address. If you have to break out in the input routine, you basically do the same thing; only this time you know that you are already in the doc check.

At this point, you ‘ll have to figure out the input routine. This is usually easier than it sounds and it’s only becoming difficult when dealing with event-driven input like mouse input. Your best bet is to try to find a loop. Now, depending on how the program gets it’s input, you will end up breaking out in two places. If the program uses a BIOS/DOS routine that sits and waits for input, you will break out inside these routines. If it uses a BIOS/DOS routine that does not wait for input such as INT 16h function 1, then you will usually be inside the actual program.

You can make a pretty good guess at where you are, depending on your current segment address. If you are in a low segment or your segment is F000h, then you are probably in DOS or BIOS. If not, you are in the program. What you need to do, is look for the program to loop back on itself. For example, if you drop out in to the BIOS keyboard routine, you should see code similar to figure 2. 

xxxx:E853 STI
xxxx:E854 HLT
xxxx:E855 JMP E857
xxxx:E857 JMP E859
xxxx:E859 JMP E85B

xxxx:E85B CLI
xxxx:E85C MOV AX,[SI]
xxxx:E85E CMP AX,[SI+2]
xxxx:E861 JZ E853
Figure 2

Let’s analyze the code shown in figure 2. The 3 jumps (E855 to E859) are simply timing jumps. The last 3 instructions are the work-stuff. What they are doing is compare the head and tail length bytes for the keyboard buffer. If they are equal (i.e. no key was pressed) then the program re-executes the loop.

This is exactly what we are looking for. Some sort of loop in the program. Remember to avoid this type of code in order not to be traced easily by crackers. If this part of code is traced then all that’s left is executing the code (set a breakpoint at F000:E863). If we start jumping through code we could find a screen saying "You have entered the wrong/right code". Control is returned to the debugger and we can follow the instructions back to the top of the doc check routine by finding RET,RETF or IRET instructions.

Return