Tunerpro xdf and bin exporter and cli editor for llms and ghidra tooling. Other stuff.

[KingAustraliaggGG]

Long post. A lot of different things going on, so forgive the length.

Looking for testers and feedback

I have put some of the supporting tools on GitHub. They are not all finished products. Some are WIP/research, but the goal is to make the ECU/XDF/disassembly workflow more repeatable and easier for other people to inspect, test, or correct.

Main GitHub profile:
https://github.com/KingAiCodeForge

Relevant ECU / reverse-engineering repos:

TunerPro XDF + BIN Universal Exporter:
https://github.com/KingAiCodeForge/Tune ... l-Exporter

This tool exports calibration data from TunerPro XDF + BIN combinations into readable TXT / JSON / Markdown / CSV outputs. The reason I made it is that some TunerPro exports can show zero-filled or poor-quality table output even when the data displays correctly inside TunerPro. This exporter reads the XDF and BIN directly so the tables, scalars, flags, axes, units, equations, addresses, and decoded values can be checked outside the GUI.

For the MS42/MS43/MS45 work, this is useful because I can compare full flash versus partial read exports, check if axes are sane, compare stock versus stage files, and produce reviewable Markdown/CSV evidence instead of only relying on what the table looks like in TunerPro.

CLI XDF/BIN map editor:
https://github.com/KingAiCodeForge/tune ... map-editor

This is a command-line XDF/BIN calibration editor. The goal is not automatic AI tuning. The goal is deterministic, logged, human-reviewed edits.

The tool is designed so a map can be listed, read, edited, diffed, and reported from the command line. That makes it easier to test repeatable changes, compare exact byte deltas, preserve original files, and let AI tools assist with inspection without giving them uncontrolled authority over the file.

The repo currently includes BMW MS42/MS43/MS45 notes and Holden VY V6 material. The useful part for this MS45 work is the structured workflow: read map, inspect values, make controlled edit, export diff, then manually review.

KingAI VY V6 L36 Commo Flasher:
https://github.com/KingAiCodeForge/King ... mo-Flasher

This is my Python flash-tool project for Holden VY Ecotec V6 / Delco 68HC11 flash ECUs. It is aimed at VY Ecotec V6 $060A / 92118883 style ECUs using ALDL 8192 baud.

Important status: this is still virtual-tested / WIP, not something I am claiming is proven on real hardware yet.

The reason it matters to the wider project is the workflow: flash protocol notes, read/write sequencing, seed/key handling, bank mapping, checksum handling, GUI lockout during flash operations, CLI/backend separation, virtual ECU testing, and safety gates. Those patterns are useful even when working on other ECUs, because the same general problems show up: file layout, address mapping, write safety, recovery, logging, and verification.

KingAI 68HC11 C compiler / disassembler / bench experiments:
https://github.com/KingAiCodeForge/King ... C_Compiler

This is a subset-C compiler / assembler / toolkit targeting Motorola 68HC11 automotive ECU work. It is aimed at Delco / Holden VN-VY V6 / GM OBD1-style research.

Status: alpha / WIP.

The idea is to go beyond hand hex-editing by compiling a small C-like subset to 68HC11 assembly, assembling it, and patching ROM images in a repeatable way. It also includes disassembly, patching, checksum, binary identification, and related tooling.

This is not directly MS45 because MS45 is MPC555 / PowerPC, not HC11. But the workflow is relevant: define the processor, split the binary correctly, label the memory map, identify safe hooks/free space, generate code, patch, diff, and verify.

VY L36 $060A enhanced ASM patch / label workflow:
https://github.com/KingAiCodeForge/king ... sm-patches

This is my VY L36 / Delco $060A assembly research repo. It contains WIP assembly patch concepts, bank-split output, HC11 references, RAM-variable notes, ISR analysis, and label/disassembly workflow notes.

Important status: research/WIP. Not a polished release. No patched binaries are being provided as a finished tune.

The useful part for this MS45 project is not the exact HC11 code. It is the method:

- split the binary into banks/regions
- generate labelled disassembly
- identify RAM variables
- validate hook points
- detect wrong assumptions early
- document corrections
- separate confirmed evidence from guesses
- use Ghidra/IDA-style labels and xrefs instead of just XDF names

That is the same style of process I am trying to port across to MS45/MPC555/PowerPC: label known calibration addresses, import them into Ghidra, mine xrefs, then classify whether a value is actually read, compared, masked, branched on, or just appears as an address-like immediate.

Supporting document/research repo:

KingAI all-files-to-Markdown batch converter:
https://github.com/KingAiCodeForge/king ... _converter

This one is not ECU-specific, but it is very useful for ECU documentation work.

It batch-converts large folders of files into Markdown so they can be searched, diffed, indexed, or used with LLM tools. It supports formats like PDF, DOCX, XLSX, PPTX, HTML, CSV, JSON, XML and more. It has multiple PDF extraction fallbacks, recursive folder scanning, resume/checkpoint support, JSON reports, and multiprocessing.

This is useful when dealing with hundreds of pages of PDFs, old documentation, A2L/DAMOS exports, CSV files, XML files, XDF-related notes, forum dumps, and technical references. The goal is to get everything into searchable text so I can find addresses, labels, OSIDs, constants, function names, and repeated terminology faster.

Other ECU definition work I have started:

I have also started early Barra XDF work using TesterPresent’s public dumps/resources from his website as a reference source. That is still early-stage, but the goal is the same: use known dumps, definitions, labels, and exports to build something that can be checked instead of guessed.

I have also forked an LS2 XDF as a starting point, but that is not even 1% complete yet. The target I want to start building toward is VE 2008-2010 LS2 / E38, especially manual HSV / SS sedan variants.

If anyone has legally shareable E38 LS2 ECU dumps, I would appreciate them for definition-building and validation. I am mainly chasing VE 2008-2010 LS2 / E38 files, especially manual HSV / SS sedan variants, but any E38 LS2 stock reads would be useful. PCMhammer full reads are ideal, but files converted to BIN from other tools are fine if the OSID, year/model, transmission, engine, and source format are included.

Please do not send paid commercial tunes or private customer files unless you have permission to share them. Stock/reference dumps, spare bench reads, manual files, matching OSIDs, and known-good XDFs are what I need for map location, segment, checksum, and XDF validation.

What I am looking for:

I am mainly looking for testers or feedback from people who understand ECU reverse engineering, XDFs, Ghidra/IDA, PowerPC/MPC555, 68HC11, TunerPro, RomRaider, A2L/DAMOS, or Holden/BMW ECU workflows.

Useful feedback would be:

- does the XDF/BIN exporter decode your XDF/BIN correctly?
- do the axes, scalars, flags, and units export correctly?
- does the CLI editor make safe and reviewable diffs?
- are the MS45 address translations sane?
- are the Ghidra label/xref assumptions wrong anywhere?
- are any of the VY/HC11 bank split or patch notes incorrect?
- does the Commo flasher protocol logic match what people know from OSE/ALDL work?
- are there better ways to map MPC/internal code versus external flash on MS45?
- are any of my labels copied too far across OSIDs without enough proof?
- does anyone have legally shareable E38 LS2 stock dumps for comparison?

I am not looking for people to blindly flash or test risky changes on road cars. Bench testing, export checking, XDF review, code review, Ghidra/IDA setup advice, stock dump comparison, and correction of wrong assumptions are more useful at this stage.

If anyone wants to test one part, the easiest starting points are probably:

1. Try the TunerPro XDF + BIN exporter on a known-good XDF/BIN pair and compare the output against TunerPro.
2. Try the CLI map editor on a spare copy of a BIN and check the diff output.
3. Look over the MS45 address mapping / Ghidra xref approach and tell me if the memory map assumptions are wrong.
4. Review the VY/68HC11 bank split and label workflow for obvious processor/addressing mistakes.
5. Try the Markdown converter on a big folder of PDFs/CSV/XML/XDF-related files and see if the output is useful for searching.
6. Share legally reusable E38 LS2 stock reads or OSID information if you have them.

I am trying to keep the project evidence-based: labels are candidates until proven by matching binary layout, sane exports, cross-source agreement, tune diffs, or disassembly references.

Any corrections, PRs, issues, test reports, stock dump comparisons, or “this assumption is wrong because...” feedback would be appreciated.

[KingAustraliaggGG]

I also have been looking into whether there is already a tool that can take TunerPro XDF/BIN calibration metadata and push it into Ghidra automatically, ideally through "analyzeHeadless", so the disassembly ends up with useful labels, comments, typed data, hardware labels, recovered references, and an audit report.

What I found so far:

There are already some partial tools around this idea, but I have not found one complete public pipeline that does the full job.

The closest direct example I found is ColPaulR’s Ghidra scripts for PCM hacking. That repo has "ImportXDF.py" and "ImportPID.py". The XDF script reads a TunerPro XDF and creates Ghidra labels for XDF flags, constants, and tables. That proves the basic XDF-to-Ghidra labelling idea is already valid.

Another useful reference is the MED9 Ghidra script repo. That one is more Bosch/MED9/WinOLS JSON focused, but the pattern is similar: take external map metadata, bring it into Ghidra, mark bytes/data, and add comments.

Ghidra itself already has the pieces needed for the rest. "analyzeHeadless" can import/process a binary and run pre/post scripts. Ghidra’s API also has "ReferenceManager", which can add memory references, offset references, register references, and query existing references. So the missing bit is not really a Ghidra limitation. It is the ECU/XDF-specific glue.

What I already have on my GitHub:

1. TunerPro-XDF-BIN-Universal-Exporter

This is probably the strongest starting point. It already parses XDF + BIN directly and exports calibration metadata to TXT, JSON, Markdown, and CSV. It handles XDF constants, flags, tables, headers, patches, "BASEOFFSET", "mmedtypeflags", address translation, endian handling, table extraction, axis extraction, statistics, zero-table detection, and address boundary checks.

That means I already have most of the XDF/BIN metadata normalisation layer. This is the part that could feed Ghidra.

Current role in the future bridge:

XDF/BIN → neutral JSON/CSV symbol metadata

Example output concept:

{
"symbols": [
{
"name": "Main Spark Table",
"kind": "table",
"xdf_address": "0x57AF",
"file_offset": "0x57AF",
"rows": 16,
"cols": 17,
"units": "degrees",
"source": "xdf"
}
]
}

2. tunerpro-xdf-bin-cli-map-editor

This is the deterministic edit/diff/preflight layer. It can read maps from BINs through XDFs, edit cells, write a new BIN, generate diffs, and preserve the original file. It was built so AI agents or scripts can interact with ECU calibration data through strict CLI commands instead of guessing values in chat.

Current role in the future bridge:

It proves the CLI pattern and audit-style workflow already works.

The Ghidra bridge should follow the same philosophy:

No blind guessing.
No automatic tuning.
No hidden changes.
Everything logged.
Human review first.

3. kingaustraliagg-vy-l36-060a-enhanced-asm-patches

This repo is the Holden VY/VX L36 "$060A" 68HC11 assembly research base. It includes patch templates, hook point work, bank-awareness notes, RAM variable work, free ROM space mapping, and static reference scanning.

This is where the hardware-label and xref-recovery side becomes relevant.

For example, it already documents things like:

RAM variables such as "$00A2", "$017B", "$0199", "$194C"

hook points such as "$101E1"

free space ranges such as "$C468-$FFBF"

bank-switching issues

bit usage analysis around "$0046"

reference scanning for operations like "BSET", "BCLR", "BRSET", "BRCLR"

That is exactly the type of information that should become Ghidra labels, comments, and recovered references.

Current role in the future bridge:

HC11 ECU profile + hardware/RAM labels + known hook/free-space metadata.

4. KingAi_68HC11_C_Compiler

This is a subset-C compiler/toolkit for 68HC11/Delco-style ECUs. It can compile simple C to HC11 assembly/binary, assemble, disassemble, patch ROMs, find free space, verify/fix checksums, convert addresses, parse XDFs, and identify binaries.

It is still WIP and needs hardware validation, but it already contains target profile logic and address/memory-map logic.

Current role in the future bridge:

HC11 target profile logic, disassembler/reference logic, and memory-map handling.

5. KingAi-VY-V6-L36-Commo-Flasher

This is the VY V6 "$060A" flasher/datalogger/table-editor side. It is not a Ghidra project, but it has practical target information: ALDL protocol, 68HC11 kernel flow, bank mapping, sector layout, checksum flow, virtual ECU, and table editor work.

Current role in the future bridge:

Validation context. Static analysis should eventually line up with real read/write/datalog behaviour.

So my rough conclusion is:

I already have maybe 70% of the useful ECU-specific side:

XDF parsing
BIN reading
BASEOFFSET/address translation
table/scalar/flag extraction
patch detection
diff/audit style workflow
HC11-specific RAM/address research
bank-aware disassembly work
target profiles
free-space and hook-point notes

The missing 30% is the actual Ghidra bridge:

1. Export my existing XDF/BIN metadata into a clean Ghidra symbol JSON/CSV format.

2. Create a Ghidra Jython or PyGhidra script that can run under "analyzeHeadless".

3. Import those symbols into Ghidra as labels.

4. Add comments and typed data for constants, flags, and tables.

5. Import hardware/RAM labels from ECU profiles.

6. Recover xrefs by scanning instructions and operands for references to known XDF symbols, RAM variables, hardware registers, and pointer tables.

7. Export an audit report showing what was created, skipped, duplicated, or suspicious.

The proposed tool name/description would be something like:

Ghidra Headless Bridge converts XDF/BIN-derived calibration metadata and ECU hardware profiles into Ghidra labels, comments, typed data, recovered xrefs, and audit reports.

The first target would probably be Holden VY/VX V6 "$060A" 68HC11 because that is where I already have the most research. After that, the same idea could be extended to other Delco/GM OSIDs, BMW MS42/MS43/MS45, Ford EEC, Bosch ME7/MED9, or anything where an XDF/A2L/CSV definition and binary can be matched reliably.

Important boundary:

This is not meant to be “AI tunes your car”.

It is a reverse-engineering and documentation bridge.

The idea is to take information that already exists in XDFs, BINs, hardware notes, RAM maps, and disassembly work, then make Ghidra more useful automatically. It should help humans review firmware faster, not replace human judgement.

What I am thinking of building next:

"kingai-ecu-ghidra-headless-bridge"

Possible flow:

python export_symbols.py tune.xdf firmware.bin --profile vy_v6_060a --out symbols.json

analyzeHeadless ./ghidra_projects VY060A \
-import firmware.bin \
-scriptPath ./ghidra_scripts \
-postScript ImportKingAiSymbols.py symbols.json \
-postScript ImportHwLabels.py profiles/vy_v6_060a_hw.yaml \
-postScript RecoverHC11Xrefs.py symbols.json \
-postScript ExportAudit.py report/

Expected outputs:

"labels_created.csv"

"labels_skipped.csv"

"xrefs_created.csv"

"unresolved_symbols.csv"

"match_score.md"

"ghidra_import_report.md"

The part I would like feedback on from people here:

Is anyone already doing a cleaner XDF-to-Ghidra or XDF-to-symbol import workflow?

For 68HC11/Delco, what hardware/RAM labels would be worth standardising first?

For "$060A", would people prefer the first proof-of-concept to focus on calibration table labels, RAM variable labels, or xref recovery?

Are there known Ghidra HC11 processor-module limitations I should design around early?

Any examples of good symbol CSV/JSON formats people already use for IDA/Ghidra would also help.