It is a large opaque binary with some non-determinism to the crashes, so useful tooling here will help us to speed up our reverse engineering efforts. Procmon's parsing of PML (Process Monitor Log) files is pretty easy to knock over, and we can quickly get lots of crashes out of a short fuzzing session. We will be using a bunch of crashes in Procmon64.exe for our examples. If that sounds interesting to you, there is more information at the bottom of this post. It’s fun and practical, with lots of demos and labs to practice applying these concepts in creative ways.
We've developed a 4-day course called "Practical Symbolic Execution for VR and RE" that's tailored towards these exact goals. (Oh BTW, we have a course!) Do you reverse engineer and symbolically execute in your workflows, or want to?Īre you using fuzzing today but want to find more opportunities to improve it and find deeper and more interesting bugs?Ĭan you jam with the console cowboys in cyberspace? The examples all use code hosted at: /atredis-jordan/SymbolicTriagePost The examples here all use the great Triton library for our symbolic execution and solving. In this post I want to share my process for writing symbolic execution tooling for triaging crashes, and try to highlight tricks I use to make the tooling effective and flexible. By building a small symbolic debugger I managed a much faster turnaround time from fuzz-case to full understanding. This is the "Good Situation" I have found myself in before, where my fuzzer handed me a large load of crashes that resisted normal minimization and de-duplication. One of those situations is when triaging a large number of crashes coming out of a fuzzer, especially in cases where dealing with a complicated or opaque target. However, I have found symbolic execution can be very helpful in certain targeted situations. Generic symbex tools have a hard time proving their worth when confronted with a sufficiently complex target.
0 kommentar(er)
