0

Crash analysis:

Given a large set of crashes, all resulting from access violations, is it possible to (with or without access to symbols and source code) programmatically determine whether the crashes resulted from a bad read from crashes caused by a bad write? My ultimate goal is distinguish buffer overruns from other crashing conditions.

Even more specifically, I would like to be able to separate corruptions of EIP (or similar instruction pointers in other architectures) from other forms of crashes so that I might better separate buffer overflows from a corpus of crashing input files.

Additionally:

What tool would you use to instrument this or otherwise automate this process?

I suspect that this is not possible since the ultimate source of the crash will be dereferencing a bad address in all cases. Walking back, maybe it is possible to mark all memory allocated to buffers and check whether the crashing address is within a reasonable offset to a buffer. Perhaps I am missing a much simpler way of checking.

For the record I am doing this on a userland program in a *nix environment. A general purpose answer would be awesome, but I would also be happy to see an array of platform specific answers.

Edit: Don't be afraid to move this to SecuritySE or elsewhere if you think it doesn't belong on RE.

  • Don't you have this information in the stack trace already? Use eip to get your faulty instruction and check if it's a read or a write given the value of the registers. – Dillinur Feb 4 '16 at 17:34
  • I want something automated that will do this for me over thousands of crashes. Also, I imagine that many things could happen between the invalid pointer being set, and it being dereferenced. – baordog Feb 4 '16 at 17:58
  • What are you calling "crashes"? Do you have the binaries or just dump/traces? In both case, it should be scriptable without problem. Distinguishing read crashes from write crashes is easy. But unless I'm missing something, I don't see how that would help you separate out-of-bound write from other crashing conditions. Or you'll have to specify what you mean by a "bad read" and a "bad write" if it's not trying to access a memory address you cannot read, resp. write. – Dillinur Feb 4 '16 at 22:26
  • I have binaries which crash the application, but I could get crash dumps pretty easily. I want to detect buffer overflows (which I think usually crash when EIP sends execution into invalid memory and would be caused by WRITING into the wrong address) and other crashes (which might be caused by doing any other operation in invalid memory, like maybe mov ESP, 0x0000001 - which crashes but doesn't help me control EIP) – baordog Feb 4 '16 at 23:10
  • Oh, so you're trying to separate "EIP corruption" crashes from the other ones. I'd reformulate your question to emphasize this point. – Dillinur Feb 4 '16 at 23:15
3

it is not clear if you are using windbg and you have a bunch of .dmp files that you want to auto analyze for access-violation if that is the case you could check this out

original contents of directory

:\>ls -l
total 96
-rw-rw-rw-  1 HP 0 96698 2016-01-29 21:27 CRASH.DMP

duplicating the same file 10 times to simulate a bunch of crash dumps

:\>for /L %I IN (1,1,10) do copy crash.dmp %I.dmp

:\>copy crash.dmp 1.dmp
        1 file(s) copied.

--------------

directory contents post duplication

:\>ls -l
total 1056
-rw-rw-rw-  1 HP 0 96698 2016-01-29 21:27 1.dmp
-rw-rw-rw-  1 HP 0 96698 2016-01-29 21:27 10.dmp
-rw-rw-rw-  1 HP 0 96698 2016-01-29 21:27 2.dmp
-rw-rw-rw-  1 HP 0 96698 2016-01-29 21:27 3.dmp
-rw-rw-rw-  1 HP 0 96698 2016-01-29 21:27 4.dmp
-rw-rw-rw-  1 HP 0 96698 2016-01-29 21:27 5.dmp
-rw-rw-rw-  1 HP 0 96698 2016-01-29 21:27 6.dmp
-rw-rw-rw-  1 HP 0 96698 2016-01-29 21:27 7.dmp
-rw-rw-rw-  1 HP 0 96698 2016-01-29 21:27 8.dmp
-rw-rw-rw-  1 HP 0 96698 2016-01-29 21:27 9.dmp
-rw-rw-rw-  1 HP 0 96698 2016-01-29 21:27 CRASH.DMP

running cdb with no symbol path to eliminate symbol loading and running a command on each of the file and grepping the result

:\>for /F %I In ('dir /b') Do cdb -sins -z %I -c ".exr -1;q" | grep -i att

result as follows

:\>cdb -sins -z 1.dmp -c ".exr -1;q"   | grep -i att
Attempt to read from address 0a29f6ac

:\>cdb -sins -z 10.dmp -c ".exr -1;q"   | grep -i att
Attempt to read from address 0a29f6ac

:\>cdb -sins -z 2.dmp -c ".exr -1;q"   | grep -i att
Attempt to read from address 0a29f6ac

:\>cdb -sins -z 3.dmp -c ".exr -1;q"   | grep -i att
Attempt to read from address 0a29f6ac

:\>cdb -sins -z 4.dmp -c ".exr -1;q"   | grep -i att
Attempt to read from address 0a29f6ac

:\>cdb -sins -z 5.dmp -c ".exr -1;q"   | grep -i att
Attempt to read from address 0a29f6ac

:\>cdb -sins -z 6.dmp -c ".exr -1;q"   | grep -i att
Attempt to read from address 0a29f6ac

:\>cdb -sins -z 7.dmp -c ".exr -1;q"   | grep -i att
Attempt to read from address 0a29f6ac

:\>cdb -sins -z 8.dmp -c ".exr -1;q"   | grep -i att
Attempt to read from address 0a29f6ac

:\>cdb -sins -z 9.dmp -c ".exr -1;q"   | grep -i att
Attempt to read from address 0a29f6ac

:\>cdb -sins -z CRASH.DMP -c ".exr -1;q"   | grep -i att
Attempt to read from address 0a29f6ac

by programmaticlally if you mean writing a tool to open and check each dump yes than it is possible to write a standalone exe using the dbgeng function

  • 1
    Whoah this is coo! I can't accept for a couple of reasons, though: 1) I am on Unix here 2) I am debugging userland applications. Thanks though! If nothing else comes up I will accept this. – baordog Feb 4 '16 at 6:33
  • Never mind didn't realize what you were doing in your answer, was late. I have crashing examples, not dumps. Still, this looks to be a Windows KD strategy. I wonder if I can port the strategy to GDB with crash dumps. – baordog Feb 4 '16 at 14:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.