Re: Ford MPC565 Tuning
Posted: Wed Jan 11, 2017 11:34 am
We really do have it easy these days! I can see why you implemented that now.headsex wrote:Implementing the Calibration only write (particularly for the BA's which 443kb mpc555 flash was slow!!) saved my sanity. Think back when SCT released their XCAL1. It was serial interface to the PC, 115200 baud.. So, you make a change to your file, upload the 1.4mb file to the XCAL1 (took about 5 minutes), and then flash the PCM (another 5 minutes).. thats like 10 minutes (or more) of wasted time, because usually you'd walk away from the PC at the first step!
So, yeah.. Sanity saved! Unfortunately for Workshops, they still have a ~4minute wait for the flash, as transferring the file to the xcal now is via USB, and relatively fast these days.
I current read from 0x0 all the way to the end, so I do include the 0x10000 in the file. I however have my own file format that has all of the parameters, data, etc in a C# structure which I can also save to disk which does not have to include the raw binary (though I do include it as well), I can easily convert this back to binary for writing/saving.In terms of the file, yeah, full size is ok, but do you include the 0x0 -> 0x10000 in that file? of not, you already have a need for a -0x10000 offset. My view on the subject is bigger, Ie, not to limit your editing software to just this purpose, but makes it available for all micro controller types.. Also, ZF transmission, from memory, the Calibration data (the only data you need to write) will give you large files with null at the start, when the entire cal section is only about 100k in size.. Its just my suggestion, You will thank me later.. Once you have it in a non raw format, you could always write a exporter which exports it to HEX, to be able to open in IDA, so best of both worlds there.
So the process is read entire bin -> convert to my file format then use this within my program. I then save the calibration back over the raw binary, kind of like an overlay that only overwrites changes bytes and write this back to the PCM. I can leave the raw binary out, however I would need to do a full read before being able to write my file format back to the PCM.
There are a few bonuses of this approach, the raw file format doesn't matter like you suggested, it can be PHF, bin, read from PCM etc. It also makes copying tables between different calibrations possible (like HPT can do). I can also distribute these files without having to distribute the address information, this makes it possible for unlicensed users to view other peoples files without there being any opportunity to reverse engineer the addresses (as they are not included in the file).
It appears they still use PHF for all the PPC stuff, at least all the strategies up to 2015 are available as PHF files. They do seem to use VBF on other cars though, eg the focus.I'm also surprised you mentioned PHF, as I believe ford moved away from that format to VBF, which, out of all things is a Volvo format (volvo binary file?).. Its a very cool format, I'll have to try and find references online that i found years ago for you to look at.
Yep this took a while to figure out. I did the same thing as HPT on one of the guys spare BA pcms that was testing my early flash software, erased fine but the timeouts needed to be massive upon restart to finish the flash so it temporarily bricked the pcm. The code on github is a very early version, I haven't published anything later than that. Mainly put it up so people can use it as a base to write their own software if they desire, however it seems not many people are coders.I haven't had a chance to look at your code on github, however, i read in this thread you've changed timeout values a number of time.. I spent alot of time optimising my code that interfaced with the j2543 dll / PCM to improve speed significantly.. Of what you've noticed, yeah, the BA can take OVER 1 minute to erase in some instances, HPTuners was bricking PCM's at one point cause they didnt cater for this excessive period, assumed 40 seconds was enough.. (bricking in the sence of blanking out the pcm, and not writing to it).
In terms of the transfer loops to send and receive data on the bus, with the j2534 read command, i would only requested 1 message, with a large timeout (ie, 5 seconds). If no data is read from the pcm, the app would loop the request. this reduced the talk between the app and passthru device, and the moment it had data, the app had it. When writing, I always made the timeout 0. Took me a while to determine this was fastest way of doing it, as it wouldnt hammer the passthru dll/device with huge amount of requests.
I think I do it similar to you, basically I send a write command then loop with a ~5 second timeout attempting to read the next packet, so basically everything sits idle until the J2534 gets the next response. I have an overall timeout as well so it doesn't infinite loop.
HPTuners only lock their .hpt file format from what I can tell (I'm not 100%), they don't bother doing anything more than that. SCT garble the OSID however HPT can now read those files now, its not that difficult to build a signature of the strategy to allow detection without the VID block either.headsex wrote:Oh, furthermore, given that you cant erase the bootloader code, you cant change the seed/key algorithm in order to "lock" these pcms, like you can in the GM world.
Its interesting to see how SCT have attempted to stop HPtuners Reading the tunes. They appear to be garbling the Strategy text in the VID block, this is given away by the fact that when you read the strategy (via the xcal hand held, or hptuners), its non english characters. As a result, it makes it difficult for hptuners to know what definition file to associated with the file you just read.
Hptuners however don't appear to garble the strategy in order to "lock" the tune.. It appears they have implemented some additional data in the file written to the pcm.. Presumably to lock the tune between HPtuner customers.
I'm not interesting in locking PCMs personally, though I am interested purely from an interest perspective how you could do it. I suspect you could add some init code that breaks the UDS handler routine by modifying the canbus registers or possibly just corrupting the RAM that it uses, this could then be disabled by writing to a specific ram address. Though this effort would be better spent on live tuning or improving the software. I'm of the opinion anything is achievable with enough time and money!
Out of curiosity how did you initially figure out the seed key routine. Did you get a BDM to rip the code from the flash chip directly, then look for the flash read/write commands in the UDS routine? I posted up the location earlier in the thread, but as I already knew what I was looking for it was easy. If I was doing it entirely from scratch I imagine it would have taken much much longer to find.
Or did you go down the route of reversing the IDS software instead? (much easier to reverse X86 than PPC asm IMO)
