ufm42/kexp

★ 17CAudience · researcherComplexity · 5/5ActiveSetup · hard

Mindmap

mindmap
  root((kexp))
    Inputs
      Pipe descriptors
      allproc pointer
      ELF loader address
    Outputs
      Payload return value
      Thread execution
    Use Cases
      Console security research
      Post-jailbreak payload work
      Inject code into a userland process
    Tech Stack
      C
      pthreads
      Raw machine code

mindmap root((kexp)) Inputs Pipe descriptors allproc pointer ELF loader address Outputs Payload return value Thread execution Use Cases Console security research Post-jailbreak payload work Inject code into a userland process Tech Stack C pthreads Raw machine code

Things people build with this

USE CASE 1

Run kexp as the payload after an existing userland jailbreak primitive on a console

USE CASE 2

Build a host program that maps a writable executable region and loads kexp into it

USE CASE 3

Pass pipe descriptors, an allproc pointer, and an ELF loader address to the payload

USE CASE 4

Study the integration recipe as a reference for post-exploit payload loading

Tech stack

Cpthreads

Getting it running

Difficulty · hard Time to first run · 1day+

Repo has no build steps or target platform listed, and assumes a prior userland jailbreak primitive.

In plain English

This repository, called kexp, is described in one line by the author as a payload that does post-jailbreak related work. Jailbreak in this context means an exploit that already broke through a device's normal restrictions, and a payload is the chunk of code that runs once that opening has been made. The repository itself is small and the README is sparse: there is no architecture overview, no build instructions, no license, and no statement of which platform it targets. What the README does contain is an 11-step recipe for a host program that loads kexp into a running process and runs it on a separate thread. The steps assume that a jailbreak has already happened from a userland process. The host first creates a shared memory region that is allowed to be both writable and executable, maps it into its own address space, and copies the kexp machine code bytes into that region. The host then prepares a 40-byte argument structure for the payload. The fields are two pairs of pipe file descriptors labelled master and victim, a kernel pointer labelled allproc, and the address and size of an ELF loader. The host calls pthread_create with the mapped code as the entry point and the argument structure as input, then waits with pthread_join, prints the return value, and frees the result. The README closes with a short credits list of names from the console exploitation community. No further documentation is shown. For a non-technical reader, the practical takeaway is that this repository is not an end-user application but a low-level building block used by other security researchers. The payload itself is written in C and compiled to raw machine code that gets injected into a target process at runtime. The names and field labels in the integration recipe, such as allproc and ELF loader, are conventions used in research into game console operating systems, but the README never names a specific console or firmware version. Anyone trying to actually use the code would need to find that context elsewhere, supply their own jailbreak primitive to reach a userland process with the right capabilities, and build the host program described in the steps.

Copy-paste prompts

Prompt 1

Translate the kexp 11-step README into a working C host program skeleton

Prompt 2

Explain what each field in the 40-byte kexp argument struct is for

Prompt 3

Compile kexp to raw machine code suitable for the pthread_create entry point

Prompt 4

Identify which console research community uses the allproc and ELF-loader conventions seen in kexp

Prompt 5

Sketch the safety boundaries to apply before running kexp on a real device

Open on GitHub → Explain another repo

Generated 2026-05-22 · Model: sonnet-4-6 · Verify against the repo before relying on details.