Author Topic: Some Facts  (Read 23815 times)

0 Members and 1 Guest are viewing this topic.

admin

  • Guest
Some Facts
« 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.

Offline sulaco

  • A few posts under my belt.
  • *
  • Posts: 33
Re: Some Facts
« Reply #1 on: March 08, 2005, 03:55:31 pm »
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.
« Last Edit: March 08, 2005, 06:35:44 pm by sulaco »

Offline A543

  • Senior Member
  • Veteran.
  • *****
  • Posts: 214
Re: Some Facts
« Reply #2 on: March 08, 2005, 10:42:43 pm »
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.

Offline sulaco

  • A few posts under my belt.
  • *
  • Posts: 33
Re: Some Facts
« Reply #3 on: March 08, 2005, 11:48:18 pm »
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 :)
« Last Edit: March 09, 2005, 12:08:01 am by sulaco »

Offline A543

  • Senior Member
  • Veteran.
  • *****
  • Posts: 214
Re: Some Facts
« Reply #4 on: March 09, 2005, 12:47:54 am »
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.

Offline AndyMan

  • Getting the hang of things.
  • **
  • Posts: 75
Re: Some Facts
« Reply #5 on: March 09, 2005, 02:06:02 am »
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?
« Last Edit: March 09, 2005, 03:58:43 am by AndyMan »

Offline AndyMan

  • Getting the hang of things.
  • **
  • Posts: 75
Re: Some Facts
« Reply #6 on: March 09, 2005, 02:17:44 am »
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

Offline AndyMan

  • Getting the hang of things.
  • **
  • Posts: 75
Re: Some Facts
« Reply #7 on: March 09, 2005, 06:02:05 pm »
Quote
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?

Offline A543

  • Senior Member
  • Veteran.
  • *****
  • Posts: 214
Re: Some Facts
« Reply #8 on: March 09, 2005, 09:59:45 pm »
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.

Offline AndyMan

  • Getting the hang of things.
  • **
  • Posts: 75
Re: Some Facts
« Reply #9 on: March 10, 2005, 01:35:40 am »
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

Offline A543

  • Senior Member
  • Veteran.
  • *****
  • Posts: 214
Re: Some Facts
« Reply #10 on: March 10, 2005, 02:50:46 am »
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?

Offline AndyMan

  • Getting the hang of things.
  • **
  • Posts: 75
Re: Some Facts
« Reply #11 on: March 10, 2005, 03:32:39 am »
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


« Last Edit: March 10, 2005, 03:34:27 am by AndyMan »

Offline TouaRhodesian

  • Newbie
  • Posts: 3
Re: Some Facts
« Reply #12 on: March 10, 2005, 07:20:09 am »
Can phatd be modified to just not look for the key?

Offline sulaco

  • A few posts under my belt.
  • *
  • Posts: 33
Re: Some Facts
« Reply #13 on: March 10, 2005, 11:46:39 am »
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!

Offline sulaco

  • A few posts under my belt.
  • *
  • Posts: 33
Re: Some Facts
« Reply #14 on: March 10, 2005, 12:15:04 pm »
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?
« Last Edit: March 10, 2005, 12:15:26 pm by sulaco »

Offline AndyMan

  • Getting the hang of things.
  • **
  • Posts: 75
Re: Some Facts
« Reply #15 on: March 10, 2005, 12:57:37 pm »
Quote
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.

Offline sulaco

  • A few posts under my belt.
  • *
  • Posts: 33
Re: Some Facts
« Reply #16 on: March 10, 2005, 01:32:05 pm »
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.
« Last Edit: March 10, 2005, 01:44:49 pm by sulaco »

Offline AndyMan

  • Getting the hang of things.
  • **
  • Posts: 75
Re: Some Facts
« Reply #17 on: March 10, 2005, 01:40:02 pm »
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)
« Last Edit: March 10, 2005, 01:42:57 pm by AndyMan »

Offline AndyMan

  • Getting the hang of things.
  • **
  • Posts: 75
Re: Some Facts
« Reply #18 on: March 10, 2005, 01:47:06 pm »
Quote
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?

Offline sulaco

  • A few posts under my belt.
  • *
  • Posts: 33
Re: Some Facts
« Reply #19 on: March 10, 2005, 01:49:20 pm »
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...