PhatHack
The Hacking Hoedown => PhatBox Hacking => Topic started by: phatchicken on November 20, 2007, 08:09:55 pm
-
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?
-
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.
-
Is there any interest in doing so? If yes, what is the progress of this effort?
-
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 :)
-
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 (http://wiki.phathack.com/Hardware_FAQ#Microcontroller), so that is what the decrypted pac file should contain.
-
I haven't been able to get a disassembler to be able to read it...
-
First, maybe we could compare different firmware.pac files to see if there are any similarities?
I took a look at the available firmwares (http://downloads.phathack.com/firmware/) 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.
-
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 (http://downloads.phathack.com/vortechs/firmware.txt)
This is the Kenwood 13.01 firmware file.
To disassemble:
Copy firmware.pac to firmware.bin
Run this command line disassembler: 8052 Disassembler (http://downloads.phathack.com/vortechs/d52.exe) using the following command line:
d52 firmware -b
It'll then generate firmware.d52 which is just a text file.
-
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.
-
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
-
I took a look at the available firmwares (http://downloads.phathack.com/firmware/) 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
-
phatchicken, you should catch us in IRC so we can talk this thru a little...
-
OK. What times are good for going into IRC?
-
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.
-
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)
-
Well, I am in California, so what would be a good time to meet up in IRC? You guys are in the UK?
-
Vortech is in the UK and Sam is in Hawaii
-
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. ;)
-
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/ (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?
-
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.
-
I read Winbond's data sheet, and the encryption that is used on-chip is described as follows:
6.3 Encryption
This bit is used to enable/disable the encryption logic for code protection. Once encryption feature is enabled, the data presented on port 0 will be encoded via encryption logic. Only whole chip erase will reset this bit.
I haven't checked what Port 0 is connected to on the PhatBox mainboard, but if the encryption is enabled, then it would seem that any bytes written to Port 0 would be scrambled. If Port 0 is connected as general purpose I/O, scrambling the output would yield unpredictable and unwanted results.
As for the contents of the EEPROM, it cannot be encrypted. For the 8051 micro, there isn't an intermediate decryption step between reading the ROM contents and running the instructions. It would need an entire plaintext copy of the code, otherwise how would it handle the instruction pointer?
-
i believe that the chip also has a 4 k rom where you load the code for it to boot from.. its been a couple years since I looked at the winbond chip, so it is possible I have forgotten or confused some details but I am pretty sure that the whole setup is encrypted end to end...
we haven't tried loading strace on the phatbox and running it against the firmware update utility which is likely the only way to tell if what goes to the winbond chip gets decrypted or not.
if someone wants to get that working, it might be informative.
-
The data sent over the serial port to the chip to update the firmware is identical to that contained in firmware.pac -- it shows you exactly what is written when you do a firmware update with level 10 logging is enabled.
-
thats what I thought. its encrypted when it hits the input pins on the chip. as I understand it the other features of the chip would prevent us from reading the unencrypted code off the chip through any other means.
-
RE: Encryption on 8051 data -- a birdie tells me this:
You should not be able to decrypt it or read it back. You should be able to code your own 51 assembly or compiled C and get it programmed via In-System-Programming.
The problem is getting somebody knowledgable in said 8051 programming...
-
Does that mean we can make our own unencrypted firmware and program that to the PhatBox?
-
That is how I read it, yes...
-
Came across this link full of CDC protocols for different head-units.
http://www.mictronics.de/?page=cdc_proto
It's got for various manufacturers (some in the form of links):
Blaupunkt DMS
Kenwood
Pioneer
Panasonic
Alpine
M-Bus
Volkswagen
VW
Clarion
Ford
ACP
Renault
Toyota
Chrysler/Jeep/Dodge
No idea if this will come in useful, but perhaps we can tie things up somehow....?
-
Went to the phatnoise site and they say that phatbox has been officially discontinued. Any chance they might release the codes for it?
-
Went to the phatnoise site and they say that phatbox has been officially discontinued. Any chance they might release the codes for it?
Almost no chance I would say. Even though the product is discontinued, the company still owns the intellectual property in the hardware and software, and there are likely to be parts of the software which are subject to license agreements from third parties. I believe that some parts of the software were made available previously (under open source agreements), but I suspect they would see no benefit to themselves in doing anything to make more of the code available, no matter how much we may wish it.
-
since no one else makes the phatbox (kenwood and GM) anymore I don't see why they wouldn't opensource phatd and the other phatnoise tools, i don't believe that they have any third party licensed code in there except for codecs and the OS itself. the kernel is the only thing they've released so far that I know of since they are required to by the GPL.
I'd like to see the boot loader opened up, or at least a way to pull out the one with the RSA code in the flash so we can make the platform more open.
-
Wishful thinking is nice, but remember what brought us all here. Phatnoise is one of the most paranoid, greedy companies I've ever come across. They won't give up a byte unless they have to by law.
Of course, I wish nothing more than to be completely wrong, but I'm not holding my breath on that.
-
I agree. I'm pretty sure that they won't do anything. They won't see a return on doing it and it will cost them money to do it (to wrap stuff up with license documents and have lawyers look at it and make sure they are protected from any claims from anybody). Since they are now part of the Harman group, I think it even less likely that they will do this than if they were still independent. It's just the way big companies tend to work (been there, done that, etc).
-
Has anyone tried contacting one of the programmers at phatnoise to see if they could help? I'm sure they're getting close to ending their non-compete agreement.
-
they still can't release copywrited or protected code... and writing a firmware from scratch is a bit of a big job
-
A little birdie has talked wit me about unencrypted firmware. What I heard was somewhat bizarre, but it sounds as if it is possible to do, even though it may be difficult.
First step: Inform the PhatBox that there is new (unencrypted) firmware available. Normally, this is done by sending a "1" in the highlighted position. But this will inform the PhatBox that the firware is normal (i.e. encrypted). A "0" simply says "there is no new firmware". What needs to be sent here is a "3".
09.88:51d :send_arm_s: firmware_modification=39
09.98:phatd:check_inst: Added PWid 2, value 0
09.98:51d :rw_packet : Buffering 10 at 0
09.98:51d :rw_packet : ########################################################
09.98:51d :rw_packet : 10 (16) ------------->
09.98:51d :rw_packet : Expecting HACK
09.99:51d :rw_packet : <============ ac (172)
09.99:51d :rw_packet : 07 (7) ------------->
09.99:51d :rw_packet : Expecting BACK
10.00:51d :rw_packet : <============ bd (189)
10.00:51d :rw_packet : 39 (57) ------------->
10.00:51d :rw_packet : Expecting BACK
10.01:51d :rw_packet : <============ bd (189)
10.01:51d :rw_packet : 50 (80) ------------->
10.01:51d :rw_packet : Expecting BACK
10.02:51d :rw_packet : <============ bd (189)
10.02:51d :rw_packet : 00 (0) ------------->
10.02:51d :rw_packet : Expecting BACK
10.03:51d :rw_packet : <============ bd (189)
10.03:51d :rw_packet : 27 (39) ------------->
10.03:51d :rw_packet : Expecting BACK
10.04:51d :rw_packet : <============ bd (189)
10.04:51d :rw_packet : 07 (7) ------------->
10.04:51d :rw_packet : Expecting BACK
10.05:51d :rw_packet : <============ bd (189)
10.05:51d :rw_packet : 32 (50) ------------->
10.05:51d :rw_packet : Expecting PACK
Second step: Create an unencrypted firmware.pac file. The first seven bytes have already been deciphered. The remaining portion is simply the assembled firmware program, and this is where the unencrypted 8051 program will go. The length of the program must always divisible by 8, with unused bytes being padded with 0.
09.87:51d :parse_pac : opening /dos/firmware.pac
09.87:51d :parse_pac : PAC file summary
09.87:51d :parse_pac : firmware name h: 39
09.87:51d :parse_pac : firmware name l: 50
09.87:51d :parse_pac : firmware ver : 07
09.87:51d :parse_pac : firmware base h: 0f
09.87:51d :parse_pac : firmware base l: fd
09.87:51d :parse_pac : firmware size h: 22
09.87:51d :parse_pac : firmware size l: b0
Third step: Create a new firmware.sig, and add a 0-byte forceupdate file to the cartridge.
Voila!
-
very nice!
Any ideas on the actual creation of the firmware?
-
Well, I guess there's the rub. We would need to write it from scratch -- an 8051 program that talks to the radio and the CPU, not to mention dealing with other stuff connected to the micro.
-
The protocol shouldn't be too much of a problem opn the CPU side... the problem is I have NO idea how to program for an 8051...
It also needs to control the power of the box.
-
We can write the code in C. (http://sdcc.sourceforge.net/) That should be easier than assembly.
As far as the power, don't we just have to do some bit-flipping once we figure out how stuff is plugged into the 8051?
-
That sounds about right... but what happens when we load a bad program onto the 8051? how do we reflash it?
-
As far as the power, don't we just have to do some bit-flipping once we figure out how stuff is plugged into the 8051?
Yeah that is the key -- having the full schematic of how that chip is wired up.
After that there are many open source programs that interface with head units that could be ported over.
-
That sounds about right... but what happens when we load a bad program onto the 8051? how do we reflash it?
I get the feeling we don't need to worry about that. There are two firmware areas on that 8051, one is a 4k section and the other is 64k.
From the Winbond datasheet:
The W78E516B contains a 64K bytes of main MTP-ROM and a 4K bytes of auxiliary MTP-ROM which allows the contents of the 64KB main MTP-ROM to be updated by the loader program located auxiliary MTP-ROM;
Plus, wouldn't it behoove the makers of the box to not allow its customers to brick the box?
-
Right, it accepts it over the serial port, but the question is if it'll let us turn the box on to initiate that... perhaps it will just default to powering on the 7312 processor then?
Worst case we can probably short a couple pins to make it power on the 7312...
-
Right, it accepts it over the serial port, but the question is if it'll let us turn the box on to initiate that... perhaps it will just default to powering on the 7312 processor then?
I can program my extra PhatBox with empty firmware, and see what happens. That would be a definitive test. :)
Here is the firmware.pac file which I will try:
39 50 01 0f fd 00 08 01 23 45 67 89 ab cd ef
-
I programmed the box with the bogus firmware, and it didn't do very much. After that, I replaced the bogus firmware with the old firmware, and reprogrammed the box. When it was done reprogramming, it worked fine. So, there shouldn't be any danger in programming new firmware.
-
Perfect... time to break out my bench setup... and my office looks so neat right now!
-
Simple perl script to generate firmware.pac files.
Usage: "perl genfirmare firmware.bin > firmware.pac"
[code#!/usr/bin/perl
use strict;
my @hdr = (0x39, 0x50, 0x1, 0x0f, 0xfd, 0, 0);
die "ERROR: Provide a file as argument\n" unless (-f $ARGV[0]);
my @info = stat($ARGV[0]);
my $padding;
if ((my $size = $info[7]) > 0)
{ # If size > 0
$padding = 8-($size%8);
$hdr[5] = ($size>>8)&0xff; # set size high
$hdr[6] = $size&0xff; # set size low
die "ERROR: Your firmware is way too big\n" if (($size>>16)&0xff);
printf(STDERR "Firmare size: 0x%02x high: %02x low: %02x padding:%d\n", $size, $hdr[5], $hdr[6], $padding);
} else {
die "Foolishly refusing to create a zero-sized firmware";
}
my $hdr = pack('C7', @hdr);
open(FILE, $ARGV[0]) or die "ERROR: Unable to open $ARGV[0]\n";
{
local $/;
print $hdr, <FILE>;
if ($padding) {
for (1..$padding) {
print chr(0);
}
}
}
close(FILE);
EDIT: oops, forgot padding
-
Why did it take me so long to find this?
~ # /dos/51d help
Arguments:
update - force update
blank - blank uC
update_noenc - force unencrypted update, depricated?
Environment variables:
uC_ISP_TIMEOUT - timeout in old-style ISP programming, in uSec
uC_ROLLINS_TIMEOUT - timeout in ProtoPhat2 communications, in uSec
uC_CONTROL_OFF - Don't connect to media daemon (e.g. - using WavePC)
-
Because you couldn't see the forest for the trees? ;)
-
I decided if I kept trying to get 51d to do it for me I was going to have to break something... so I did this instead:
http://phatos.cvs.sourceforge.net/phatos/51d/
It will now (on my system) happily replace 51d to the extent that it will:
- Keep the phatbox from rebooting
- Make phatd play songs and tell the 8051 the track/disk name and the first 11 chars of the titles
I still need to add firmware update code, a routine to write multi-part text values, and some parsing of phatbox.ini. The first two tasks are actually the same one since that's how it updates the firmware too. It's pretty simple, but I'm tired...
EDIT: I already had code to init the DSP... and it seems to be working, so I put it back in.
-
FYI: There is a type in the output of "51d help"
Where it says
uC_CONTROL_OFF - Don't connect to media daemon (e.g. - using WavePC)It should really say
uC_CONTROLL_OFF - Don't connect to media daemon (e.g. - using WavePC)
This is why I couldn't get it to run with those parameters.
-
ok, so when it sends 3 in the firmware update field, it doesn't initate a firmware upload. But when it boots after a cold power off... it's booting from the 4K ROM. When you send 3 then, it uploads the file. I uploaded a valid firmware that way and it did NOT work. This makes me think that it probably actually did what we expect. The encrypt bit must apply to OUTPUT data only, and it will accept input either way?
-
OK, first step... I need to figure out how to write a program for the 8051 that just tells it to turn on the system... heh.
I THINK upload is working :) but I won't really know if it works, or just takes a bad upload until I have a program that does something I can see. I tried blinky LED sample program but of course that's not what's really hooked up to those ports on the 8051... the LED is connected to the 7312.
-
I want to allocate some time in development of 51d. As I understand this thing is not much more than pipeline between 8051 chip and phatd?
I am familiar with IDA and can try understand some things from original program.
sbingner! do you have task for me to do? :)
-
I want to allocate some time in development of 51d. As I understand this thing is not much more than pipeline between 8051 chip and phatd?
I am familiar with IDA and can try understand some things from original program.
sbingner! do you have task for me to do? :)
The source is on sourceforge (http://sf.net/projects/phatos) -- feel free to try to flesh out the 51d... I haven't been working on it recently, but having a full replacement would be useful... there are obvious work-arounds we could do to make it have more options...
What we REALLY want is to get custom firmware loadable to the 8051...
-
** updated, because I thought of new stuff while fixing typos **
Maybe I'll take a look at the 8051 as well...I'd be very surprised if there weren't some way for us to get our own code into the chip, even if we have to fully erase the thing to make it happen.
I looked over Winbond's (very terse) data sheet on that part awhile back, and if I recall correctly the type of security the thing uses, it's basically a sort that allows the contents of the chip to be read back out, but unless the person doing the reading knows what the security key is, they can't directly read the output data. Typically, the way that type of security works is, there's an 8-, 16-, or 64-byte key that's programmed into special registers on the MCU, and when the code is read out of the processor, each N-byte block is XORed with the security key.
Often times, this type of security can be worked around if the person programming the part is lazy, because if they leave unprogrammed locations unprogrammed, then reading the chip results in a bunch of garbled code, followed by a bunch of repeated blocks of the same data, which will usually be the key XORed with 0xFF (in rare cases, it'll just be the key, because some compilers produce .HEX files that stuff 0's into unused locations).
One thing that you can often do to decide if you've decrypted the data correctly on this type of processor is to look at the byte at locations 0x0000, 0x0003, and 0x0013 - Usually, they'll all be 0x02, because those locations are the reset vectors and a couple of interrupt vectors, respectively, so the instruction at those locations is often an LJMP to the appropriate handler.
Of course, all this assumes that our primary intent is to decrypt the code that's already in the MCU- in actual fact, if our goal is just to get fully custom firmware into the thing, then the existing firmware is a moot point- we just need to be able to communicate with the ARM sufficiently well to convince it that we're a bona fide product of the Phatnoise labs, and not some poseur trying to make the Phatbox do something it's creators didn't originally intend...and based on what I recall from the Wiki, we have a reasonably good idea of what that communication looks like.
Once we've made the ARM happy, there's no reason in the world that we can't add whatever esoteric functionality we want for a given head unit, provided we have an understanding of that head unit's interface.
-c