independent offensive security

Reverse Engineering Pentesting Scripts And Exploits

breaking stuff just to see how it works.

status
available
timezone
utc+01
disciplines
re · pentest · exploit dev · tooling
scroll
[01] >

About me

Exploring system weaknesses through reverse engineering and exploit development

I take software apart to find out where it gives. Binaries, protocols, web stacks and the glue between them - the method does not change: read what is actually running rather than what the documentation claims, then keep pulling until something moves.

Work is authorised, scoped in writing, and written up so your own engineers can reproduce every finding without me in the room. Findings go to the vendor first and stay out of public view until a fix ships or the disclosure window closes. Scope drives the number, and the number is fixed before anything starts.

  • Custom workflows. No two targets get the same harness. Tooling is written for the system in front of me and retired the moment it stops earning its place.
  • Practical research. Time goes into bug classes that turn up in real deployments, not into whatever reads well on a conference slide.
  • Tools built for real use. Fuzzers, loaders, protocol clients and triage scripts that survive contact with a live engagement rather than a demo.
  • C/C++, Python, PHP, JS, Bash. Native code for exploitation and instrumentation; scripting for everything that has to run once and be correct.
  • Security-conscious handling. Encrypted transport, the minimum evidence retained, destruction on request. Client detail never leaves the engagement.
[02] >

Core exploitation domains

Five surfaces, one habit: find the boundary somebody assumed was solid, then show exactly how far across it an attacker gets.


  • Desktops

    Thick clients, local privilege boundaries and the update paths nobody audits.

    • win32
    • ipc
    • privesc
  • Servers

    Service daemons, auth boundaries and deploy scripts that grant more than anyone intended.

    • linux
    • daemons
    • authz
  • Virtualization software

    Hypervisors, container runtimes and the device models where guest input reaches host code.

    • hypervisor
    • device model
    • escape
  • Networks

    Routing, segmentation and the management planes left reachable from the wrong side.

    • l2 / l3
    • mgmt plane
    • segmentation
  • Zeroport

    Undocumented services, forgotten listeners and ports no asset inventory admits to.

    • discovery
    • banner drift
    • shadow svc
[03] >

Capability matrix

languages

  • C / C++ daily driver · exploit and tooling
  • Python harnesses, fuzzing glue, triage
  • x86-64 / ARM64 assembly read constantly, written where it is needed
  • PHP legacy web targets, source review
  • JavaScript / TypeScript browser surface, node services
  • Bash engagement plumbing, one-shot automation

reverse engineering

  • Static analysis ida · ghidra · binary ninja
  • Dynamic analysis gdb · windbg · frida · record-replay traces
  • Firmware and embedded unpacking, flash dumps, boot chain review
  • Obfuscation and packers devirtualisation, unpacking by hand
  • Anti-cheat and DRM kernel drivers, integrity checks, telemetry

web

  • Application logic auth, session, multi-tenant boundaries
  • API surface rest · graphql · undocumented endpoints
  • Injection classes sqli, template, deserialisation
  • Client side xss, csp bypass, prototype pollution
  • Source review php, node and python codebases

infrastructure

  • Active Directory delegation, acl paths, kerberos abuse
  • Linux estates service accounts, sudo policy, container escape
  • Cloud iam boundaries, metadata services, storage acls
  • Segmentation vlan hopping, east-west reachability
  • CI / CD build agents, artefact signing, secret sprawl

tooling

  • Fuzzing afl++ · libfuzzer · grammar harnesses
  • Emulation qemu · unicorn · rehosting blind targets
  • Instrumentation dynamorio, pin, hand-written hooks
  • Evidence and reporting scripted capture, reproducible proofs
  • Internal loaders, protocol clients, triage pipelines

No bars, no percentages, no star ratings - a score against a skill is invented precision. Ask about any line here and you get a straight answer on how deep it goes.

[04] >

Action process

01

Contact

Send the scope, the target class and a timeline. Encrypted if it is sensitive. You get a written answer with a fixed quote, or a clear no.

02

Progress

Work runs against the signed scope inside an agreed window. Anything critical reaches you the day it is found, not in the final report.

03

Payments

The quote is fixed before work starts. Half up front on engagements, the balance on delivery. Invoice, BTC or XMR - whichever suits your finance team.

[05] >

Track record

120+

Engagements delivered

self-reported, 2019-2026

4200+

Hours on target

self-reported, 2019-2026

90+

Coordinated disclosures

vendor first, never brokered

6

Sectors worked in

sectors named, clients never


  • ██████
  • ████████
  • █████
  • █████████
  • ███████
  • ██████

Round figures, self-reported across 2019-2026. None of it is an audited metric. Names, logos and anything that would identify a target stay behind the NDA - sector and engagement class is the most that is ever said in public, on this page or anywhere else.

[06] >

Field notes

Scope first, every time

The first command of any engagement is not an exploit. It is a check that the target list in front of me matches the one on the signed document, and a refusal to move if it does not.

The session beside this is illustrative - no live host is contacted, and nothing here runs against anything. It is what the opening five minutes of a scoped assessment actually look like, minus the parts that would identify a client. If you have something you want looked at, send it through the intake form.

rky@shellcode - field notes illustrative

whoami

rky - offensive security, independent. authorised work only.

cat scope.txt

targets: 2 · window: 14d · retest: included · signed: yes

in scope: one binary, one staging api. nothing else.

./triage --dry-run scope.txt

2 targets parsed · 0 hosts contacted · dry run, nothing sent

the harness refuses to move until scope.txt matches the signed copy.

next step

Found something worth breaking?

Send scope and a timeline. You get a written answer with a fixed quote, or a clear no.