PHF to BIN Converter

[DWS]

I had a weird interest in the PHF file format, so I got some of the primary features worked out. My website tool linked below allows you to view the header, segment address ranges, and footer data in a easy to view way and you can also convert the file to a raw bin file. This is very experimental, but it has worked with Spanish Oak, Black Oak, Green Oak, Some Transmission computers, odd sized ones like 448kb, D186, PCM150, etc.

FYI, the checksum for each block in the file is checked and validated, however the header/footer items are not checked.


LINK ---> https://eec.derbyws.com/phf2bin.php

Get PHF files from Ford ---> https://www.motorcraftservice.com/

If you have any issues with the page, let me know and shoot me the file (post here or in a PM).


Notes about padding:
Several files in PHF format needs extra padding to meet the correct raw bin file size. Reading the raw data directly from the computer sometimes populates dates in these sections and won't match. Of my understanding all of these sections should be ignored when wrote to the computer so the site fills those sections with hex FF. An example of this would be * Oak computers, it seems most/all PHF files skip addresses 8000-FFFF.

Currently only segments that end with 7fe0 has padding added automatically. Anything else would require manual padding (for now). If you have any of the raw bins for a file that has a different ending address that needs padding, let me know so I can test and validate. I suspect all should end at ffff, but I'm not positive on that.

Feedback is always good to have.



** Orig post below this line **

I'm poking around with the PHF file format to try to better understand it and not just rip out the raw BIN file. This seems to be the common format from Ford for Black Oak computers and likely Green Oak and the other *oak types.

I have a lot of validating to do across more files, but so far I have a reasonable understanding of the format. There are checksums throughout the file which makes bin to phf harder to do. I have something worked out that seems to work in most of file but it needs more testing yet and the very end check sums in the footer I haven't checked into yet.

Anyway, is there interest in the ability to modify a bin file and convert it back into a phf file? I assume the main use case would be to use Ford IDS with the file, but I would like to get some feedback before investing too much time into this project. I understand the format well enough to extract the bins out (in theory any size with out hard coded checks for computer type and if the checksum math works correctly, it can also validate the file is good too).

[f4ordy]

I'd be interested in seeing how you go & progress with bin to phf. I'm sure there'd be people who are wanting to disable PATS that would be interested in being able to do it with a phf file.
You've probably already found Rolls PHF2BIN converter for Black Oak & Spanish Oak PCM's https://github.com/rollsch/PHF2BIN

[DWS]

Yea I saw the open source tool. I did a quick look at it and it looks like it just ignores the "headers" for each chunk of data. It also looks like it might process some files wrong but I haven't ran it or anything. It checks for an index every 0x10000 bytes but the files I'm looking at cuts off early at 0x8000 where there's a "8 byte" header.

Those blocks I have enough sense made of them that I could make a program process the actual header to know the lengths, how far to go for the next data block, etc all automatically regardless of file type, at least based on the few I'm poking at, it would need to be tested across a lot more files and computer types to make sure it works as expected.

The checksum method I have currently worked out works for all data as long as there isn't ascii data, the strategy, copyright, etc is where the checksum breaks, but the rest of the file it seems rock solid. That's part of the 6 byte "header" btw.

I've done a fair bit with network packets and client/server socket communication and this file format reminds me a lot of those systems.

The actual header I'm not sure how critical that is to be "right" for IDS to accept it. Either valid looking values would need to be generated, or user entered values, or user provided base file to extract the data from or a combination of the 3. The footer with the checksums I haven't poked at, but I suspect those are required to be correct too. The main part I've been focused on is the actual "blocks" or "packets" that holds the raw bin info that has some extra data related to it.

Either case, it's been a really interesting project, and I never really used AI much, but I've been poking at Grok a bit and it's not perfect but I can shoot over a block of data and have it do the calculation for me to save some time.

I'll have to collect some PHF calibrations off Ford's website to expand the pool of what I'm working with to better identify patterns for the sections that aren't making sense.


This is very early stages, but a bin extractor that works for any computer type should work somewhat like this (put in a simple way at least)

Read till 00 (null) is found, repeat 23 times
Next 2 bytes should be 24 00 (I think it relates to the number of header items so might need slight adjustments here)

3A seems to be a sort of "read" command, next byte is the length in hex

3A02 seems to be a sort of definition for a current segment
0000 seems to always follow will get into that more later
0400 I suspect 04 is a command for "segment" and the next byte is the segment number 00 in this case, the next segment would be 01
00 null to end the header
FA 1 byte checksum

3A20 is the header for the actual 32 bytes of data so I'll break down my understanding of a block

3A Read
20 32 bytes
0000 address 0000 for this block, the next block would increase by 0x20 which makes sense since it's 32 bytes later (0x20 = 32 dec)
00 null to end the header
Next 32 bytes are the raw bin data, extract and append to output file
last byte is the 1 byte checksum again

The 3A20 headers repeat till a segment change and the address resets again.

For the ending
3A00 seems to be a sort of EOF marker for the bin
0000 probably address to keep with the 3A command structure
00 null to end the block
01 filler data? maybe 0 length isn't possible so 1 byte is the min?
FF checksum (seems to match the design)

The footer is after this, same pattern as the header, text values start with 2020 aka 2 spaces and ends with null. If the program is to process this for meta data or anything, loop till the next byte after the null is not 20 20.

Last 2 bytes of the file seems to be 4000, maybe a sort of end of transmission/whole file type of signal.

All of this is fairly easy to spot. I'm the weird one that would make a program actually process through the file that way vs blindly pulling segments out of the file hoping the pattern doesn't change for any edge cases. I'd think the format wouldn't change from those standards, but maybe another command might exist in other files, or I haven't seen some commands buried in the file since I haven't processed one myself yet. I'll probably make one based in PHP as a stand alone tool for PHF to bin to validate several files against, and I can write in a log file the conflicting checksum blocks to hopefully work out what's wrong with the math. Once it's solid, it wouldn't be a large load on the server to offer it as a free tool, at least till I add it to the main tuner site as a new module.

Anyway, got into the techy bits quite a bit, hopefully didn't confuse people too much. FYI, the file this logic is based on is FABK8N5, can grab it from Ford directly and look at it in a hex editor to follow along.

To get the calibration in PHF format, go to Ford's website below, select your country (I'm in USA and it worked so might want to use that), then at the bottom of the page there's a list of "Site Features" and choose "Calibration Files". Enter the calibration file name FABK8N5 or whatever one you'd like (mostly the newest version is the only ones on the website, several are missing too), and Download file. If you get an ASP file, cancel the download and try again till either the page says the zip file doesn't exist, or you get a download for a zip file. Unzip and you have successfully received a calibration file for Ford IDS software.

https://www.motorcraftservice.com/

I'm not sure what the best process is for finding the latest calibration file name for all computers. I've had reasonable luck just googling the full part number and finding the next part number that's the update, repeat till it's the latest one and it's likely on Ford's site. If a full list exists somewhere or there's a location to look up any computer including much newer ones, it would be nice to have access to that data. Anything newer than around 2010 seems to be harder to find info on.

[DWS]

Sooo... while messing around with this file format, I figured I'd make my own PHF to Bin converter (web based). Everything seems to work exactly as expected, of course right now it's ignoring the checksums, but it's processing everything else linearly and actually using the headers and such to process the file.

I got a bin file from another user that used the open source PHF2BIN converter linked below and found it's 0x20000 bytes oversized. Going back up where it should have ended, I see the PHF footer text. It appears the program is somewhat broken so someone might want to let Rolls know about the issue. The exact file to recreate the issue is HAANGB6, should be able to get it directly from Ford (AU based model of my understanding).

https://github.com/rollsch/PHF2BIN

As of right now I do have effectively a hard coded in padding which mimics what the above converter does for addresses 8000-FFFF. A real dump I have using PCM Flash actually has data in that region, but the PHF header says to effectively skip the first 0x10000 bytes so I guess those probably don't matter too much. Besides the padded section, the files are a perfect match except some data around the VIN area and of course the actual VIN but that makes sense.

Next step is to add in the checksum calculation and compare the calculated one vs the provided one in the file and go from there.

[DWS]

Welp, another progress report already, The blocked BIN data checksums I have worked out now, so I can validate data integrity and also regenerate those blocks from a raw BIN file.

The header isn't too complicated, the actual BIN data effectively is solved. The last bit to really work out is how the checksums in the footer are calculated and I think I'll understand the file format well enough to be able to recreate the PHF files even for bins that never came that way.

I also learned some new things about these computers in the process, so I'll have to try applying that to my efforts in Ghidra.

[oldtinfords]

Interesting to see someone else have ago at BIN2PHF. I have only found one other forum where someone was trying to do it & that was a few years ago.

Everything is skipped before 0x10000. The area pre 0x10000 is different between BA, BF & FG, they have their own specific data. You will have worked out the VID starts at 0x100C0. There's a lot of work already done in the PCMtec Development Blog.
You are correct that there's an issue with Rolls PHF2BIN converter. It doesn't process the BA Falcon Black Oak 1472k files correctly resulting in an oversize file.

BA Falcon files

HAANGB6_Rolls_PHF2.bin

(1.5 MiB) Downloaded 99 times

HAANGB6_PCMflash_Read.bin

(1.44 MiB) Downloaded 98 times

The BF & FG Spanish Oak 1024k files I've tested in the past have worked correctly.

FG Falcon Files

HAEE3A6_Rolls_PHF2.bin

(1 MiB) Downloaded 99 times

HAEE3A6_PCMflash_Read.bin

(1 MiB) Downloaded 98 times

HAEE3A6.PHF

(1.15 MiB) Downloaded 136 times

[oldtinfords]

BF Falcon Files

HACCKX5_Rolls_PHF2.bin

(1 MiB) Downloaded 149 times

HACCKX5_PCMflash_Read.bin

(1 MiB) Downloaded 149 times

HACCKX5.PHF

(1.15 MiB) Downloaded 102 times

On a side note, I have previously edited the PATS switches on a BF & FG PHF file, flashed it with FORScan, PATS was correctly disabled & the vehicle started.

[oldtinfords]

I missed the link you had to your PHF2BIN converter but have tested it & the results for both the Black Oak 1472k & Spanish Oak 1024k files look good

https://eec.derbyws.com/phf2bin.php

[DWS]

Thanks for checking it out. I ironically found Rolls tool had mistakes after I made mine since I was comparing what it did about the padding issue since I figured it was a known working tool. I did a real quick peek at the code and saw it ignored the "6 byte header" for each 32 byte block blindly so I suspected it might have issues. I ran into a file that had 16 byte blocks and my site handled it fine. It also processes through the header/footer most likely in the same way IDS would or very close at least so any header changes from the "standard" is no problem. It doesn't even check the header contents or anything to try to identify the file type, it just processes what it's given and spits out the resulting file =).


The links are really weird on this site, when I use the url tags it makes it blend in with the normal text and makes it hard to see. Looks like putting the link with out the proper formatting makes it link as blue, so I guess it's a weird template related issue on the site. I added a var to the url for no reason other than to make the link stand out, the ?r does nothing though.

Anyway, the first files I was testing were D186 (1472kb) and the group of guys I'm talking to are mostly from AU so I got some of the newer Falcon files from them and grabbed the PHF files from Ford. Converted the PHF and bindiff'ed the resulting files and all looked good. I hit a bunch of different computer types to try to catch any edge cases but didn't have raw bins to compare against so mostly was testing based on file length to make sure the padding matched up.

I have an idea on how to fix the padding problem, I just hate to assume things and wish the header had something reliable to reference to know where padding is needed.

[DWS]

Another small update. Padding is automatically calculated now based on the last address in the segment to fill it to FFFF, view PHF info to see where padding is added and the number of bytes added.

Two issues I've identified so far.

1. I have ran into one file that the address ranges of the segments seems to have skipped addresses within, so it says say 00000000-0000FFFF but the actual file ends at 0000DFFF. I'll have to check each block within a segment to make sure the data is continuous. In the cases it's not, I assume padding the missing data is likely the desired effect from the converter's point of view.

2. The header section has changed format slightly a few times. The newest files seems to have changed again. This time there's no clear indicator that the next block is valid data so will have to rework that part of the code and put in some fail safes so an uploaded BIN file won't pass.



On a side note. I have some files that are new enough to be in the VBF format. I took a really quick peek at it appears like they aren't encrypted or zipped and there doesn't seem to be a whole lot of info in a quick google search about the format. Would something similar be of interest for these files? VBF2BIN I suspect isn't that hard to do. Any checksums might be hard to work out though to recreate a VBF from a bin similar to how PHF is complicated to recreate from a bin.

Are there computers that have VBF and PHF files? I suspect the file format switch might have happened suddenly so there's a split in models, or it was done at a certain model year for all vehicles. Would be good to get raw bin reads from physical computers to match the resulting converted bin to as well. Either case, if/when I start this project I'll make a dedicated thread for it.