Disassemblers used? First modifications to P59

[NSFW]

It's my understanding that the '603 OS can be made to work on all platforms, but I have to admit that I've never tried it.

If it is indeed possible to use that OS everywhere, then that would save a bunch of labor in porting changes from one OS to another. And in locating new tables and constants in each different OS.

I think the Subaru world kinda suffers from having dozens of firmware images that are unique to each model and year. Whenever somebody comes up with a new table or hack, half of that work needs to be replicated for every additional model and year so that more people can benefit.

[jlvaldez]

From the info I have this should do it. Write full after the change.
Lean cruise patch for 12579405:
0002AAB8 66 to 4E
0002AAB9 06 to 71

I've got those bytes at the addresses you listed. I'll try changing them.

For whatever reason, I cannot find any references to these addresses in what my disassembler could disassemble. Not sure why. It just shows as undisassembled code

This compiler only had a 68000 cold fire instruction set, so i'm not sure which instructions are missing from CPU32. I'll probably do some digging to see if CPU32 support would be hard to add. I can't speak to IDA, but Ghidra seems very powerful, just lacking the full instruction set, which might be why it couldn't decompile the entirety of my binary.

Thanks for this. This will give me what I want, but I still want to dig more into this. This is very interesting to me and I love seeing how things work.
Edit 3: Looks like it doesn't auto decompile parts of it because it barfs on the missing table instructions that aren't in the standard 68k instruction set. If i manually compile functions around it, this code makes sense. Looks like the patch code you have changes the bne offset of 6 to a NOP. I love it. Took me a solid 30 minutes with the CPU32 instruction set document open to figure out what these bytes did, but I'm glad I now understand exactly what is being changed.


NSFW,
Have you by any chance tried flashing a different binary to an PCM? If I upload 706 and modify everything so that it's from my tables, would I be able to revert to my old binary if I accidentally brick it? From what I've seen in the PCM hammer threads, you might be SOL if you mess up the flash.

Does the 706 OS support the intel flash that my PCM apparently has? Seems 706 was only put on PCMs with the AMD flash.

EDIT: I was doing some googling and stumbled across this issue for Ghidra that was filed, and they mentioned that they made a fork to start adding CPU32 instruction set from the 683xx family!! Perhaps we can assist the fork and get a free decompiler that's platform independent (I use Linux for my desktop and server environments) and quite powerful!
https://github.com/NationalSecurityAgen ... ssues/1244

Edit 2: The fork doesn't work for me. I added the new language files he added and it doesn't work for me. Digging through the error logs isn't very helpful. Perhaps someone more familiar with decompilers than myself might have more luck.

Edit 3: If I don't use their patched 68000.sinc file, it compiles the .sla file without errors. However, it doesn't seem to understand the tbl instructions. I think understanding the problems and fixing them might be outside the realm of my current understanding. I'm a little too green to decompilers to immediately hop into a language file and understand all the errors and make necessary changes

[NSFW]

I've done an OS change on a P01, but haven't tried it yet on a P59. However it's probably just a matter of enabling the feature in the app and in the kernel. We disabled OS replacement on P59s temporarily so we could test P59 calibration changes first, since a bad calibration flash is easier to recover from than a bad OS flash.

At this point I want to fix a kernel bug that just came up, and then do another release, but I think we're ready to try OS flashing after that.

[jlvaldez]

I guess I'll be waiting for the update to PCM hammer.

So now that I have the offset and the bytes I want to change, how do I get tuner pro to update the checksums? Is this automatic? I feel like a noob with this part.

I've been unsuccessful at reaching out to the Ghidra CPU32 guy, but now that I'm home, I've been playing with the .sla file to try and get his modifications to compile.

[antus]

What tunerpro does is dependant on your xdf file. It can easily do the calibration segment 16bit sums but it cant do the os sums without a plugin because it can only sum a contiguous block and the os sum is calculated over 3 non contiguous blocks. My plugin takes the start and end addresses from tunerpro then ignores the non os areas as it calcs the sums. Ive released plugins to do this and others have ripped of my plugins and removed my name from them but they still work. If the xdf has a plugin it'll probably be able to handle the os sum. Alternatively just calculate it by hand. Add up each 16bit word through the 3 ranges and keep the low 16 bits of the result. P59 is the same as P01 but keep adding to the end of the bin.

[jlvaldez]

That's very helpful. I didn't realize it's as simple as addition thank you
Could be a simple python script.

So I take it that I simply add the 16 bit words together through the 3 segments of the OS segment. Does the end of the OS segment ever change? Surely each version had a different length, or do you inlcude the 0xFF padding bytes? Not at my computer right now to see what the end address is.

[antus]

Include the padding bytes and cover the exact ranges. Later pcms have an index table that tells you the ranges. These ones are static. Yep its literally a check sum.

[jlvaldez]

Thanks for all your help and patience with me. I've pieced it all together into a crappy little python script that can validate and update checksums for P01 and P59

[ShorTuning]

I wrote down the steps I used to get started with the OS in my Corvette using IDA:
https://github.com/LegacyNsfw/12593358/wiki/How-To

I had a head start since there is an XDF for that OS, but I don't think that's a requirement. The OS also has a table of OBD2 PIDs and function pointers, and those pointers mostly refer to very short functions that just read a value from RAM and convert it to the units required for OBD2. So you can pretty confidently label those RAM addresses with the OBD2 parameter name. That lead to having labeled RAM addresses in a lot of code, and that gives you some hints about what the code might be doing.

An XDF would be a big help but if you've already found the line you want in another OS, I suspect you'll be able to find it in this OS. If you have HPT for your current OS, you can try making changes to tables in HPT, reading the bin file with PCM Hammer / LS Droid, and then comparing the files to see where the table is. It would be time consuming to build an XDF that way but you probably only need a few tables to help you find the code you're interested in.

I have been using IDA, but Ghidra sounds very interesting and I need to give it a try. Since it's free and apparently quite capable, I think that's going to become the standard tool for reverse engineering PCMs.

If you have the option of switching to the 12587603 OS, that would be great, because I think that's where most P59 OS hacking is going to happen. That OS seems to support every option of transmission, DBW, DBC, etc.

What change are you planning to make? I've been trying to find the code that disables the high octane timing table when you disable the MAF sensor... I'm not there yet but I think I'm getting close.

I opened up my copy of TIS2000, looks like my options for OSes for my VIN are (from oldest to newest)
12578128 (initial release)
12579405 (What i'm currently on)
12580055
12593058

Doesn't look like 12587603 is an option for me I've got a 2003 Silverado 2500 HD 6.0/4L80E

To be specific. I'm trying to bypass the platform check for lean cruise. You can set the platform manually in HPT, but for whatever reason the cruise control stops working when the platform code is changed. So I want to simply change the branch on not equal to branch on equal.

A quick google for me shows no luck finding an XDF for this OS either... However, it did point me to a thread where Gampy was making a comment about this OS just a few days ago in the LS Droid thread.

I found on NSFW's GitHub, this txt file that talks about the advantages of the 7603 OS. Says that all combinations are supported by this OS. However, TIS2000 does not show it as an option for me. I wonder if I can flash it with my TECH2 using a different VIN. Or if I should simply flash a 7603 binary onto the truck with PCMHammer and then use HPT to copy over all of my tune edits...

Edit: So i was digging through NSFW's XDF for 7603, and it looks like you already have an OS patch to do exactly what I want to do... Hmmmmm

Edit 2: The patch doesn't seem to point to a valid location in a 04 Z06 .bin... Nothing refers to the address in the patch according to my decompiler. Weird thing is I can't find the lean cruise branch code. Maybe the enable is different than the 411 PCMs (which I found it in originally).

Use this and write entire into your PCM. You can apply your VIN to the file and it will be the same overall tune with the newer '603 OS.

2004 Silverado 2500HD 4L80E 6.0L LQ4 (12587603).bin

(1 MiB) Downloaded 269 times