I have recently got into Spanish Oak. Read a bin off a bench harness using my OBD Xpro FT. Got the Super Duty controller — physically different case than the car/F150 units, so I don't know yet if everything transfers the same as far as readable addresses and sizes. This one's 2MB. Didn't crack the case open, but I suspect calibration lives on an external flash chip, with the RTOS/bootloader stuff in the onboard 1MB. One thing I did confirm: ask for a bad address and you get a proper NRC — it's not handing back fake data, it just tells you no.
While I was in there I also dug into the security access side, since it wasn't quite what I expected going in. The seed/key handshake isn't doing any live math on the PCM. I went looking for the actual algorithm in the binary — constants, loop structure, all of it — and came up empty. Turns out the PCM just stores a fixed seed and a fixed expected key, and compares whatever it's sent against that. Same seed every time you ask. Whatever's actually computing a valid response lives entirely on the tool side, not the chip.
Once unlocked, there are three tiers, each tied to a string token written into memory after a successful unlock — basic read access, a calibration read tier, and one above that. All three seem to get set together off a single unlock, though I haven't fully confirmed that holds in every case.
There's a decent amount of integrity-checking wrapped around the unlock itself (call-chain checks, session timeouts), so it's not naive — just not modern crypto either. Pretty in-character for Ford in that era.
Validated all of this against a real unit, lines up with the static-seed theory.
More to come as I dig into what that top tier actually opens up.
EEC VI Power PC
-
Ralmo94
- Posts: 25
- Joined: Thu Mar 12, 2026 10:00 pm
- cars: 1995 towncar
1994 k1500
1998 k2500 7.4
2002 Tahoe 5.3
2004 Silverado 1500
2008 F250 5.4
EEC VI Power PC
OEM boxes. Open questions. Closed source.
The engine knows what it wants. The ECU knows what it got.
If the bootloader can read it, so can we.
The silicon doesn't lie — it's just not telling the whole story.
The engine knows what it wants. The ECU knows what it got.
If the bootloader can read it, so can we.
The silicon doesn't lie — it's just not telling the whole story.
-
Ralmo94
- Posts: 25
- Joined: Thu Mar 12, 2026 10:00 pm
- cars: 1995 towncar
1994 k1500
1998 k2500 7.4
2002 Tahoe 5.3
2004 Silverado 1500
2008 F250 5.4
Re: EEC VI Power PC
Quick update on the Spanish Oak digging — got some bench time in to nail down the calibration location question I was still fuzzy on.
One scope note up front: this is all from the Super Duty controller specifically. Still haven't confirmed whether the car/F150 units are wired the same way internally.
Read the full internal 1MB (0x000000) and got a clean dump — no NRCs, no fake data, consistent with what I mentioned before. No calibration tables in there at all though; it's straight OS/bootloader content. Kept probing addresses and got another full 1MB positive response starting at 0x800000. That's not part of the same physical block — the internal flash maxes out well below that address — so this has to be a separate chip on the bus, addressed through one of the external chip-selects.
Confirmed it with a controlled test: used commercial software to change a single 16-cell calibration table, then diffed both 1MB reads against my originals. The second block (0x800000) showed the actual table change, right where expected. The first block (internal) showed only 2 bytes different — and only those 2 bytes, both times I repeated the test with different table edits. Looks like a checksum that covers the external calibration data but lives internally, separate from the data it's checking.
Lines up with other Spanish Oak threads mentioning three separate checksums covering different regions — they kept specifics vague, but my results back up at least one living internally. My suspicion is one covers calibration, one covers the RTOS, and one covers the bootloader. Want to test if a bigger edit spanning more regions moves more bytes — haven't gotten to that yet.
So to add onto what I said before: calibration sits on external flash at 0x800000, separate from the internal image, and integrity checking is handled back on that internal side rather than alongside the data itself. Useful if you're trying to figure out what's actually safe to touch vs. what the PCM is watching — at least for Super Duty so far. If anyone's bench-tested a car or F150 unit, curious if it matches.
One scope note up front: this is all from the Super Duty controller specifically. Still haven't confirmed whether the car/F150 units are wired the same way internally.
Read the full internal 1MB (0x000000) and got a clean dump — no NRCs, no fake data, consistent with what I mentioned before. No calibration tables in there at all though; it's straight OS/bootloader content. Kept probing addresses and got another full 1MB positive response starting at 0x800000. That's not part of the same physical block — the internal flash maxes out well below that address — so this has to be a separate chip on the bus, addressed through one of the external chip-selects.
Confirmed it with a controlled test: used commercial software to change a single 16-cell calibration table, then diffed both 1MB reads against my originals. The second block (0x800000) showed the actual table change, right where expected. The first block (internal) showed only 2 bytes different — and only those 2 bytes, both times I repeated the test with different table edits. Looks like a checksum that covers the external calibration data but lives internally, separate from the data it's checking.
Lines up with other Spanish Oak threads mentioning three separate checksums covering different regions — they kept specifics vague, but my results back up at least one living internally. My suspicion is one covers calibration, one covers the RTOS, and one covers the bootloader. Want to test if a bigger edit spanning more regions moves more bytes — haven't gotten to that yet.
So to add onto what I said before: calibration sits on external flash at 0x800000, separate from the internal image, and integrity checking is handled back on that internal side rather than alongside the data itself. Useful if you're trying to figure out what's actually safe to touch vs. what the PCM is watching — at least for Super Duty so far. If anyone's bench-tested a car or F150 unit, curious if it matches.
OEM boxes. Open questions. Closed source.
The engine knows what it wants. The ECU knows what it got.
If the bootloader can read it, so can we.
The silicon doesn't lie — it's just not telling the whole story.
The engine knows what it wants. The ECU knows what it got.
If the bootloader can read it, so can we.
The silicon doesn't lie — it's just not telling the whole story.
-
antus
- Site Admin
- Posts: 10013
- Joined: Sat Feb 28, 2009 10:34 am
- cars: TX Gemini 2L Twincam 8psi
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Subaru WRX 2007
Re: EEC VI Power PC
Good info 
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
-
Ralmo94
- Posts: 25
- Joined: Thu Mar 12, 2026 10:00 pm
- cars: 1995 towncar
1994 k1500
1998 k2500 7.4
2002 Tahoe 5.3
2004 Silverado 1500
2008 F250 5.4
Re: EEC VI Power PC
I thought I would share the bin I pulled incase anyone wants to take a look at one.
Actually it is 2 bins because of the external flash chip for the calibration. BenchRead_flash starts at 0x0 and BenchRead_cal starts at 0x800000
You do not have the required permissions to view the files attached to this post.
OEM boxes. Open questions. Closed source.
The engine knows what it wants. The ECU knows what it got.
If the bootloader can read it, so can we.
The silicon doesn't lie — it's just not telling the whole story.
The engine knows what it wants. The ECU knows what it got.
If the bootloader can read it, so can we.
The silicon doesn't lie — it's just not telling the whole story.
-
pman92
- Posts: 667
- Joined: Thu May 03, 2012 12:50 pm
- Location: Castlemaine, Vic
Re: EEC VI Power PC
Same as the aussie spanish oaks, just with extra external flash like our black oaks have.
RTOS/Bootloader is 0x0000 to 0xFFFF which cant be erased / written over OBD.
0x10000 onwards (including external flash) is the strategy / calibration.
RTOS/Bootloader is 0x0000 to 0xFFFF which cant be erased / written over OBD.
0x10000 onwards (including external flash) is the strategy / calibration.
-
Ralmo94
- Posts: 25
- Joined: Thu Mar 12, 2026 10:00 pm
- cars: 1995 towncar
1994 k1500
1998 k2500 7.4
2002 Tahoe 5.3
2004 Silverado 1500
2008 F250 5.4
Re: EEC VI Power PC
Interesting, due the Aussie ones also have a different case and connectors ?pman92 wrote: Tue Jun 23, 2026 6:19 am Same as the aussie spanish oaks, just with extra external flash like our black oaks have.
RTOS/Bootloader is 0x0000 to 0xFFFF which cant be erased / written over OBD.
0x10000 onwards (including external flash) is the strategy / calibration.
OEM boxes. Open questions. Closed source.
The engine knows what it wants. The ECU knows what it got.
If the bootloader can read it, so can we.
The silicon doesn't lie — it's just not telling the whole story.
The engine knows what it wants. The ECU knows what it got.
If the bootloader can read it, so can we.
The silicon doesn't lie — it's just not telling the whole story.
-
Ralmo94
- Posts: 25
- Joined: Thu Mar 12, 2026 10:00 pm
- cars: 1995 towncar
1994 k1500
1998 k2500 7.4
2002 Tahoe 5.3
2004 Silverado 1500
2008 F250 5.4
Re: EEC VI Power PC
I have an update.
I got brave and tested a write to my bench pcm. It erased and then failed.
My flashing utility did not handle that correctly, leaving my pcm blank except for the boot loader.
I was able to read it after the erase, but not write to it. I think I have the bug figured out and will test.
I did manage to flash it with HP Tuners with the file for my truck that i had credits for.
I have the MPV1, and it times out during the erase process during a flash and is designed to resume after a time out so it flashed.
Now the bench PCM has a vin matching the truck, this means that the vin has to be in the section that gets erased.
HPT now sees the bench pcm the same as the truck pcm that I have credits for. This unexpected turn of events will speed up RE progress.
Another thing I figured out is since this is a truck platform and not a standard car regulations and it does not respond to obd2 mode 9 requests for vin or calibration ID. Hpt apparently obtains this info with a proprietary ford diagnostics.
I have 2 f150 pcm's on the bench now as well. One from an 05 5.4, and one from an 06. My brother has a 06 truck that needs engine work, I tested the 05 PCM in the 06 truck, and Forscan would not talk to it, or my xtool d7. My theory is that 05 needs the legacy spc?
neither the 05 or 06 will talk on the bench.
An ai said that I might need to connect all 3 keyed power wires, because they may not power all rails if only one is connected?
I obtained part of an 05 factory service manual with wiring charts, and there is 3 wires for key power.
I have not tested that theory yet. All of my pcm time has been focused on the empty pcm that I just recovered this morning.
After I get some more of the kinks worked out of my flashing utility, I would invite anyone to look at it that knows python and UDS.
I personally do not code and rely on AI for all of my code generation, and would appreciate a human eye on it before I trust it or share it publicly.
Right now it is too much of a mess for that though. I plan to also add support for NGC3 at some point since they also seem to use the same kind of chip.
I don't know if I will release free or not yet, but If I charge for it, it will be cheap.
All testing has been done with OBDX Pro FT at this point.
I got brave and tested a write to my bench pcm. It erased and then failed.
My flashing utility did not handle that correctly, leaving my pcm blank except for the boot loader.
I was able to read it after the erase, but not write to it. I think I have the bug figured out and will test.
I did manage to flash it with HP Tuners with the file for my truck that i had credits for.
I have the MPV1, and it times out during the erase process during a flash and is designed to resume after a time out so it flashed.
Now the bench PCM has a vin matching the truck, this means that the vin has to be in the section that gets erased.
HPT now sees the bench pcm the same as the truck pcm that I have credits for. This unexpected turn of events will speed up RE progress.
Another thing I figured out is since this is a truck platform and not a standard car regulations and it does not respond to obd2 mode 9 requests for vin or calibration ID. Hpt apparently obtains this info with a proprietary ford diagnostics.
I have 2 f150 pcm's on the bench now as well. One from an 05 5.4, and one from an 06. My brother has a 06 truck that needs engine work, I tested the 05 PCM in the 06 truck, and Forscan would not talk to it, or my xtool d7. My theory is that 05 needs the legacy spc?
neither the 05 or 06 will talk on the bench.
An ai said that I might need to connect all 3 keyed power wires, because they may not power all rails if only one is connected?
I obtained part of an 05 factory service manual with wiring charts, and there is 3 wires for key power.
I have not tested that theory yet. All of my pcm time has been focused on the empty pcm that I just recovered this morning.
After I get some more of the kinks worked out of my flashing utility, I would invite anyone to look at it that knows python and UDS.
I personally do not code and rely on AI for all of my code generation, and would appreciate a human eye on it before I trust it or share it publicly.
Right now it is too much of a mess for that though. I plan to also add support for NGC3 at some point since they also seem to use the same kind of chip.
I don't know if I will release free or not yet, but If I charge for it, it will be cheap.
All testing has been done with OBDX Pro FT at this point.
OEM boxes. Open questions. Closed source.
The engine knows what it wants. The ECU knows what it got.
If the bootloader can read it, so can we.
The silicon doesn't lie — it's just not telling the whole story.
The engine knows what it wants. The ECU knows what it got.
If the bootloader can read it, so can we.
The silicon doesn't lie — it's just not telling the whole story.
-
pman92
- Posts: 667
- Joined: Thu May 03, 2012 12:50 pm
- Location: Castlemaine, Vic
Re: EEC VI Power PC
The VIN is in the VID block, which as you worked out is part of the section which can be erased and programmed (right near the start around 0x10000).
There is a serial number in the bootloader section, specific to each PCM, that cannot be erased and programmed. Kind of funny if HPT doesn't use it.
Spanish Oak is not UDS, at least in the case of the spanish oaks we have here. And I assume yours would be the same. It is fords GDS (global diagnostic specification), which is basically KWP2000 and similar to UDS.
If you're just trying to read/write the PCM, then PCMflash can do so.
There is a serial number in the bootloader section, specific to each PCM, that cannot be erased and programmed. Kind of funny if HPT doesn't use it.
Spanish Oak is not UDS, at least in the case of the spanish oaks we have here. And I assume yours would be the same. It is fords GDS (global diagnostic specification), which is basically KWP2000 and similar to UDS.
If you're just trying to read/write the PCM, then PCMflash can do so.
-
Ralmo94
- Posts: 25
- Joined: Thu Mar 12, 2026 10:00 pm
- cars: 1995 towncar
1994 k1500
1998 k2500 7.4
2002 Tahoe 5.3
2004 Silverado 1500
2008 F250 5.4
Re: EEC VI Power PC
Good point I remember that now. Interesting, After reading your reply I wondered what forscan showed, and it showed the vin that matches the truckpman92 wrote: Sun Jul 05, 2026 2:41 pm The VIN is in the VID block, which as you worked out is part of the section which can be erased and programmed (right near the start around 0x10000).
There is a serial number in the bootloader section, specific to each PCM, that cannot be erased and programmed. Kind of funny if HPT doesn't use it.
Code: Select all
[11:45:24.595] Connection to adapter has been established: J2534 OBDX Pro FT
[11:45:24.596] Adapter: OBDX Pro FT
[11:45:25.396] Connection to vehicle has been established
[11:45:28.531] Vehicle: Ford F-Series Super Duty 3V 5.4L 2008 ( 2008 MY ), VIN: 1FT********00420
[11:45:30.710] Found module: OBD2_PCM - On Board Diagnostic II (PCM)
[11:45:30.945] DTCs in OBD2_PCM: P0122-P, P0223-P, P0706-P
[11:45:33.103] Found module: PCM - Powertrain Control ModuleCode: Select all
Hardware Spanish Oak 2048K, ECM, Ford
VIN 1FTNF205X8EB26828
Operating System... TDDG5N9
IDInteresting...pman92 wrote: Sun Jul 05, 2026 2:41 pm Spanish Oak is not UDS, at least in the case of the spanish oaks we have here. And I assume yours would be the same. It is fords GDS (global diagnostic specification), which is basically KWP2000 and similar to UDS.
If you're just trying to read/write the PCM, then PCMflash can do so.
I have read multiple bins with my own software, I thought it was UDS, but I really don't know.
If there is no interest in my tool I am perfectly happy to keep it as my own hobby. Not trying to step on anybody elses work.
the pcm tec development blog inspired me to look into this in the first place. I have seen the youtube videos of some of the custom stuff they can do, pretty cool.
Here is a log of my tool before I realized it had the external flash chip. Is there enough information to say if it is UDS or not?
Code: Select all
[15:41:06] Found 2 J2534 device(s).
[15:41:09] DLL: C:\Program Files (x86)\OBDX Pro\J2534\OBDX Pro FT\OBDXFT_J2534_32bit.dll
[15:41:10] Connected: OBDX Pro FT @ HS CAN 500k
[15:41:46] [FEPS] Applying programming voltage to pin 13 (18v)...
[15:41:46] [FEPS] FEPS active.
[15:41:46] [FEPS] === IGNITION CYCLE REQUIRED ===
[15:41:46] [FEPS] Turn ignition OFF now. Wait 3 seconds. Then turn ON.
[15:41:52] [FEPS] Boot window open. Proceeding with security unlock.
[15:41:52] [SESSION] Starting session 0x85...
[15:41:52] [SESSION] Session 0x85 started OK.
[15:41:52] [SESSION] Keep-alive started.
[15:41:52] [SEC] Requesting seed (Service 0x27 0x01)...
[15:41:52] [SEC] Seed received: C4F0D6
[15:41:52] [SEC] Trying 485 known keys...
[15:41:52] [SEC] Access GRANTED with key #126: [8, 48, 97, 164, 197]
[15:41:52] [MEM] Starting full read (1024KB)...
[15:41:52] [MEM] Output: D:/Auto/08 F250 Spare pcm.bin
[15:41:52] [MEM] Waiting briefly before first read...
[15:41:53] [MEM] TX 0x23 mem_id=0x00 @ 0x000000 size 0x0080: 000007e023000000000080
[15:41:53] [MEM] RX raw: 000007e863000000000000000000000000000000001060000000000000000000000000000000007efc436f707972696768742028432920466f7264204d6f746f7220436f6d70616e7920313939332c313939342c313939352c313939362c313939372c313939382c313939392c323030300000000000000000000000000000000000000000
[15:41:53] [MEM] TX 0x23 mem_id=0x00 @ 0x000080 size 0x0080: 000007e023000000800080
[15:41:53] [MEM] RX raw: 000007e863000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002bd5640e
[15:41:53] [MEM] TX 0x23 mem_id=0x00 @ 0x000100 size 0x0080: 000007e023000001000080
[15:41:53] [MEM] RX raw: 000007e8637c7043a67c9143a67cb243a63c60000060632600a08300ca7c9e9ba6808300cc80a300dc90a40000808300d480a300e090a4000080a300e490a4004080a300e890a4002880a300ec90a400687c7042a67c9142a67cb242a67c7043a63c60003f6063fd107c6118507c21196e7c7042a6906100209081002490a1002890c1002c
[15:41:53] [MEM] TX 0x23 mem_id=0x00 @ 0x000180 size 0x0080: 000007e023000001800080
[15:41:53] [MEM] RX raw: 000007e8637c7a02a6906100087c7b02a69061000c7c7302a6906100107c7202a6906100147c6802a6906100187c6000269061001c3c60002f6063c000a08302883ca055cc60a5aa3390a30388b083028870850800418200087ca42b7890810014480078244f5add88ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
[15:41:53] [MEM] TX 0x23 mem_id=0x00 @ 0x000200 size 0x0080: 000007e023000002000080
[15:41:53] [MEM] RX raw: 000007e8637c7043a63c60003f6063fd507c6118507c21196e7c7042a6906100209081002490a1002890c1002c7c7a02a6906100087c7b02a69061000c7c7302a6906100107c7202a6906100147c6802a6906100187c6000269061001c3c60000238630000480072a54800769cda1c55edffffffffffffffffffffffffffffffffffffffff
[15:41:53] [MEM] TX 0x23 mem_id=0x00 @ 0x000280 size 0x0080: 000007e023000002800080
[15:41:53] [MEM] RX raw: 000007e863ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
[15:41:53] [MEM] TX 0x23 mem_id=0x00 @ 0x000300 size 0x0080: 000007e023000003000080
[15:41:53] [MEM] RX raw: 000007e8637c7043a63c60003f6063fd507c6118507c21196e7c7042a6906100209081002490a1002890c1002c7c7a02a6906100087c7b02a69061000c7c7302a6906100107c7202a6906100147c6802a6906100187c6000269061001c3c60000338630000480071a54800759c072a2d56ffffffffffffffffffffffffffffffffffffffff
OEM boxes. Open questions. Closed source.
The engine knows what it wants. The ECU knows what it got.
If the bootloader can read it, so can we.
The silicon doesn't lie — it's just not telling the whole story.
The engine knows what it wants. The ECU knows what it got.
If the bootloader can read it, so can we.
The silicon doesn't lie — it's just not telling the whole story.
-
pman92
- Posts: 667
- Joined: Thu May 03, 2012 12:50 pm
- Location: Castlemaine, Vic
Re: EEC VI Power PC
It sounds like what your doing will be a great learning experience, I'm not saying you shouldn't be doing it. Just pointing out if your end goal is just read/write bins then there are already options available to save you the development.Ralmo94 wrote: Sun Jul 05, 2026 5:08 pm I have read multiple bins with my own software, I thought it was UDS, but I really don't know.
If there is no interest in my tool I am perfectly happy to keep it as my own hobby. Not trying to step on anybody elses work.
GDS / KWP2000 and UDS are all very similar, with subtle differences that might trip you up (particularly with UDS which is much newer). You can find documentation on google for reference:
https://www.cds.caltech.edu/~murray/dgc ... 2003.0.pdf
I've never actually fully checked out the write process of the PCM myself. But from my work on other modules from same age ford vehicles here is Australia, I suspect the erase might be done with a mode 0xB1 diagnostic command - which is a ford mode specific to GDS and not part of UDS.
Next time I am writing one with PCMflash I will get a datalog of it and post it up.