OpenRCE

📚 OpenRCE is preserved as a read-only archive. Launched at RECon Montreal in 2005. Registration and posting are disabled.

About Articles Book Store Distributed RCE Downloads Event Calendar Forums Live Discussion Reference Library RSS Feeds Search Users What's New

Customize Theme

Flag: Tornado! Hurricane!

Created: Wednesday, October 10 2007 07:33.22 CDT

Modified: Thursday, November 22 2007 00:41.51 CST

Printer Friendly ...

Hardware Breakpoints : Stature

Author: adityaks

# Views: 8648

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

There are 31,328 total registered users.

Recently Created Topics
[help] Unpacking VMP...	Mar/12
Reverse Engineering ...	Jul/06
let 'IDAPython' impo...	Sep/24
set 'IDAPython' as t...	Sep/24
GuessType return une...	Sep/20
About retrieving the...	Sep/07
How to find specific...	Aug/15
How to get data depe...	Jul/07
Identify RVA data in...	May/06
Question about memor...	Dec/12

Recent Forum Posts
Finding the procedur...	rolEYder
Question about debbu...	rolEYder
Identify RVA data in...	sohlow
let 'IDAPython' impo...	sohlow
How to find specific...	hackgreti
Problem with ollydbg	sh3dow
How can I write olly...	sh3dow
New LoadMAP plugin v...	mefisto...
Intel pin in loaded ...	djnemo
OOP_RE tool available?	Bl4ckm4n

Recent Blog Entries
	halsten	Mar/14
Breaking IonCUBE VM
	oleavr	Oct/24
Anatomy of a code tracer
	hasherezade	Sep/24
IAT Patcher - new tool for ...
	oleavr	Aug/27
CryptoShark: code tracer ba...
	oleavr	Jun/25
Build a debugger in 5 minutes
More ...

Recent Blog Comments
	nieo on:	Mar/22
IAT Patcher - new tool for ...
	djnemo on:	Nov/17
Kernel debugger vs user mod...
	acel on:	Nov/14
Kernel debugger vs user mod...
	pedram on:	Dec/21
frida.github.io: scriptable...
	capadleman on:	Jun/19
Using NtCreateThreadEx for ...
More ...

Imagery

SoySauce Blueprint
Jun 6, 2008

[+] expand

View Gallery (11) / Submit