PhatHack
The Hacking Hoedown => PhatBox Hacking => Topic started by: admin on March 08, 2005, 03:28:55 pm
-
Here is what I have found/figured out from various sources:
1. All of the system files are DES-signed (that's what the .sig files are). There is a Linux utility called "hdparm" (I believe) where one of the responses is the drive identify string. That gets signed and the signature is written to the magic sector on the drive.
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.
3. Unless we have someone who can break large-size DES, an attack on the signature isn't feasible.
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.
-
I agree with the signature thing, every file has a .sig file, and any modification to any file is noticed. I tried to modify rc.sh and the box went into its loop.
-
I've noticed hdparm on the DMS. Are you saying that the Phatbox can or does write the key itself?
If it's only checking the drive ID, I've heard that the larger DMS' have standard factory Toshiba strings. TK's said his homemade drive was a 60GB. Maybe a sector by sector copy would work there, although I highly doubt it. By the way, hdparm can return the serial number of a drive as well.
-
phatd is looking at "a" string being returned by hdparm.
I tried to modify rc.sh to dump the output of hdparm -I /dev/hda into a text file to see what phatd is receiving, but couldnt get it to write. Im still playing with it.
If the .sig system could be worked out, hdparm could be replaced with a simple script that outputs a "blessed" DMS's string. This coupled with a dump of the "special" partition area of the DMS, would mean victory. Still a long way to go though :)
-
I've done some reading on DES and Public/Private Key encryption. If the key is DES'd, then they would have to either un-DES it, or re-DES the magic keys source data to get something to compare with. Either way, the DES encryption key would be in the Phatbox code.
If they are using a Public/Private key, they might have been stupid and put the private key in the code to decrypt the magic drive key in order to make the comparison with whatever data they magic key is based on. If they are smart, they are only re-public keying the data from the drive and comparing the new key with the magic key from the drive for a match.
3 out of those 4 possibilities has the key somewhere in the Phatbox code. If we can get the encryption key, we can make our own magic keys. If the key isn't there to be had, the only way I can think of to get around this would be to tamper with the drive somehow.
-
It's not DES... it's an MD5SUM
Somewhere on the freakin drive (a visile/invisible file) is the key...
md5sum is used frequently in linux to "sign and protect" the files
ONCE I've found the file, I should be able to generate sig files without any issues... AT WHICH TIME, step 2 comes into operation...
Leave the exising drive and ADD ONE
HENCE the rc.sh now moves in "el-cheapo drive" rather than my existing 10GB... I should be able to mount a 60/80/100+ GB drive.
Hardware costs initially are high (but that's because I need the cables like yesterday)
REMEMBER: We're talking IDE drives... 2 drives can sit happily on a single cable, jumper settings allow the second drive to co-exist and as long as it's"formatted" the same way as the existing DMS using the format utility, all I'll be changing is HDA to HDB... bb's your uncle and we now have oodles of space! (and swappable drives)
UNLESS of course I decide just to wire a regular 3.5 drive to the car's 12Volt and use the 5 volt from the Keg to give me a 400GB drive!!!!
Wot u guys think.. can it be done?
-
HIGH costs being relative that is..
First blush is gonna cost about $50
From then on, I suspect that costs will be more like $15-20 (ish) + cost of drive
UNLESS I go the whole hog and load a 400GB reglar IDE type drie then I could be talking about $50 (ish) anways
-
I agree with the signature thing, every file has a .sig file, and any modification to any file is noticed..
You don't think they would have more than 1 type of signature file do ya?
-
AndyMan, could the key you're looking for be stored in the magic key? I don't see why it couldn't be. On my 10GB, the key seems to start at absolute sector 1792 on the drive. It's before the start of the first partition so it's outside of any partition.
-
could be BUT I'm almost certain that they won't be duplicating sig files...
there was a thread that said something about playlists needing a sig file, that's whee I got the idea that thy're not using multiple "sig" definitions.
On Sixpak, there's a stanalone "SIG" generator for the playlists... do you get my drift yet?
Well, I'm waiting for the hardware to arrive so I can chek it out
-
Hmm, I'm not quite following you. If I understand you correctly, you are trying to determine the encryption key they use to create the sig files. I'm guessing that you suspect the key is hiding on the DMS somewhere.
What I'm saying is that we know there is a hidden "magic sector" where the drive serial number or ID is encrypted and used to check against the actual serial number or ID, which is why copying to another drive won't work. I guess what I'm wondering is if your key might be stored in the magic sector key, as the magic sector key doesn't have a sig file that we know about.
Does this make sense with what you are saying or am I obviously confused?
-
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
-
Can phatd be modified to just not look for the key?
-
Andyman - Ive got Redhat linux running on vmware so ill have a go tonight at signing a modified rc.sh to see if it works. Ill let you know what I find.
I now get what you mean about the playlists being signed (they have .sig files too). I missed that before. Im not sure if they use another key, hope not!
-
Just did a "strings plsign" and found a reference to pkeys2.e. I dont have the DMS on hand but I think I remember seeing this file on there. Is this where your keys might be found?
-
Can phatd be modified to just not look for the key?
If I'm right, then we should be able to add an additional ide drive with a modified rc.sh basically add unlimited storage.
sulaco Let me know as soon as you find something out... It is quite possible that the keys are in that file... Now what needs to happen is that you verify the rc.sig file (making sure it's the same as the one on the dms. If it is, then modify the rc.sh to bring in hdb rather than hda and then re-sign the rc.sh
We might actually be getting somewhere on this one. I'm still waiting for the hardware to arrive that will allow me to add an extra hard drive to the existing dms, I'll let everyone know as soon as it arrives.
-
Yes, by modding rc.sh to mount an hdb partition, it would mean you could add an hdd and use the original to do the boot and verification work e.t.c.
If the new rc.sig works im gonna try and replace hdparm so it always produces the same drive details no matter what drive its on. If this works then people will be-able to replace failed drives with oem drives using something like dd to copy them.
-
I see where you're going... I'm of the opinion that doing as few mods as possible is definitely the way to go... hdparm MAY BE the longer way around but is most certainly the better one.
A hack like mine will be good ASSUMING the linux allows multiple ide drives... that is still to be tested.
ALSO, my hack will still allow you to utilize the existing storage from the original DMS as well as the additional drive(s)
-
If the new rc.sig works im gonna try and replace hdparm so it always produces the same drive details no matter what drive its on. If this works then people will be-able to replace failed drives with oem drives using something like dd to copy them.
Do you have an ARM compiler/decompiler?
-
Not looking too good so far im afriad, I got hdparm and its sig from the firmware zip file and ran plsign on it. The newly created .sig is a different size (one byte bigger) than the original .sig
So this means your probably right about 2 keys. I have noticed on the DMS there are the following files:
pkeys2.e
pkeysa.e
so maybe these are the two keys?
Anyway ill try my newly created .sig on the dms tonight and see if it boots ok...
-
Do you have an ARM compiler/decompiler?
Not at the moment but im working on obtaining one :)
-
Just wanted to remind people that there are 2 processors in a Keg/Phatbox. Firmware on first one cannot be modified via a DMS-carried firmware update.
Quote from PN when my Keg died last year...
"Standard PhatBox Operation:
When it first gets power, it boots of off protected non-HU specific firmware (that never gets reprogrammed) and then turns off if there is no firmware update on the DMS (this prevents it from becoming a doorstop if it gets programmed with bad firmware).
After it turns off, it is running HU specific firmware and should be talking to the HU. When it gets ignition, it will boot the Linux processor."
Not sure whether the protected firmware does the "is this DMS blessed?"check before trying to do a firmware update, or if its the Linux processor that handles this.
Hope this helps....
-
if you could get hold of a real copy of their flavor of linux, that would also be a huge step forward 8)
-
Not sure whether the protected firmware does the "is this DMS blessed?"check before trying to do a firmware update, or if its the Linux processor that handles this.
Ah but, if I remember correctly, the new 80gb+ drives aren't signed the same as the older drives, therefore it's almost a certainty that the linux scenario verifies the dms
-
So this means your probably right about 2 keys. I have noticed on the DMS there are the following files:
pkeys2.e
pkeysa.e
Just a quick thought, if there are two different keys, one for playlists and one for system files, what if someone copied the playlist key file above to the system key file name (replacing the original) and then used the playlist sig generator to generator new sig files (using the playlist key) for all the system files. Sounds too easy, but it might be worth a try.
Ah but, if I remember correctly, the new 80gb+ drives aren't signed the same as the older drives, therefore it's almost a certainty that the linux scenario verifies the dms
Do you know what's different about the 80GB DMS keys? I'm just curious.
-
As far as I can see the plsign utility is standalone, so it probably has the key info built in.
-
As far as I can see the plsign utility is standalone, so it probably has the key info built in.
;D
-
When it first gets power, it boots of off protected non-HU specific firmware (that never gets reprogrammed) and then turns off if there is no firmware update on the DMS (this prevents it from becoming a doorstop if it gets programmed with bad firmware).
Wasn't there a thread recently on the official board talking about it being dangerous to flash the firmware in the Red box, and if it fails the prom has to be removed from the board and reprogrammed manually? It sounds like the Red box doesn't have this second processor. If the key checking routines are in this second processors code that would sure explain why the Red boxes don't need keyed drives.
Any thoughts?
-
Wasn't there a thread recently on the official board talking about it being dangerous to flash the firmware in the Red box, and if it fails the prom has to be removed from the board and reprogrammed manually? It sounds like the Red box doesn't have this second processor. If the key checking routines are in this second processors code that would sure explain why the Red boxes don't need keyed drives.
Any thoughts?
I originally took this to mean that the newer "non-Red" phatboxes were designed to be safe from a bad firmware flash (i.e a dumb user unplugging the DMS while flash was happening), because the initial boot always used the protected firmware.
So I thought it was put there to ensure the Phatbox was ALWAYS in a position to check if the modifiable firmware was to be upgraded on this reboot or not. A good way of eliminating the inevitable return of PBs for re-flashing after a bad flash...
But you have raised a good point, it might also imply that the "blessed-drive" checking is in there too.
And hence does not apply to Red Phatboxes.
So, the BIG question: can you upgrade the user firmware using a non-blessed drive? (i.e. the forceupdate file exists in root of PHTSYS on a non-blessed drive)
If you can, then we know that the first boot check is for a firmware upgrade and only later (probably in the linux code somewhere) is the blessed-drive checking.
If you can't, then it must be the protected firmware that is doing blessed-drive checking as it's first task.
Anyone care to try? Might help narrow things down... :)
-
I would be interested in seeing if we can get the sectors dumped off a couple drives up to where the partition starts for phatsys to do a comparison to see what is the same data wise and what is diffrent. having diffrent size drives and same size drive dumps would help too.
I am interested to see how much data is really significant / changes from drive to drive.
-
Hm, let me see...
Although I don't own one (I think soon I will) myself right now I'll try to contribute something being a coder ;)
I've read that ALL files are signed (not encrypted!?) by either RSA or DES (standard or triple?), right? If that's the case there won't be any reason to search for the key as it would be likely the public key. As these are mathematical "trapdoor problems" one can't decrypt the ciphered information (or sign unsigned files) without the private key with reasonable efforts - and appearantly plsign might contain a private key but that one's not used for system files. Additionally if all files are signed there won't be a way of patching the check routines in files like phatd or even replace them by a symlink attack...
IMHO the most sound approach would be to change (if possible) the hdd information being verified. Is it possible to alter any information (CHS, hence physical layout) in a hdd's firmware-respond without killing it? I think not as this info is used by the bootcode (i.e. BIOS) to address the drive correctly. I f that same info is used to generate an encrypted tag of that drive it going to be nearly impossible to interfere.
Ok, just a bunch of thoughts from my side... Please correct me if I'm wrong :-/ I'm definitely going to dive into this in more detail as soon as I got my own unit!
Bye, Para
-
I would be interested in seeing if we can get the sectors dumped off a couple drives up to where the partition starts for phatsys to do a comparison to see what is the same data wise and what is diffrent. having diffrent size drives and same size drive dumps would help too.
I am interested to see how much data is really significant / changes from drive to drive.
I've got a good working 10gb dms AND an identical DRIVE but not a true DMS..
If you have a fast download, I can put on my server for download...
What format do you want the image made using?
-
Not looking too good so far im afriad, I got hdparm and its sig from the firmware zip file and ran plsign on it. The newly created .sig is a different size (one byte bigger) than the original .sig
You didn't run a diff on these 2 files did you?
-
You didn't run a diff on these 2 files did you?
"Binary files rc.sig and rc.sig.old differ"
-
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.
-
I've just bought another PB (this one is for a friend). Is there any point in doing a drivecopy with Ghost/Acronis/dd/whatever when it's still in 'virgin' condition?
Will this tell us anything?
Rgds Balle
-
Is there any point in doing a drivecopy with Ghost/Acronis/dd/whatever when it's still in 'virgin' condition?
The only think I can think of is seeing if there is a key on it before it gets inserted into the Keg or cradle. I'll bet there is but it never hurts to check.
-
It was sent from US to Norway today, so it probably takes a week or so anyway. But it's not like it would cost me anything to do this, and compare the drive before first use and after.
But I agree with you that it probably won't get us anywhere..
Rgds Balle
-
As asked above, can anyone please tell me if ALL files on the PB are actually signed?
Para
-
All (as far as I can remember without having a keg in front of me) files on PHTSYS partition are signed
-
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
-
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.
-
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?
-
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 :)
-
@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: (http://www.cise.ufl.edu/help/software/doc/rsaref2/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
-
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.
-
Good point, but they included the respective headers in their plsign binary...
-
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
-
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.
-
I agree with you but why should the arm cpu have a firmware? I thinks that's part of the microcontroller, too...
-
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.