Fuzzing and crash dump analysis
From crash dump to working exploit lab in WinDBG
Here is a very basic program to help us explore our exploit environment. The
basic_vuln program reads in a binary ﬁle and displays the ﬁrst 64 hexadecimal
bytes from that ﬁle. The program prints various meta data such as the location of
variables and functions in the process address space. This meta information will
help simplify the exploitation process as we are learning.
There is an obvious overﬂow in line 27 where the fread call reads 128 bytes into a 64 byte
Buﬀer. This leads to a traditonal stack overﬂow, among other possibilites.
In this case we create a ﬁle of 128 bytes of 0xdeadbeef. This will overﬂow the 64 byte
buﬀer in the hexdump_ﬁle function, smashing the stack, and generating a crash dump.
First*we*set*a*break*point*before*the*fread*call*in*hexdump_file*that*will*ul)mately*corrupt* the*stack,*so*we*can*check*out*the*stack*before*its*destroyed.*In*this*case*I*switch*to*source* mode,*open*up*the*disassembly*window,*put*my*cursor*on*the*push*ecx*before*the*call*to* fread,*then*tell*windbg*to*run*to*cursor.*Once*the*break*point*before*fread*is*hit,*I*can* inspect*the*saved*frame*pointer*and*saved*return*address*on*the*stack*with*ddebp*L2.* Everything*looks*sane*at*this*point*since*the*stack*hasn’t*been*smashed.*
Leave a Reply.