samplez/tunie/research/FINDINGS.md

Seed/key recovery — findings

Question

Is the Triumph Keihin KWP2000 Security Access (service 0x27) seed/key algorithm recoverable, and does the logging APK help?

Answer

Yes, fully — and from the static decompile, so the logging build isn't needed for it. The algorithm is AES-128, and all key material is embedded in the app. RESEARCH.md's prediction ("Honda-style XOR / bit-shift with a factory constant, possibly brute-forced") was wrong about the primitive.

Where it lives

com/tuneecu/m.java, method Vb() (jadx), = Lcom/tuneecu/m;->Vb()I (smali).

Evidence in Vb()	What it proves
sArr = {1,2,4,8,16,32,64,128,27,54}	AES Rcon (0x01,02,04,08,10,20,40,80,1B,36)
4 table lookups/column at +0,+256,+512,+768	AES T-tables (Te0–Te3)
10-iteration loop building 44 words	AES-128 key expansion
9 rounds + 1 S-box-only final round	AES-128 encryption
iArr3 = w.f first entry 0xA56363C6	(3·S0, S0, S0, 2·S0) with S0=0x63 → standard S-box + MixColumns

Verified: all 256 entries of w.f match the standard AES Te0 table exactly (keihin_seedkey.py cross-checks them). Our reference AES also passes the FIPS-197 Appendix-B known-answer test. This is unmodified AES-128.

What Vb() does

1. Loads a 128-bit seed block into Ie[0..3] from the ECU's 0x27 seed response.
2. AES-128-encrypts it with one of three embedded keys (iArr4, m.java:5351), selected by MainActivity.h7 ∈ {0,1,2}.
3. Returns the first ciphertext word; Gd() sends it as 27 02 <4 bytes>.

The three keys (little-endian, as the cipher consumes them):

h7=0: ef704ca051b800cc9287df6a3511a978
h7=1: d4b15ff4c92ab7f098316e7a5b11ac39
h7=2: dc9fdba46f2fad18a4b8e1123c7183c2

h7 is looked up from an ECU calibration-code string (MainActivity.java:6221).

Still open (framing, not crypto — one captured pair resolves both)

1. Which key applies to a mechanical-odometer 865 twin. h7 defaults toward 0 for the older no-code Keihin maps, but confirm rather than assume.
2. Exact seed-block layout. Vb() encrypts Ie[0..3]; m.java fills Ie[1..3] from the seed response and pads two bytes with fixed constants (0x03, 0x01), with Ie[0] set on an earlier path. A single real (seed, key) pair pins this down exactly.

The logging APK

work/TuneECU-logging.apk is a clean apktool rebuild of the original (the ~17 KB size delta is re-signing/recompression). No custom instrumentation was found — every Log call is TuneECU's own, gated behind its debug boolean, and no debuggable flag is set. So it does not currently capture seed/key at runtime.

It's still the right tool for the validation step above: make the app perform one real Security Access against the bike (or a bench ECU) and capture the 27 01 seed and 27 02 key off the wire, then check compute_key(seed, h7) reproduces it. That either confirms the port outright or tells us the exact h7/padding.

Reference implementation

research/keihin_seedkey.py — pure-Python, self-testing. Run it:

python3 research/keihin_seedkey.py

Boundary

This is write-path material. It is kept in research/, outside the read-only tunie package, and tunie does not import it. Reproducing the key does not make flashing safe — it's one of several pieces (checksum patching, a verified stock dump, a recovery plan, ideally a spare ECU) that all have to line up first.