OpenRCE_adityaks
November 24th, 2007, 18:50
Analogy
This post just provide a glimpse over the Hardware breakpoint analogy. As good discussion is going on forums regarding it.Lets elaborate it a bit. The hardware breakpoints are crucial from system point of view whenever a user mode breakpoints have to be set from kernel debugger. Usually advised for setting paged out operations. Precisely it is commonly undertaken a processor issues INT 3 whenever a Conditional Breakpoint is encountered. But as far as Hardware Breakpoint is concerned things are bit different.In this basically an address is trapped by the processor whenever a relative operation is processed using that address in a system. The operations can be:
1. Read Operation.
2. Write Operation.
3. Execute Operation.
The processor traps the address using these operations. This entirely depends on the type of breakpoint specifications are and how it has been set. INT 6 is required for system hardware breakpoints not including the peripheral components.The hardware breakpoints are circumvented on underlined points:
1. Pre fetching Instruction
In this primarily an address is fetched by an instruction early. It means if a stringent pre fetch occurs on the breakpoint address the breakpoint is going to be executed not caring for the instruction to be completed. This is because dynamic call has been undertaken by system on that address which is set for Hardware Breakpoint. Hence it executes. The pre fetching states a breakpoint can be executed whether an instruction is completed or not if pre fetching occurs.
Example: A breakpoint can be executed even if a loop is not over.
2. Overhead Processing.
As we know the hardware breakpoints require active inclusion of CPU system. It depends on the speeding power of a CPU and the time taken to execute a Hardware Breakpoint. The timing limits come to play.Usually a CPU gets in hang state or debugger "BUSY" state for long time.It further reaches to Processor Hogging state. So less overhead more reliable execution of hardware breakpoints.
3. Hierarchical Function Calls.
The functions are interdependent over each other.As such there is no specific hierarchy of calling that functions whenever LINKER encountered them. Most of the time it is hard to find the direct flow of functions in memory. The difference occurs in Source Code and Linking code. In that cases it would be better if proper disassembly is done prior to set a breakpoint.
4. Discreet Interrupts
As the Hardware Breakpoint is to be set , so it requires chip registers mainly. It has been advised to use INT 6 for standard system hardware breakpoints. If peripheral device is undertaken the interrupt number should be INT 13 in executing breakpoints. This is considered to be as good practice when breakpoints are to be structured differentially.
Case Layout:
If a reverse engineer is working at kernel level debugger. The code requires a breakpoint to be set in a function that is specified in a user mode then Hardware Breakpoints are preferred. Like If some one has to call a function is Lsass.exe for password validation pr security oriented from kernel level then hardware breakpoint is best in these cases.
kd> g <Function name> [Breakpoint Stats] [ "g" , @$ra [return address] ,"ba" ,"gc"]
The breakpoint parameters are defined above.The breakpoint can be simulated in this way by using these parameters. For loops pre fetching can be encountered and breakpoints(hardware) depends on it. So overall it is good practice to use Hardware Breakpoints.
Thats all
Views.
Your views are welcomed!.
Cheers
0kn0ck
https://www.openrce.org/blog/view/912/Hardware_Breakpoints_:_Stature
This post just provide a glimpse over the Hardware breakpoint analogy. As good discussion is going on forums regarding it.Lets elaborate it a bit. The hardware breakpoints are crucial from system point of view whenever a user mode breakpoints have to be set from kernel debugger. Usually advised for setting paged out operations. Precisely it is commonly undertaken a processor issues INT 3 whenever a Conditional Breakpoint is encountered. But as far as Hardware Breakpoint is concerned things are bit different.In this basically an address is trapped by the processor whenever a relative operation is processed using that address in a system. The operations can be:
1. Read Operation.
2. Write Operation.
3. Execute Operation.
The processor traps the address using these operations. This entirely depends on the type of breakpoint specifications are and how it has been set. INT 6 is required for system hardware breakpoints not including the peripheral components.The hardware breakpoints are circumvented on underlined points:
1. Pre fetching Instruction
In this primarily an address is fetched by an instruction early. It means if a stringent pre fetch occurs on the breakpoint address the breakpoint is going to be executed not caring for the instruction to be completed. This is because dynamic call has been undertaken by system on that address which is set for Hardware Breakpoint. Hence it executes. The pre fetching states a breakpoint can be executed whether an instruction is completed or not if pre fetching occurs.
Example: A breakpoint can be executed even if a loop is not over.
2. Overhead Processing.
As we know the hardware breakpoints require active inclusion of CPU system. It depends on the speeding power of a CPU and the time taken to execute a Hardware Breakpoint. The timing limits come to play.Usually a CPU gets in hang state or debugger "BUSY" state for long time.It further reaches to Processor Hogging state. So less overhead more reliable execution of hardware breakpoints.
3. Hierarchical Function Calls.
The functions are interdependent over each other.As such there is no specific hierarchy of calling that functions whenever LINKER encountered them. Most of the time it is hard to find the direct flow of functions in memory. The difference occurs in Source Code and Linking code. In that cases it would be better if proper disassembly is done prior to set a breakpoint.
4. Discreet Interrupts
As the Hardware Breakpoint is to be set , so it requires chip registers mainly. It has been advised to use INT 6 for standard system hardware breakpoints. If peripheral device is undertaken the interrupt number should be INT 13 in executing breakpoints. This is considered to be as good practice when breakpoints are to be structured differentially.
Case Layout:
If a reverse engineer is working at kernel level debugger. The code requires a breakpoint to be set in a function that is specified in a user mode then Hardware Breakpoints are preferred. Like If some one has to call a function is Lsass.exe for password validation pr security oriented from kernel level then hardware breakpoint is best in these cases.
kd> g <Function name> [Breakpoint Stats] [ "g" , @$ra [return address] ,"ba" ,"gc"]
The breakpoint parameters are defined above.The breakpoint can be simulated in this way by using these parameters. For loops pre fetching can be encountered and breakpoints(hardware) depends on it. So overall it is good practice to use Hardware Breakpoints.
Thats all
Views.
Your views are welcomed!.
Cheers
0kn0ck
https://www.openrce.org/blog/view/912/Hardware_Breakpoints_:_Stature