New Firmware / New Features

[phatchicken]

I was wondering if there has been any work done to add support to currently unsupported head units, or if there has been any work done to add features to existing PhatBox firmwares.  For example, I have a PhatBox in my Volvo, and I use the Honda firmware.  It works great and I love it, but my head unit has a Pause button and the firmware does not appear to support this feature.  I would like to change the firmware.pac file to add support for this.  Apparently, my Volvo's head unit uses the "Alpine M-Bus" changer protocol.

Any ideas or suggestions?

[VorTechS]

The firmware pac files is currently encrypted in a manner that we've not yet found out.  Until this happens, there's no way we can extend the PhatBox support.

[phatchicken]

Is there any interest in doing so?  If yes, what is the progress of this effort?

[VorTechS]

Yes there is interest in doing so.  AFAIK the progress is zilch, zero, nadda, not a lot.

If you've ever seen the 'bizarro_scramble' routine in the signing code (for SIG files) you'll understand why.  PhatNoise never really adopted standard encryption, which was probably a sensible thing.

Actually the issue might not be encryption - we just don't know what the format of the file is, or the protocols etc...

But if you think you can crack it.... we'd all be very happy if/when you do

[phatchicken]

First, maybe we could compare different firmware.pac files to see if there are any similarities?

Second, we know that 8052 code is what runs on the microcontroller, so that is what the decrypted pac file should contain.

[sbingner]

I haven't been able to get a disassembler to be able to read it...

[phatchicken]

First, maybe we could compare different firmware.pac files to see if there are any similarities?

I took a look at the available firmwares and I decided to start with Audi, because it was the first one in the list.  I started with just the first portion of the Audi firmware.pac files.

Version 2.00:   39 50 02 0f fd 19 48 fb e4 93 07 c6 25 36 f2 84 88 4a 8c c5 ac 7b 25 0c 04 a3 4d 40 b5 23 a1 4b
Version 3.00:   39 50 02 0f fd 19 a0 fb e4 93 07 c6 25 36 f2 84 88 4a 8c c5 ac 7b 25 0c 04 a3 4d 40 b5 23 a1 4b
Version 4.00:   39 50 04 0f fd 19 88 6d fd a6 02 a5 98 99 fd 84 88 4a 8c c5 ac 7b 25 0c 04 a3 4d 40 b5 23 a1 4b
Version 4.01:   39 50 04 0f fd 19 88 6d fd a6 02 a5 98 99 fd 84 88 4a 8c c5 ac 7b 25 0c 04 a3 4d 40 b5 23 a1 4b
Version 5.01:   39 50 05 0f fd 1b 20 50 55 72 09 cf 33 e7 ef 84 88 4a 8c c5 ac 7b 25 0c 04 a3 4d 40 b5 23 a1 4b
Version 5.02:   39 50 05 0f fd 1b 40 0a 7c 0d 54 8d c8 76 7b 84 88 4a 8c c5 ac 7b 25 0c 04 a3 4d 40 b5 23 a1 4b
Version 6.00:   39 50 06 0f fd 1e d8 9a 36 e0 87 3e f3 67 6d 84 88 4a 8c c5 ac 7b 25 0c 04 a3 4d 40 b5 23 a1 4b
Version 7.00:   39 50 07 0f fd 21 e8 93 79 0c 10 91 cd 60 72 84 88 4a 8c c5 ac 7b 25 6f e6 4d 0b 60 20 45 a6 4b
Version 7.02:   39 50 07 0f fd 22 b0 93 79 0c 10 91 cd 60 72 84 88 4a 8c c5 ac 7b 25 6f e6 4d 0b 60 20 45 a6 4b

I noticed right off the bat that the third byte corresponds with the version number, and that there are several sequences that are the same.

[VorTechS]

Okay, I tried something really really stupid, completely random which leaves me to claim that I got it 'disassembled'. 
Or at least, I got an 8052 disassembler to generate something.

Perhaps this means something to you 'low level' guys?

Disassembled Kenwood Firmware

This is the Kenwood 13.01 firmware file.

To disassemble:

Copy firmware.pac to firmware.bin

Run this command line disassembler: 8052 Disassembler using the following command line:

d52 firmware -b

It'll then generate firmware.d52 which is just a text file.

[VorTechS]

I also tried 6 other firmware.pac files for other head units and they all disassembled without error.

To be sure the disassembler wasn't just making stuff up, I tried disassembling random files and got a bunch of errors.

[sbingner]

All the HU disassemblies are at http://downloads.phathack.com/firmware/disasm

You can find which is for a HU by looking at http://downloads.phathack.com/firmware and seeing the filename of headunit.zip -- that will correspond to the .txt

[sbingner]

I took a look at the available firmwares and I decided to start with Audi, because it was the first one in the list.  I started with just the first portion of the Audi firmware.pac files.

Version 2.00:   39 50 02 0f fd 19 48 fb e4 93 07 c6 25 36 f2 84 88 4a 8c c5 ac 7b 25 0c 04 a3 4d 40 b5 23 a1 4b
Version 3.00:   39 50 02 0f fd 19 a0 fb e4 93 07 c6 25 36 f2 84 88 4a 8c c5 ac 7b 25 0c 04 a3 4d 40 b5 23 a1 4b
Version 4.00:   39 50 04 0f fd 19 88 6d fd a6 02 a5 98 99 fd 84 88 4a 8c c5 ac 7b 25 0c 04 a3 4d 40 b5 23 a1 4b
Version 4.01:   39 50 04 0f fd 19 88 6d fd a6 02 a5 98 99 fd 84 88 4a 8c c5 ac 7b 25 0c 04 a3 4d 40 b5 23 a1 4b
Version 5.01:   39 50 05 0f fd 1b 20 50 55 72 09 cf 33 e7 ef 84 88 4a 8c c5 ac 7b 25 0c 04 a3 4d 40 b5 23 a1 4b
Version 5.02:   39 50 05 0f fd 1b 40 0a 7c 0d 54 8d c8 76 7b 84 88 4a 8c c5 ac 7b 25 0c 04 a3 4d 40 b5 23 a1 4b
Version 6.00:   39 50 06 0f fd 1e d8 9a 36 e0 87 3e f3 67 6d 84 88 4a 8c c5 ac 7b 25 0c 04 a3 4d 40 b5 23 a1 4b
Version 7.00:   39 50 07 0f fd 21 e8 93 79 0c 10 91 cd 60 72 84 88 4a 8c c5 ac 7b 25 6f e6 4d 0b 60 20 45 a6 4b
Version 7.02:   39 50 07 0f fd 22 b0 93 79 0c 10 91 cd 60 72 84 88 4a 8c c5 ac 7b 25 6f e6 4d 0b 60 20 45 a6 4b

I noticed right off the bat that the third byte corresponds with the version number, and that there are several sequences that are the same.

Yea... they correspond to this as well (beginning of a level-10 logfile):
09.39:51d  :parse_pac : PAC file summary
09.39:51d  :parse_pac :     firmware name h: 22
09.39:51d  :parse_pac :     firmware name l: 00
09.39:51d  :parse_pac :     firmware ver   : 08
09.39:51d  :parse_pac :     firmware base h: 0f
09.39:51d  :parse_pac :     firmware base l: fd
09.39:51d  :parse_pac :     firmware size h: 15
09.39:51d  :parse_pac :     firmware size l: 60

This is obtained from the first 7 bytes of the file, which SHOULD be just a header.  It is in the order listed above... so for your "4" it would be:

name h: 39
name l:50
ver: 04
base h: 0f
base l: fd
size h: 19
size l: 88

[sbingner]

phatchicken, you should catch us in IRC so we can talk this thru a little...

[phatchicken]

OK.  What times are good for going into IRC?

[phatchicken]

I found a web-based IRC interface so I don't need to install a client like mIRC.  I can be in the #phathack channel during the day -- just let me know a good time.

[VorTechS]

sbingner is away for a few days, possibly the week.

He's usually around 8am-12pm (GMT) or from the looks of recent activity 7pm (ish GMT)

[phatchicken]

Well, I am in California, so what would be a good time to meet up in IRC?  You guys are in the UK?

[judb]

Vortech is in the UK and Sam is in Hawaii

[VorTechS]

As judb says I'm UK, and as my signature says I'm on IRC between 8am and 4pm GMT.  However, I am not the person to talk to about ASM programming!

The GMT times I gave for Sam (sbingner) are based on the activity I've seen on the channel, given that I am in the UK.

[phatchicken]

All the HU disassemblies are at http://downloads.phathack.com/firmware/disasm

You can find which is for a HU by looking at http://downloads.phathack.com/firmware and seeing the filename of headunit.zip -- that will correspond to the .txt

Heh.  I really think these pac files are encrypted somehow; they cannot be plaintext.  If you take the disassembly from VorTech or http://downloads.phathack.com/firmware/disasm/, and then try to assemble those files, you will get a bunch of errors.  Plus, if you look at the disassembled code, there are many POPs without PUSHes, and vice versa -- a real good way to screw with the stack pointer.

If they are encrypted, how will we decrypt them?

[judb]

They are encrypted

the other part of this is that they are loaded into the 8052 encrypted. its one of the main features of that particular chip.

The reason we haven't made any headway is we don't have any idea how to hack the inner workings of that chip.

As I understand it, the code stored in the 64k eeprom inside the chip is stored encrypted so even using a jtag dump wouldn't gain us anything, or at least thats how I understand it from the spec docs on that chip.