Some Facts

[sbingner]

It won't.... I tried that like 6 months ago  I also don't think the first check is by phatd, but if it were it would be trivial to hack...  just find where it checks the sig and make it always return true

Sam

OK... checkout the following..

http://unix.phatnoise.com/

See the one that talks about "plsign" to sign the playlists?

Well, if I'm right... THAT VERY SAME STANDALONE "plsign" uility that creates signed playlist files will create the sig file needed for modifying the rc.sh file

GIVEN THE ASSUMPTION that they're not going to use multiple encryption scenario's ...  I SHOULD BE ABLE re-sign the rc.sh file using the plsign utility

I'm downloading knoppix (cd based linux) now to test my assumptions

[sbingner]

To get this info, I had to disassemble the DMS, and put it into my laptop... I then booted off a linux CD and pulled off all the info and a full image of the drive itself

Tonight ill try and get a dd dump of the first bit of my 60GB dms, ill try and provide some hdparm info as well, if this is of some use.

[A543]

Tonight ill try and get a dd dump of the first bit of my 60GB dms, ill try and provide some hdparm info as well, if this is of some use.

sulaco, I would still be interested in seeing this information, if you're still up for retrieving it.


And also a question:  Has anyone absolutely confirmed whether the sig files are MD5SUM, DES or something else? Or is this still just guesswork?

[sulaco]

Hi, yeah will try and get it done soon.

Ive been pretty busy lately so ive only had time to keep an eye on this forum.

Im also playing about with the kernel. Ill explain if it works

[para]

@A543: I'm quite sure that RSA is used, at least for the playlists signatures! Therefore I suppose they also use it for the DMS signature...

Update: I think they use "rsaref". See what Debian has to say about it:
http://packages.debian.org/stable/non-US/rsaref2

Found in rsaref.txt:

3.1 Signing data

RSAREF signs data with three procedures: R_SignInit, R_SignUpdate,
and R_SignFinal. These procedures are typically called by
message-processing applications, by key-generation applications when
constructing a PEM or PKCS certification request, and by
certification applications when signing a certificate.

An application first calls R_SignInit, giving an integer specifying
which message-digest algorithm to apply (By Para: MD2 or MD5). R_SignInit
sets up a context for the signature operation, and returns the
context.

The application then calls R_SignUpdate any number of times, giving
the context and the next data part. R_SignUpdate digests the part.

After all the parts are supplied, the application calls R_SignFinal,
giving the context and the signer's RSA private key. R_SignFinal
encrypts the message digest with the private key and returns the
result, which is the signature

[A543]

On the RSAREF page link it states:

RSAREF 2.0 is also the only (apart from RSAREF 1.0) way to legally use RSA within the United States (until the 20th Sep 2000). It license is surprisingly liberal but it places restrictions upon using the library for revenue generating purposes.

Keying the DMS was done strictly for revenue generating purposes, so I'm guessing that this isn't what they use.  Also I'm not sure what happened on the 20th of Sept. 2000, but that might also exclude them from using it.
I agree that it's probably something from RSA, but probably not by way of this library package.

[para]

Good point, but they included the respective headers in their plsign binary...

[judb]

On the RSAREF page link it states:
Keying the DMS was done strictly for revenue generating purposes, so I'm guessing that this isn't what they use.  Also I'm not sure what happened on the 20th of Sept. 2000, but that might also exclude them from using it.
I agree that it's probably something from RSA, but probably not by way of this library package.

The patents were waved and the public domain got RSA capability so if it were after Sept 6 2000 according to this press release its free...

http://www.rsasecurity.com/press_release.asp?doc_id=261&id=1034

[judb]

author=Paul
2.  When phatd runs, the first thing it does is to verify the current identify string against the signature on the magic sector. If it differs, phatd exits. Since it is in a while/forever loop, that causes the repetitive green light flashes on the PhatBox.


4.  The .pac files are firmware for the microcontroller that interacts with the head unit (that controller needs to be "instant-on" so the head unit doesn't declare the CD changer broken at startup). The rest of the PhatBox boots Linux from the DMS. If a file named forceupdate is present in PHTSYS, the firmware file(s) will be flashed to the microcontroller at next boot.

Hope that helps.  It is all (to the best of my knowledge) true.

From my toying around with the boxes I think this is slightly incorrect.  

From what I can tell the ramdisk sig is checked before the ramdisk is loaded which means the boot loader checks the sigs on the drives in the phatsys partition.  I feel its likley that whatever does this also checks the magic number on the drives during boot up.

The ramdisk /etc/init.d/rcS script calls a mount -a (which only mounts the /dos (phatsys) partition and then calls /dos/rc.sh which then mounts the /dos/Data (phatdata) partition.

The .pac files I think are the firmware for the ARM CPU and the .bif is the file for the microcontroler, i THINK .  progpld is a CPLD firmware writer.

Just my thoughts / updates for things as I get more data.

[para]

I agree with you but why should the arm cpu have a firmware? I thinks that's part of the microcontroller, too...

[judb]

The fact that there are pins to jumpers on the board that relate to the boot rom for the ARM CPU makes me think that they are loading into flash the code for the ARM cpu.  Also the speed at which the system boots makes me think they are reading a lot more from the flash than from the drive.  

Once we get JTAG working I think we'll know more.