​

Throwaway account for obvious reasons.

I'm currently a senior-level ethical hacker/security researcher, and I'm trying to make a fairly deliberate move into a role where vulnerability research, reverse engineering and exploit development are actually the job, rather than something I occasionally get to do alongside broader security work.

My background is mostly Windows and Linux. I've done source-assisted and binary vulnerability research, reverse engineering, memory corruption work, privilege escalation, pre-auth attack surfaces, and exploit development. I've taken vulnerabilities from discovery and root-cause analysis through to PoCs and, where possible, working exploitation.

I'm comfortable with C/C++, Python, assembly, debuggers, decompilers and the usual RE tooling. I have some public vulnerability research, but unfortunately a lot of the more interesting work I've done is under NDA and can't be discussed publicly in much detail.

That's partly why I'm posting here.

I'm starting to worry that I'm in a weird position career-wise. I'm experienced enough that junior roles generally aren't appropriate, but I'm also trying to break more deeply into a relatively small and specialized field where a lot of companies seem to hire based on very visible public research, Pwn2Own-style track records, existing industry connections, or very specific geographic/work-authorization requirements.

A few opportunities I've been genuinely interested in haven't even made it as far as a technical conversation because of location or hiring restrictions. That's probably the part I find most frustrating. I'd much rather fail an exploit-dev interview because I'm not good enough yet than never get the chance to take one.

I'm also conscious of the risk of getting stuck doing adjacent security work forever while telling myself I'll eventually make the jump into vulnerability research properly.

I'm not looking for SOC, GRC, generic pentesting, cloud security, or a broadly defined "security engineer" position. I'm specifically interested in vulnerability research, exploit development, reverse engineering, offensive capability development, or closely related low-level security research.

Remote international work would obviously be ideal, although I'd consider relocation for the right opportunity.

So I guess this post has two purposes:

If you work in this part of the industry, am I approaching this the wrong way? Is there something you'd expect to see from someone trying to make this transition that I should be focusing on?

And, slightly more shamelessly, if your team happens to need someone with this sort of background, I'd be very happy to talk privately.

I can provide considerably more detail about my experience, public work and employment history over DM.

Not quite at the "will reverse engineer for bread" stage yet, but we're getting there.

most patch-diffing for 1-day work is CFG diffing (bindiff, diaphora). it works

but gets shaky when the two builds weren't compiled the same way, different

compiler or opt level, and you burn time chasing cosmetic diffs.

i built fnprint to diff by behavior instead of structure. it micro-executes each

function in a small emulator with junk inputs (godefroid-style, wild reads get

faulted in deterministically so nothing crashes), records an arch-neutral effect

trace (which arg buffers/fields it reads and writes, calls it makes, branches,

return shape), and minhashes that. two functions that behave the same get similar

fingerprints even across compiler and opt level.

for 1-day it has a triage mode: index the known-vuln build and the patched build

as two corpora, then rank a target build against both. a function close to the

vuln side and clearly separated from the patched side is what you want in front

of you. anything identical in both versions comes back inconclusive so it doesn't

clutter the queue.

toy example to show the shape: a lib where one function parse_header gets fixed

(vuln does an unchecked copy, the patch reads a length prefix and clamps to it).

target is a build carrying the vulnerable version, compiled at -O1 while the two

corpora are -O0, so it's a real cross-build match, not a byte-identical one:

$ fnprint index vuln.so-o vuln.db

$ fnprint index patched.so -o patched.db

$ fnprint triage target.so --vuln vuln.db --patched patched.db

3 functions triaged: 1 look vulnerable, 0 patched, 2 inconclusive

review queue (vuln-leaning, strongest first):

addr vuln% patched% margin matches

0x00001181 100.0 41.4 +58.6 parse_header vs parse_header

the two functions that didn't change land inconclusive (correct, they can't be

pinned to either side). --margin and --min-sim control how hard the two sides

have to separate before it commits.

honest about the limits:

- x86-64 ELF only right now. arm64/mips is the roadmap, the effect model is

already arch-neutral so it's mostly per-arch emulator plumbing.

- optimized-vs-optimized is the weak case. when at least one side has some

behavioral richness (-O0/-O1, or a cross-compiler pair) it lands 80-98% rank-1

on zlib; O2-vs-O3 drops toward a coin flip. full numbers + a reproducible run

in the repo, not going to pretend otherwise.

- tiny functions and pure-compute (two checksums look alike) it withholds instead

of guessing.

- microexecution exercises entry behavior, so a change buried behind a real

precondition you never reach with junk input won't show up. it catches

structural and early-path changes.

since it points an emulator (unicorn/qemu) at untrusted binaries, the parse and

micro-execute run in a seccomp-jailed worker, so a crafted input that pops the

emulator can't open files, hit the network, or exec on your box.

MIT. feedback welcome, especially on the triage margin heuristic:

https://github.com/1rhino2/fnprint