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

I cannot wait for the accompanying Black Hat talk. Christopher Domas is one of my absolute favorite all-time hackers. He does such a fantastic job of explaining his work. Some of my favorite talks of his: - Psychological Warfare in Reverse Engineering ▶ this video - The MoVfuscator link - Hardware Backdoors in redacted x86 link

Makes me think of what might deter a reverse engineer and then this most awesome youtube talk on psychological warfare by Chris Domas ▶ this video It's so good.

Saw this recently after reviewing some Defcon 23 videos. The author goes into detail about how it's working and some other fun stuff regarding anti-reverse-engineering. 2015 DEFCON 23 - Chris Domas - Repsych: Psychological Warfare in Reverse Engineering ▶ this video And a paper by him: link

▶ this video about 7 minutes in he is chatting about it but all is a good watch - could only find the YT link sorry

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

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

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