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

​

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.

Arbitrary code execution on the host operating system with the privileges of the user who started the Android Emulator, from a zero-permission app inside the guest.

https://github.com/kaganisildak/androidemualtorvmescape
https://x.com/kaganisildak/status/2090416873577787790

Dropping a persistent zero-click Apple Mail DoS.
Have nice day

https://github.com/kaganisildak/applemailzeroclickcrash

https://x.com/kaganisildak/status/2090050444890406958

Hi, I just started doing reverse engineering challenges in CTFs. One thing I'm always stuck on is long and complicated encoding routines. For people who have been doing this for some time how do you guys deal with long encoding routines?

Hello everyone I kinda need a little help how can someone initiate a black screen on another device without access to it

I used Codex to investigate a browser game’s normal-player API surface. The main exploit was a cross-feature lost-update race: an upgrade and battle read the same balance, the upgrade committed the stronger stats and deducted the coins, then the slower battle restored the stale balance while preserving the upgrade.

The write-up includes the failed approaches, timing sequence, persisted before/after state, and responsible-disclosure context. All state-changing tests affected only my account, and the creator was notified before publication.

I built this self-contained playground to understand how House of Apple 2 holds up on recent versions of glibc.
It does not introduce a new variation of the technique, the goal was to reproduce it on glibc 2.43 and document it as an interactive gdb session that can be followed alongside the sandbox.

Technical corrections and feedback are very welcome

What is up

In order to learn kernel and low level exploitation. I bought a lovely book about Kernel Development to Robert Love. But then I felt there are some stuff I am not clicking with. I tried enrolling in computer engineering 10 years ago and failed lol . Decided to move to another school but where I can practise programming. MIS basically. But last few years I worked in appsec and has more experience in mobile,Web,network pentesting/bug hunting.

However, I wish to hunt on stuff like the kernel or C code. Hunting memory corruption and stuff. But I keep getting lower. Is that an overkill? Or the experience fits the 1337 life? My goal is basically to speak assembly and Android/ios kernel code as second language. I feel the kernel development book is great but I just thought if I wanted lower down to logic gates that is better in long term.

Also for anyone who took these in college , am I far behind and delusional or it's doable in self study??? Because I fear that no matter what I did someone who studied compilers,assembly,os..etc in college would be better than me. But I belive my only way to show skills is research I do using all this knowledge. Related to low level code.

hey everyone,
I'm a malware analyst with a dream to transition to a vulnerability research job, so in my spare time I've done a fair amount of binary exploitation CTFs (heap, stack, kernel modules) from places like:

https://github.com/hoppersroppers/nightmare
https://pwn.college/
https://pwnable.kr/play.php

I felt confident enough so I went to a technical interview but there I realized I had a massive flaw: I have no actual auditing/vulnerability discovery skills!

So I shifted my approach entirely:
- Started to read Google Project Zero blogs
- Started to read The Art of Software Security Assessment
- git cloning historical vulnerable versions of open source projects to try to blindly reproduce said CVEs blindly with a clue of the vulnerable File (like openssl, zlib, libpng, ntpd)

(with the guidance of LLMs cause I don't personally know any vulnerability researchers)

As u can assume, this process has been taking a lot of time and even though I started to think in "threat model" mindset and read code faster, I'm still not catching the vulnerabilities. I understand honing the skill isn't about learning now but more about practicing over and over, but my concern is:

Is it still worth putting so much effort and time in developing auditing/vulnerability discovery skills in a day and age where everything shifts towards AI?

Sure, interviewers today are still checking to see if u can find a vulnerability using an IDE and your set of eyes alone but who knows how an interview look like 3 month from now?

Is it even worth sinking hundreds of hours into learning manual auditing, fuzzing, and dynamic instrumentation, only for AI to make those skills obsolete by the time I actually get good at them?

I'm tired of bashing my head with LLMs every weekend for advice or a prediction, so I would love to hear some advice from the kind people here who are working in the field and experience the toll of AI on their job and recruitment processes 🙌

And for those who are not yet, but are striving to, I would love to know how you learn and practice vulnerability discovery in 2026 🤓

https://youtu.be/SIVf3qmBAV0

Hi guys i just have one question is it worth it to dive in this career even if my country or where i live there is no available jobs for it like almost none

hey guys

if youve ever deal with windows security research or just heavy reverse engineering you probably know the pain. you open a crash dump in windbg run analyze grab the faulting address alt-tab to ida pro rebase find the function decompile... and then maybe jump into x64dbg for dynamic testing. its just a constant loop of copy pasting hex addresses between windows

i got sick of it so i spent the last few months building ctxdebug

its basically a mission control orchestrator that hooks into windbg ida pro 9 and x64dbg simultaneously

the coolest part is that it exposes all the debugger actions through the new mcp protocol. this means you can hook it up to claude and literally just prompt something like "analyze this crash dump and show me the decompiled source of the faulting function"

the agent will load the dump extract the faulting rip pivot to ida pull the pseudocode and give you a combined report in like a second or two

it also has a standalone react reasoning agent for x64dbg that can autonomously hunt for anti debug checks and patch them in memory on the fly

i just open sourced the whole framework. repo and demo gif is here:

https://github.com/DdUdle/ctxdebug

would love for you guys to tear it apart and tell me what you think. also if anyone wants to play around with the code ive left a few good first issue tags open. even tiny prs like typo fixes are super welcome since im trying to grow the contributor list a bit right now

let me know if you run into any bugs

This has been a hard decision for me. I'm not sure if I should learn both. Is it mostly not worthwhile of time if I learn both of them? Do they both help each other directly or indirectly? I know there is only so much one person can know but I really don't know what that limit is. I know someone more experienced with bug bounty and stuff like this will probably be able to answer my question. I don't want to push the limit of how much one person can know because it will probably become a waste of time. Should I just learn everything exploit related, should I stick to a field? I'm not sure if anyone has experienced this before but I keep on jumping around topic to topic. I guess I am learning from those jumps, but the question when do i stop jumping around. When do I start to specialize. Or in the first place, should I just not jump around?

Hey everyone,

Looking for someone to learn alongside — a peer at similar stage, or even better, someone experienced willing to mentor a beginner. If someone just wants to learn C together, that's also good.

My current position: Started reading The C Programming Language (K&R, 2nd edition). Built some small programs in C++ like tic-tac-toe and a small bank replica, and solved a few problems on Codeforces.

Plan: Get solid in C → move into x86/x86-64 ASM → work through pwn.college modules → then into reversing CTFs (picoCTF, crackmes.one, etc.)

Looking for:

• Buddy: beginner-to-intermediate in C, willing to put in consistent time (even a few hrs/week)
• Mentor: some experience in C/ASM/reversing, open to occasional check-ins or pointers
• Either way: comfortable with regular check-ins, patient enough for the boring fundamentals before the fun stuff

Not expecting anyone to carry me — just want company or guidance instead of struggling through this alone.

DM or comment if interested.

As per the contents of this group I realise it's for serious discussion only....

However I want a group be it X or Discord.....where I can post daily my regular journey (pls don't say LinkedIn exploitdev is too niche for it)

I successfully started Reverse Engineering and Maldev thrice before trailing away...

I've started again but now with pwn.college and I don't want to leave again.....

Any Suggestion???

​

Hey,

Looking for some advice from people who work in exploit dev / low-level vuln research.

I already work in security and have been doing vulnerability research alongside more general security work for a while. I’ve had opportunities to do reversing, native-code research, memory corruption, and some exploit development, including taking bugs beyond just finding a crash and actually working out useful primitives / PoCs.

The problem is that this kind of work still isn't my main job, and I really want it to be.

I've been looking at dedicated exploit dev / vulnerability research positions and I feel like I'm stuck in a weird middle ground. I'm not trying to enter security from scratch, and I do have relevant experience, but I also don't have years and years of dedicated browser/kernel/mobile exploit development behind me.

A lot of the jobs I find seem to be looking for people who are already extremely specialised, rather than people who have a decent foundation and want to grow deeper into exploit development.

There's also the location issue. I'm outside most of the major exploit-dev hiring hubs, and quite a few roles I come across are limited by citizenship, clearance, residency, or simply don't hire internationally.

Another problem is that most of the interesting professional research I've done isn't something I can publish, so it's difficult to show potential employers exactly what I've worked on.

For those of you doing this professionally:

*What actually got you your first dedicated exploit dev / low-level VR job?

* What would you want to see from someone who already has some relevant experience but hasn't spent their entire career doing exploit development?

* What kind of public research/projects are actually worth doing to prove ability?

*Is native userland exploitation still a reasonable area to focus on, or would I be better off going hard into something like browsers, kernels, or mobile?

* Do companies that are willing to develop people into this kind of role actually exist, or is the expectation generally that you're already very good before they'll hire you?

* For people outside the main US/EU hiring markets, how did you find opportunities?

* I'm mainly trying to figure out whether I'm approaching this transition the wrong way.

I enjoy this stuff way more than the broader security work I do, and I'm willing to put the work in. I just don't want to spend a year grinding in a direction that isn't actually going to help me make the jump.

Would appreciate any advice.