comment $


       ---------------------------------------------------
	 Bypassing the breakpoints with file "streams"
       ---------------------------------------------------
	 written by Piotr Bania <bania.piotr@gmail.com>
	         http://www.piotrbania.com




 About
 -----

 First of all i dunno if this issue is known issue or not, so i will write
 about it as it is new (forgive me if im wrong). Anyway shortly, we
 have 3 different types of breakpoints:

 1) BPX (int3)
 2) Memory breakpoints done by using page rights modifications bla bla.
 3) Hardware breakpoints (debug registers)

 
 I will not speak here about point 1 (BPX'es). Also consider the fact
 point 2 (memory breakpoints) are already known to be detected by
 page rights checks.

 Anyway, there are often a situations when attacker is trying to capture
 buffer data (if you ever were resarching some vulnerabilities you prolly
 know what i mean). So this is shortly accomplished by two scenarios,
 usually we put a breakpoint on the buffer in what we are interrested in.
 Sometimes it is a memory breakpoint, sometimes it is a hardware breakpoint,
 depends on situation. 	


 So while researching a brand new vulnerability which you probably will see
 someday, i got a bit confused. I was tracing the heap memory, and i found
 a leakage. So i simply traced the allocation point of the block, and then
 i've put a breakpoint on the begining of the block (firstly it was
 a memory breakpoint). And here it comes the confusion point, the program
 didnt work - i mean it didnt reach the crash point. I got bit confused,
 i tried with HARDWARE breakpoints, the memory was corrupted but whats
 more funny the breakpoint didnt work (but the block changed). After 
 spending few minutes looking at my dirty shoes i decided to try with 
 my brand cool tracer. And guess what, the memory was broken because of 
 ReadFile, where the input buffer was my corrupted block.

 
 What is the conlusion?
 First of all, you can bypass the hardware memory breakpoints by reading
 data directly from a file. Secondly, you can detect memory breakpoints.
 Its really funny when you write to the protected data, and none of this
 breakpoints says u really write there and the memory is changed.



 Just like always, more short thoughts...


      			  	Save us, from what we have become tonight
					       eyes, glazed with distrust
        				       No sense of wrong or right
									.
 

 
$






include my_macro.inc


push 	255
push 	offset fname
push 	0
@callx 	GetModuleFileNameA


mov	eax,offset buff		; set a breakpoint on the EAX area
int	3			; try HARDWARE breakpoints and
				; memory breakpoints and see what you got


push 	OF_READ
call 	a1
fname	db	255 dup (0)
a1:	
@callx	_lopen
inc	eax
test	eax,eax
jz	exit			; HFILE_ERROR, fucked up

xchg	ebx,eax
dec	ebx
push	512
push	offset buff
push 	ebx
@callx	_lread			; just a sample protected memory modification
inc	eax			; probably ERROR_NOACCESS (000003E6) on normal memory bps :)
test	eax,eax
jz	stfu


int	3			; this is stored to check breakpoints state
				; look they were not alerted and the data:)
				; was written




push	ebx
@callx	_lclose



exit:
	push 0
	@callx ExitProcess


stfu:
	push 	0
	@pushsz	"Eat your breakpoints"
	@pushsz	"Eat your breakpoints"
	push 	0
	@callx 	MessageBoxA
	jmp exit



buff	db	512 dup (0)



end start