4

I have found this, https://msdn.microsoft.com/en-us/magazine/cc163311.aspx

It says that only "a full root-cause analysis can ensure that you have correctly diagnosed whether a given crash is exploitable". Is it possible to do such analysis without access to source code ? How ? If not, what´s the closest to "full root cause analysis" that can be done without source code ?

|improve this question
  • Good ole fashion elbow grease and reverse engineering! – RoraΖ Mar 21 '15 at 10:03
2

If this is public application and you can install it on your computer so you can debug it with any debug software you want, for example with immunity debugger and than you can analyse the crush and see what happen in the cpu registers and memory when the crush happen and find a way to inject your code (shellcode) in the right place so the application will run it..

|improve this answer
  • Ok, I get this is the way to look for buffer overflows(try to check if you can overwrite EIP), so for other types of bugs it should be about overwriting specific registers/memory locations to check if you can trigger some bug belloning to some known "bug pattern"(race condition, format strings etc...). You apply knowledge of those bug types to see if you can trigger them. – Rafael Mar 21 '15 at 16:18
2

There are ways to triage likely bugs automatically, such as the !exploitable plugin for windbg, but it is only an indication of whether a bug is exploitable, not a proven analysis.

|improve this answer
  • I understand tools like these implement knwoledge about registers that can usually be exploited, and check if it can overwrite them, warning if succefull. Is that it ? – Rafael Mar 21 '15 at 16:58

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.