DEF CON 23 - Chris Domas - Repsych: Psychological Warfare in Reverse Engineering

tangentially, the "blueprint spaghetti" link is pretty great: [link] at a former job i knew a team of devs who built and maintained a framework to help teams of researchers put together pipelines of simulation (often fluid simulation), animation, rendering, etc. This framework had its own blueprinting functionality. One of the cute features they had was nested blueprints -- e.g. you could define some blueprint, and abstract it behind an interface as its own component, then re-use the component in another blueprint. So i guess in a "blueprints from hell" scenario that lets you have "fractal blueprints from hell". edit: i'm also reminded of Chris Domas' defcon talk "Psychological Warfare in Reverse Engineering", where he sets out to construct binaries that cause despair when someone tries to reverse engineer them -- in particular he asks the question: "could i make a binary that draws a particular picture when someone views the binary's control flow graph in IDA" [this video]

In nature, prey animals will sometimes jump when they spot a predator[1]. One of the explanations is that this is the animal communicating to the predator that it is a healthy prey animal that would be hard to catch and therefore the predator should choose to chase someone else. I think we can kind of view obscurity in the same way. It's a way to signal to a predator that we're a hard target and that they should give up. Of course in the age of automation, relying on obscurity alone is foolish because once someone has automated an attack that defeats the obscurity, then it is little or no effort for an attacker to bypass it. Of course, sprinkling a little bit of obscurity on top of a good security solution might provide an incentive for attackers to go someplace else. And I can't help but think of the guy who was trying to think of ways to perform psychological attacks against reverse engineerers [2]. [1] - [link] [2] - [this video]

You can visualize the actual execution of software at a very low level using the "graph views" built into "binary code analysis tools" (decompilers/disassemblers) like IDA Pro, Ghidra, and Radare2. Many of these tools can generate absolutely HUGE graphs showing the control flow of raw assembly, though they're frequently so large that they're more overwhelming than helpful. Hence why most of the time they are used to generate graphs of small and complex sub-sections of software. Here are some example images showing control-flow graphs by different disassemblers/binary code analysis tools: [0] Ghidra control flow graph, relatively zoomed in: [link] Taken from this stackoverflow: [link] [1] Radare2 showing control flow graphs in ascii in the terminal: [link] [2] IDA Pro control flow graph, relatively large and zoomed out: [link] From this stackexchange: [link] [3] Defcon talk by Chris Domas where they demonstrated automate code generation which would cause various binary code analysis tools to generate control-flow graphs which formed specific shapes, shapes meant to offend or demoralize researchers examining the code (quite entertaining): [this video]