Author Topic: New Firmware / New Features (Read 59694 times)

phatchicken · « **Reply #20 on:** November 30, 2007, 07:15:24 pm »

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?

judb · « **Reply #21 on:** December 02, 2007, 03:35:28 am »

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.

sbingner · « **Reply #22 on:** December 02, 2007, 05:24:18 pm »

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.

judb · « **Reply #23 on:** December 02, 2007, 09:08:51 pm »

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.

sbingner · « **Reply #24 on:** December 03, 2007, 08:43:38 am »

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...

phatchicken · « **Reply #25 on:** December 04, 2007, 09:53:17 pm »

Does that mean we can make our own unencrypted firmware and program that to the PhatBox?

sbingner · « **Reply #26 on:** December 06, 2007, 07:31:37 pm »

That is how I read it, yes...

VorTechS · « **Reply #27 on:** December 07, 2007, 01:59:52 pm »

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....?

dafamous12 · « **Reply #28 on:** January 04, 2008, 04:17:38 am »

Went to the phatnoise site and they say that phatbox has been officially discontinued. Any chance they might release the codes for it?

S80_UK · « **Reply #29 on:** January 04, 2008, 08:57:48 am »

Quote from: dafamous12 on January 04, 2008, 04:17:38 am

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.

judb · « **Reply #30 on:** January 06, 2008, 12:03:04 am »

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.

A543 · « **Reply #31 on:** January 06, 2008, 01:28:19 am »

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.

S80_UK · « **Reply #32 on:** January 06, 2008, 10:47:44 am »

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).

todd1010 · « **Reply #33 on:** January 07, 2008, 03:37:53 am »

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.

sbingner · « **Reply #34 on:** January 08, 2008, 10:08:32 am »

they still can't release copywrited or protected code... and writing a firmware from scratch is a bit of a big job

phatchicken · « **Reply #35 on:** March 11, 2008, 07:59:24 pm »

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".

Quote

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.

Quote

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!

sbingner · « **Reply #36 on:** March 13, 2008, 02:53:00 am »

very nice!

Any ideas on the actual creation of the firmware?

phatchicken · « **Reply #37 on:** March 13, 2008, 06:12:44 pm »

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.

sbingner · « **Reply #38 on:** March 13, 2008, 06:30:52 pm »

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.

phatchicken · « **Reply #39 on:** March 14, 2008, 06:43:48 pm »

We can write the code in C. 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?

News:

Author Topic: New Firmware / New Features (Read 59694 times)