ROX: Vulnerability Research - how to approach a black box without wasting time

3 minute read

I’ve been consulting in vuln research for ~2 years. When I started - I was 16 at the time, I landed on a platform I knew only from CTFs, with little professional VR experience. I worked 10 am.–3 am., dreamt about it at night, and burned out fast. I couldn’t find any clear guide on handling huge binaries. VR is a secretive world and you don’t always have people to ask. I was progressing, but slowly-on a 300-MB binary I kept chasing trivial C++ routines and hand-rebuilding vtables instead of going to the point.

Two years in (still junior!), I’ve learned how not to waste time. Here are the practices that helped me move faster.

  1. Do your homework first

    Take time to search technical articles/blog posts/write-ups about the software or tech you’re targeting. More than once I re-implemented an algorithm only to find an obscure post on page 10 of Google doing exactly that. Don’t be scared by sketchy-looking URLs-sometimes that’s where the gold is. White papers and any hints about crypto/algorithms are particularly valuable (see #2).

  2. Strings → cross-references

    Search for strings in the binary, then jump to their Xrefs to see where they’re used and to identify functions quickly. If you care about URL parsing, search for URL, UrlPars (to catch both “Parsing” and “Parser”), Parsing, etc. This is also great when focusing on a specific component: developers often leave debug/error strings with paths that reveal filenames and even project names you can reuse. This is actually how I found both CVE-2025-2851 and CVE-2024-57391.

  3. Trace early with frida-trace

    frida-trace lets you trace functions, offsets, and Objective-C methods-and you can modify handlers to fit your needs, which saves time. Even on huge codebases, don’t be afraid to use wildcards across subsets of functions or Obj-C methods. For instance, to spot which crypto functions are called during an action on iOS:

    1frida-trace -i "*Crypto*" -U -f com.example.app

    It may capture a lot, save the output and take time to identify the algorithms in play (e.g., AES, HKDF, MD5).

  4. Don’t over-analyze every function

    You don’t need to fully understand each function at first. In decompilations, a good chunk is compiler slop that’s not worth the time. With C++, tons of routines (referencing/dereferencing, object creation, std::string noise, etc.) can distract you. Aim for the function’s purpose and I/O quickly. On a 300-MB binary - when doing the first analysis, spending even 5 minutes per function is impossible.

  5. Lean hard on cross-refs and stack traces

    Cross-refs and stack traces are mandatory. I keep a small snippet ready to print a stack trace from any interesting function. Find a function, then look where it comes from. This often lets you avoid rebuilding vtables: you can infer unknown functions by observing the stack from known, symbolized ones. Along with frida-trace, this is one of the most important accelerators you can use.

  6. Compare cross-platform builds

    For cross-platform software, it often pays to look at multiple platforms (e.g., Windows and iOS) and hunt for symbols/DLLs where symbols weren’t stripped. The compiler may produce code that decompiles more readably on one platform. Windows is a good bet because some DLLs are in C# and decompilable with dnSpy. You’d be surprised how many vendors don’t strip or obfuscate. In my experience, amd64 is generally easier for most decompilers.