Hi,
i have some Question about Sice and others.

So, who does sice set a breakpoint into a target ?
Must Sice really set a code into the target adress or happens it on other a way?
How looks it by tracing ?
Is there sice setting breakpoint after breakpoint ( surely by refeshing the old code after left the instuction before )?


Or can a target be traced step by step without insert any code from the debugger ?


Greetings from germany

Juergen

Hi, SI just sets a breakpoint on the target or on API calls. I don't know how SI sets a breakpoint, but I don't think it adds code to the program.
When tracing the program, it is highlighted (at least in version 3.2).
U can trace the target while its running. When you press F10 while you are in the code, you will be able to follow it step by step.

Hi,
Technically speaking, Sice does insert a code. For execution type (bpx) breakpoints, an int 3 command is set at the target address. This interrupt command signals that a breakpoint has occured, halts program execution, and pops up Sice at the target location.



To my knowledge, the int 3 is an internal interrupt and is essential for halting the program execution via breakpoints. I don't think it would be possible to trace a target without it. Fortunately, the operating system handles these messy details and we don't need to worry about them when reversing a target.

Hope this answers your question.

Regards,
Clandestiny

It does. At the BPX address a Hex CC (int3) byte is written. When the interrupt is called and trapped by SoftIce it takes control and its screen pops up. The first thing Sice does is to replace the CC in the screen with the original byte from the code of the app so you don't see it.However, in memory mapped programs, like the ones generated by Delphi, the temporary CC code gets actually written in the DISK of the code producing surprising results if you don't dissable the BPXs before quiting the application.








I might be wrong about this but there is a CPU flag called T(rap) which is clear (0) most of the time. Debuggers change that flag to 1, what tells the CPU: "execute the next instruction, the return the control to me". So debuggers don't need to constantly modify the code ahead of them, the hardware has a service that handles it for them. (this was truth for the debugger used by MSDOS, when I was young. I do not know if the more advanced , multitasking, CPU have a different approach. I doubt it, because when Sice is active, not even the system Clock ticks: notice how your system time gets behind when you use Sice).




More expert explanations welcome.

Bratsch

It does. At the BPX address a Hex CC (int3) byte is written. When the interrupt is called and trapped by SoftIce it takes control and its screen pops up. The first thing Sice does is to replace the CC in the screen with the original byte from the code of the app so you don't see it.However, in memory mapped programs, like the ones generated by Delphi, the temporary CC code gets actually written in the DISK of the code producing surprising results if you don't dissable the BPXs before quiting the application.








I might be wrong about this but there is a CPU flag called T(rap) which is clear (0) most of the time. Debuggers change that flag to 1, what tells the CPU: "execute the next instruction, the return the control to me". So debuggers don't need to constantly modify the code ahead of them, the hardware has a service that handles it for them. (this was truth for the debugger used by MSDOS, when I was young. I do not know if the more advanced , multitasking, CPU have a different approach. I doubt it, because when Sice is active, not even the system Clock ticks: notice how your system time gets behind when you use Sice).




More expert explanations welcome.

Bratsch