What's been tried so far..

[MarkH]

thought it would be good to start a thread of what has already been tried - all the info on the "other" forum is great,  but i'd be scared someone from phatnoise may delete it all...

what i've done:

ata lock not used - other wise the cradle could not read the hdd, also i've pulled the disk out and connected directly to a pc - so definately not locked.

being that re-partitioning will stop it from working within the player I would guess they have hidden some funky data within the partition tables (or other non-file area of the hdd)

i believe people have tried sector copying the hdd which failed so my guess would be they probably do something along the lines of take some "fixed" data from the disk (serial number / firmware number etc etc), then do some funky calculation on it, then save this little bit of data somewhere in the partition table (or similar) - then presumably the player probably does the same bit of maths in the systems BIOS, compares it to the hdd data and decideds if it likes the DMS (or not) at this point.

This is only a guess, but it is what i'd do if i wanted to prevent people from upgrading HDD's...

[sulaco]

I take it when the phatbox boots rc.sh is run calling phatd, so phatd is *possibly* doing these checks.

Im wondering if its possible to decompile phatd and try to somehow remove these routines? (im currently looking into it)

[A543]

The beginning of the first partition is moved forward on the disk a small amount from where it would normally be created. It's perfectly valid to do this, it's just not normally done, why waste the space.  But, that small extra space is where, what seems to be the key, is stored.  On my 10gig DMS, the key seems to start around absolute sector 1792, and the start of the first partition is at absolute sector 2048.  This is why if you repartition the DMS you'll most likely destroy the key, as the partitioning software will move the beginning of the first partition to the more normal beginnning of the disk, overwriting the key.
  As I mentioned on the "other" board, my next experiment is to manually resize the PHTSYS partition to something like 35MB (from 260). Then add the extra space to the PHTDTA partition for more music.  If this works, then we can almost certainly eliminate any partition information being stored in the key.
sulaco, we need coders like you here!  Excellent to have you aboard.  I'm more of a hardware guy. But with coders and hardware people coming at this from different directions, I'm sure we can solve it.
I'm wondering if you know what boot.pac and boot5.pac are?  Are these files the actually boot firmware stored in the Phatbox?

[judb]

has anyone tried to dump the data off the drive thats before the partition start?  

I doubt seriously that whatever data they store there will be terribly difficult to decode.  

I don't buy the idea that we cant upgrade drive sizes because of this blessed drive thing so that they can have OEM support for the phatbox.  whatever they write in that area of the drive is used to lock us into that media so we have to continue to buy drives at 100 percent markup on the drive from phatnoise.  its all about the revenue.  

[A543]

Here are my thoughts at this point.
Here is a list of what might be in the key:
1. Drive serial number            -  most likely
2. Drive ID string                    -  possibly
3. Firmware revision               -  possble but not likely
4. Partition table info              -  possible but not likely
5. Hardware revision or
    other unkown item             - very unlikely

If my partition table experiment works, I will feel safe dropping 4 and 5 from that list above and will concentrate on the remaining items.  It's a process of elimination.  What I will need at that point will be as many key/serial number pairs as I can find. I will also need these to come from drives with the same firmware revision. If the drive all have the same firmware, model and ID string then the only difference between the drives will be the serial number.  Since the serial number is static and I suspect the key is static, then the algorithm for generating keys from serial numbers can be deduced.  I'll need key/serial number pairs for that.
I'd like to hear from members who would be willing to post or send that data when I get to that point.
Maybe next week sometime.   If, on a long shot, there is someone here with codebreaking experience, I'd sure like to hear from you as well.

[A543]

hey judb, if you've been following market prices, you'd see the markup is closer to 400%!!

[A543]

The story has changed over the years, first the drives were keyed because of DRM.  When that was exposed as ridiculous, it was then said that the drives where keyed for quality control issues. That I would actually accept as a good move on Phatnoise' part, if it weren't for the huge markups on the drives.  Now it's because of OEM reasons?  Hmm, we should have a contest to see who can guess the next excuse they will use for having the key!

And yes I have extracted the key to a file.

[MarkH]

it would be sensible for someone to do a quick how-to with links to freeware required so that all the users can send in their key data and serial numbers so people can start looking at the numbers (unfortunately I have no working DMS at the moment, but have access to lots of Hard Drives to test with!)

[Firefox]

Happy to supply info of 10GB or 40GB drive if someone provides the step-by-step.

Also, you are all aware that TerryKennedy has already cracked this aren't you? It's just that he's not telling...
...but if you search his posts in the PN forums you'll see he has left a few clues lying around.

e.g.
http://www.phatnoise.com/forum/showthread.php?s=&threadid=1795

http://www.phatnoise.com/forum/showthread.php?s=&threadid=1375

I think there might be some PrivateKey/PublicKey signing that will ultimately get in the way of being able to pick up an OEM drive and drop it in. e.g. encrypted string in the hidden sector, decrypted with PN public key by the PB firmware. If so i'm not sure you can succeed without the PN signing utility/private key.

But at least if we understand how it all works we can decide if this is ultimately a dead end or not.

[sulaco]

On the partition subject, doesnt the recovery disk repartition the dms, so maybe it can shed some light on it (unless it doesnt touch this area of the disk at all)

http://unix.phatnoise.com/

[judb]

On the partition subject, doesnt the recovery disk repartition the dms, so maybe it can shed some light on it (unless it doesnt touch this area of the disk at all)

http://unix.phatnoise.com/

Yes it does.  I recall looking at their scripts and not seeing any weird offsets used but they could in theory be using the linux kernel to modify the drive offset to skip the first few sectors or something.. just like the phatbox looks there for special data.  We dont have the source for that CD so its hard to say.

[A543]

I believe the partitioning program has command line options that set where to place the start of the first partition or something like that and they have it set for the beginning of the second track.  I'm just going from memory here, but I'll look at it again when I get a chance.  Also, their script has code for both a 260 meg PHTSYS partition, which is remarked out, and a smaller 60 meg (I think) partition, which is the one that is used, if I remember correctly.

[sbingner]

PEOPLE READ THIS PLEASE

I posted this before, but nobody seems to want to read it.  I HAVE A BIT-FOR-BIT COPY OF A 10GB DMS!  There is special data in the second sector (at the very end), and the actual partition starts on the third sector.  It appears to have some info about the drive in there signed with some sort of RSA-type key.  I'd be happy to post that sector and the partition tables etc... in fact, you can download it from:

First 1mb of drive: http://www.bingner.com/phatnoise/dms-1mb.bin.gz
Partition table: http://www.bingner.com/phatnoise/DMS-fdisk.txt
hdparm inf: http://www.bingner.com/phatnoise/hdparm.txt

READ THIS! :)

[A543]

I've looked at your files.  Your hdparm data is the same as mine, except for the serial number of course.
Your partition table is also the same as mine, well before I changed mine.  The first sector (sector 0) is just the partition table.   The first partition starts on the second track, not the second sector, based on your fdisk dump.  Same as mine.
If you are looking for the key, start looking at absolute sector 1792 and the data goes right up to sector 2047 - the last sector before the first partition.  It's roughly 130k in size so I suspect the key is more than just an encrypted driveID string and serial number.  It's also very possible that only a small part of the garbage is actually used, the rest is, well, just garbage.
Thanks for posting the info, every bit helps.

[sbingner]

Oops, right... I forgot to look at my data before I posted was just going off memory... I went ahead and posted the first 2MB of the drive at: http://www.bingner.com/phatnoise/dms-2mb.bin

Sam

[judb]

Did you just use a hexdump of /dev/sda (the USB cradle connection) or of /dev/hdb (have it slaved in your box) or did you do a dd of the drive and then hex dump it?

My 10 gig drive is quite diffrent than the data you posted.

[sbingner]

The data I put up was from it connected directly to an IDE port on my laptop (hda) -- I still have the entire raw dump of the DMS

Sam

[judb]

okay that was half of the question

hexdump or dd to preform the extraction?

[sbingner]

heh dd for extraction, I emailed you too...

[judb]

heh dd for extraction, I emailed you too...

Hmm... I didn't get any email... I just checked my spam filters too and non of them caught it.

try sending it directly to jud D0T barron AT gmail D0T com  

Thanks!