-
Notifications
You must be signed in to change notification settings - Fork 0
Advanced Guide
This page focuses on the workflows where XeCLI is strongest: live inspection, module work, memory editing, debugger control, XEX extraction, and automation.
Use the transport that matches the task:
- XBDM for live control, memory, threads, screenshots, and module metadata
- JRPC2 for Title ID, CPU key, temperatures, notifications, and generic RPC
- FTP for bulk file transfer, content trees, save files, and DashLaunch config edits
Trying to force one transport into every job is where most fragile automation starts.
rgh title is now useful as an operator tool, not just a raw lookup helper:
rgh title
rgh title --jsonIt resolves the active Title ID from the console and can layer a path-based fallback name over the bundled database entry when the live XEX is a dashboard replacement or homebrew shell.
XeCLI also exposes a lightweight hardware/session layer that is useful in tooling and operator workflows:
rgh signin state
rgh led set --preset quadrant1
rgh fan set --speed 55 --channel both
rgh smc versionUse cases:
- prove that the correct profile is signed in before save or content work
- surface visible LED state changes during scripted workflows
- dispatch fan changes from automation without opening a GUI tool
- probe SMC details when the installed plugin stack supports it
Read Hardware-and-System.md for the operator-level details and caveats.
Typical sequence:
rgh mem hexdump --addr 0x30000000 --size 0x40
rgh mem peek --addr 0x30000000 --type u32
rgh mem search --addr 0x30000000 --size 0x1000 --pattern DEADBEEFrgh mem poke --addr 0x82000000 --type u32 --value 0x12345678
rgh mem poke --addr 0x82000000 --type float --value 1337
rgh mem poke --addr 0x82000000 --type string --value "XeCLI"Do not treat poke as a blind trainer primitive. Read the target first, confirm endianness, then write.
rgh mem search --addr 0x82000000 --size 0x4000 --pattern 00000000 --freeze --freeze-type u32 --freeze-value 1 --freeze-count 10Use this for controlled short tests. Infinite freeze loops are available, but that is not a good default during early analysis.
rgh modules list
rgh modules info --name Aurora.xex
rgh modules dump --name xam.xex --out .\xam.binrgh modules unload --name HvP2.xex --forceUnload is intentionally gated because live module unload can wedge the console if the target rejects it.
Some modules or plugin stacks do not complete as a clean hot-load. XeCLI supports a tracked reboot-expected flow:
rgh modules load --path Hdd:\HvP2.xex --system --reboot-expectedThen, after the console comes back:
rgh modules pendingThis is better than pretending a disconnect was success.
rgh threads list
rgh threads context --id 0xFB000008
rgh threads suspend --id 0xFB000008
rgh threads resume --id 0xFB000008threads list now favors image-backed start metadata over fake names. On targets where XBDM does not expose real thread names, the table shows the containing image plus Start Addr. and End Addr. columns instead. End Addr. is the image end boundary for the resolved start address.
rgh debug stop
rgh debug go
rgh debug watchdebug watch is the quickest way to confirm that the console is actually emitting debug lifecycle events instead of silently stalling.
rgh debug break add --addr 0x82001000
rgh debug databreak add --addr 0x82100000 --size 4 --type writeUse code breakpoints to catch known execution sites and data breakpoints to identify writers to hot structures.
Use xex dump for a real XEX image, not a raw module dump:
rgh xex dump --out .\title.xexrgh xex strings --running --unicode --min 6Ghidra is external and documented in the CLI as (Free). XeCLI does not currently pin a supported Ghidra version in the docs, but it can install the XEXLoaderWV helper after you configure the tool path.
rgh ghidra config --path "C:\Tools\ghidra" --java "C:\Java"
rgh ghidra install-loader
rgh ghidra analyze --in .\title.xex
rgh ghidra decompile --in .\title.xex --out .\decomp
rgh ghidra verify --dir .\decompghidra verify exists because a decompile folder full of placeholder stubs is worse than no result at all if you do not catch it.
IDA support is pinned to IDA Pro 9.1.250226 with idaxex 0.42b. XeCLI does not bundle IDA Pro, but it can install the pinned loader helper after you configure the tool path.
rgh ida config --path "C:\Program Files\IDA Professional 9.1" --python python
rgh ida install-loader
rgh ida check
rgh ida analyze --ftp-path /Hdd1/Aurora/Aurora.xex --out-db .\Aurora.i64 --overwrite
rgh ida decompile --in .\Aurora.i64 --out .\ida-decomp --backend idalib --max 50
rgh ida verify --dir .\ida-decompIf you want a single command that pulls the running or remote XEX, builds a database, and exports C:
rgh xex ida-decompile --ftp-path /Hdd1/Aurora/Aurora.xex --out .\ida-decomp --max 50 --out-db .\Aurora.i64 --keep-dbRead Reverse-Engineering.md for the current support matrix, official download links, helper-loader install notes, and the pinned IDA baseline.
Use FTP-backed commands when the job is about the storage layout instead of the live memory image:
rgh save extract --titleid 415608C3 --out .\saves
rgh content list --device Hdd1 --show-types
rgh plugin list
rgh plugin enable --slot 5 --path Hdd:\XDRPC.xex --backupTreat content deletion and plugin edits as operational changes, not exploratory commands.
status --jsontitle --jsonmodules list --jsoncontent list --jsonghidra verify --json
- interactive selection flows
- destructive commands without explicit targeting
- reboot-expected module loads without follow-up verification
rgh status --json > status.json
rgh title --json > title.json
rgh modules list --json > modules.jsonStop and reassess instead of brute-forcing the console when:
- a module load repeatedly knocks the box off LAN
- XBDM stays up but JRPC2 calls become ambiguous
- a memory write target does not retain values across reads
- decompile output collapses into placeholder stubs
XeCLI is most effective when it makes unstable workflows explicit instead of hiding them.
XeCLI documentation for the rgh command. For release downloads, use the latest release.