PhatHack
The Hacking Hoedown => PhatBox Hacking => Topic started by: MarkH on March 07, 2005, 01:00:57 pm
-
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...
-
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)
-
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?
-
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.
-
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.
-
hey judb, if you've been following market prices, you'd see the markup is closer to 400%!! :o >:(
-
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.
-
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!)
-
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.
-
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/
-
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.
-
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.
-
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! :)
-
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.
-
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
-
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.
-
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
-
okay that was half of the question
hexdump or dd to preform the extraction?
-
heh dd for extraction, I emailed you too...
-
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!
-
So we know that there is no boot loader code in the MBR of the DMS, correct? There is absolutely nothing there. Starting at offset 0x1be is the partition table. What I find interesting is the 4 bytes that can be found at offset 0x1b8. If more people can get their 4 bytes off of their DMS, please do and post your results. I'm not sure what other information would be relevant right now, I have no idea what those 4 bytes signify. And it might be nothing. But it's still odd. (If you need help extracting this information, let me know)
000001b0h: 00 00 00 00 00 00 00 00 ED 77 ED 70 00 00 00 00 ; ........íwíp....
000001c0h: 01 01 0B 3F 60 04 00 08 00 00 00 20 08 00 00 00 ; ...?`...... ....
000001d0h: 41 05 05 3F E0 FF 00 28 08 00 00 00 4C 02 00 00 ; A..?àÿ.(....L...
000001e0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
000001f0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA ; ..............Uª
-
Here's mine, doubt it's anything...
000001b0 00 00 00 00 00 00 00 00 0e 67 fe 3c 00 00 00 00 |.........g.<....|
000001c0 01 01 0b 3f 60 04 00 08 00 00 00 20 08 00 00 00 |...?`...... ....|
000001d0 41 05 05 3f e0 ff 00 28 08 00 00 88 23 01 00 00 |A..?...(....#...|
000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
-
Those 4 bytes are put there by Windows NT-XP as a disk signature.
-
http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/Windows/XP/all/reskit/en-us/prkd_tro_kyrr.asp
How to read that disk signature and decode it...
-
http://www.codeproject.com/system/change_drive_sn.asp
code to change the disk sig serial number... doubtful this is helpful in any way.
-
Those 4 bytes are put there by Windows NT-XP as a disk signature.
Absolutely right. Windows puts something there if it's zero. if it's nonzero, it just uses the data that's already there as a signature. That's what I get for posting before fully researching. There was data I could not explain, I got excited. It's still possible it could mean something else, i.e., maybe Windows didn't put it there, but I'll only bring it up again if I'm sure.
-
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.
As for Terry, the guy is smart, no doubt, but I am uncertian about the validity of his claims to have made his own drive. I mean saying that telling us would do no good but not telling us is somewhat duplicitous. I think that if he did figure it out he would have said how to do it by now, or someone else would have figured it out by now.
What chaps my ass is that I just dont quite know enough about how hard drives work to really solve this problem on my own That with the fact we have people talking DES encryption and Terry saying he did it on his own seem to be rather conflicting ideas.
-
http://www.codeproject.com/system/change_drive_sn.asp
code to change the disk sig serial number... doubtful this is helpful in any way.
could just change that with dd, but what he had to change is the actual hardware serial number reported by the firmware... via proprietary software. I haven't been able to find anything that can do that, but if we could it would stand to reason that we could make one drive completely identical to the signed drive then do a data dump to get a working drive.
-
We just need to know where on the drive it needs to be written.
I found a tool that allows me to write directly to the drives cache and read from it.. sending direct commands to the buffer etc.
from what I have read the firmware of the drive largely resided on the platters just outside of the bios range reported for OS access.
Also, I have verified they are not using HPA (drive level hiding of sectors) with the DMS drives.
http://mhddsoftware.com/ is the software.
-
could just change that with dd, but what he had to change is the actual hardware serial number reported by the firmware... via proprietary software. I haven't been able to find anything that can do that, but if we could it would stand to reason that we could make one drive completely identical to the signed drive then do a data dump to get a working drive.
How do you know that was what he did? I looked around and didnt see him ever say thats specifically what it took to do it.
-
http://www.hdat2.com/files/hdat2en.pdf
Super informative PDF about hard drives... :)
-
Using the software from that site... here is all the info you could want about the 10 gig toshiba drive...
*******************************************************************************
HDAT2 v4.01.11 PM (c) 2005 CBL
*******************************************************************************
Device Information's [PhatNoise DMS 10GB]
*******************************************************************************
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Translation Cylinder Head Sector Total sectors Size
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
ATA 28-bits 16383 16 63 19640880 10.06 GB
CHS/Current 16383 16 63 16514064 8.46 GB
BIOS 1022 239 10 2455200 1.26 GB
CMOS [XX] 19485 16 63 19640880 10.06 GB
LBA 8183 240 10 19639200 10.06 GB
Normal 19485 16 63 19640880 10.06 GB
Large 2435 128 63 19635840 10.05 GB
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
DPT ? ? ? 19640880 10.06 GB
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Device model [HDD] PhatNoise DMS 10GB
Orphan (not useable) sectors 0 = 0.00 KB
Translation/Addressing mode LBA/28-bits
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Hard disk drive parameter table INT41/46h at F000:94D0h
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
-> hex dump [ 13 05 F0 A0 3F 00 00 00 08 FF 3F 10 1C 4C 4A 11 ]
-> Phoenix EDD Translated Table
Number of cylinders 1299
Number of heads 240
Number of physical sectors per track 63
Write-precompensation cylinder number 0
Control byte 0008h = 0000000000001000b
-> more than 8 heads
-> ECC retries enable
-> Access retries enable
DPT Number of cylinders 16383
DPT Number of heads 16
Number of sectors per track (AT and later) 74
Cylinder number of landing zone (AT and later) 19484
Reserved/Checksum 11h
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
BIOS Data Area for Hard Disk Drive
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Hard disk drive (controller) status 0000h = 0000000000000000b
-> Controller not busy
-> Selected drive not ready
-> no error
Hard disk drive error 0000h = 0000000000000000b
Hard disk drive task complete flag 00C0h = 0000000011000000b
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
ATA/ATAPI Identify Device
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
ATA version 0005h/FFFFh
ATA supported UDMA4/ATA66
ATA active UDMA4/ATA66
Serial number X1E70304T
Firmware A4.01 E
Cache 0 KB
General Configuration 0040h
Specific Configuration C837h
-> Device does not require SET FEATURES subcommand to spin-up after power-up and IDENTIFY DEVICE response is complete
Integrity Word 58A5h
-> Signature = OK [reported=A5h, should be=A5h]
-> Checksum = OK [reported=58h, should be=58h]
Queue depth 1
Hardware Reset result 604Bh = 0110000001001011b
-> Device detected CBLID- above V[iH]
-> Device 0 Hardware Reset result 01001011b
-> device determined by : jumper was used
-> diagnostics passed
-> did not detect the assertion of PDIAG-
-> did not detect the assertion of DASP-
-> responds when Device 1 is selected
Detected an 80-conductor cable YES
Removable Media Status Notification not supported
Master Password Revision Code FFFEh
Security Status 0001h = 0000000000000001b
-> Security disabled
-> Security supported
-> Enhanced Security Erase: not supported
Time for Security erase unit 16 minutes
Time for Enhanced security erase unit not specified
Capabilities [49] 0F00h = 0000111100000000b
-> DMA supported
-> LBA supported
-> IORDY may be disabled
-> IORDY supported
Capabilities [50] 4000h = 0100000000000000b
Read/Write LONG: vendor specific bytes 46
Read/Write MULTIPLE: sectors per interrupt
-> Maximum 16
-> Current 16
-
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Command Set 1 supported 7C6Bh = 0111110001101011b
-> SMART feature set
-> Security Mode feature set
-> Power Management feature set
-> Write Cache
-> Look Ahead
-> Host Protected Area feature set
-> WRITE VERIFY command (obsolete)
-> WRITE BUFFER command
-> READ BUFFER command
-> NOP command
Command Set 2 supported 4108h = 0100000100001000b
-> Advanced Power Management (APM) feature set
-> SET MAX security extension enabled by SET MAX SET PASSWORD
Command Set 3 supported 4000h = 0100000000000000b
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Command Set 1 enabled 7C49h = 0111110001001001b
-> SMART feature set
-> Power Management feature set
-> Look Ahead
-> Host Protected Area feature set
-> WRITE VERIFY command (obsolete)
-> WRITE BUFFER command
-> READ BUFFER command
-> NOP command
Command Set 2 enabled 0008h = 0000000000001000b
-> Advanced Power Management (APM) feature set
Command Set 3 enabled 4000h = 0100000000000000b
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Advanced Power Management level value 80h
Acoustic management: recommended value 00h
Acoustic management: current value 00h
Stream Minimum Request Size [sectors] 0
Streaming Transfer Time for DMA 0
Streaming Access Latency for DMA and PIO 0
Streaming Performance Granularity [microsec] 0
Streaming Transfer Time for PIO 0
Physical/Logical sector size 0000000000000000b
Inter-seek delay for acoustic testing [microsec] 0
World Wide Name 0000000000000000h
Reserved for technical report 0000h
Logical sector size in words 0
Current set features option [vendor] 0000h = 0000000000000000b
Initial Power Mode Selection [vendor] 0000h = 0000000000000000b
Current media serial number not supported
Multiple LUN Support not supported
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Extended INT13h
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Extended INT13h support YES
Major/Internal/Extension Version 30h/00h/00h
-> EDD v2.0
Subset 0005h = 0000000000000101b
-> Fixed disk access subset: YES
-> Device locking and ejecting subset: NO
-> Enhanced Disk Drive (EDD) support subset: YES
-> 64-bit extension: NO
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Device Parameter Table (DPT)
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
DPT buffer size 65
Information flags 0000h = 0000000000000000b
-> (bits 4-6 are not valid)
Sector size 512
DPT Extension (DPTE) pointer F000:9470h
Key to presence of Device Path [BEDDh] BEDDh
Length of Device Path 36
Host bus type PCI
Interface type ATA
Interface Path for bus type PCI
-> hex dump = [ 00 1F 01 00 00 00 00 00 ]
-> Bus = 0
-> Slot = 31
-> Function = 1
-> Channel = 0
Device Path for interface type ATA
-> hex dump = [ 00 00 00 00 00 00 00 00 ]
-> ATA device = 0
Checksum for Device Path Information AFh
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Device Parameter Table Extension (DPTE)
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
I/O Port base address 0170h
Control Port address 0376h
IRQ 15 (0Fh)
Head register upper nibble 00E0h = 0000000011100000b
-> bit 4: ATA DEV bit = Master
-> bit 6: LBA enable = YES
BIOS Vendor specific 00h
Block Count for ATA READ/WRITE MULTIPLE cmds 16
DMA information 02h
-> DMA channel = 02h
-> DMA type = 00h
PIO information 04h
-> PIO type = 04h
BIOS selected HW specific option flags 0897h = 0000100010010111b
-> Fast PIO access
-> Fast DMA access
-> READ/WRITE MULTIPLE access
-> LBA translation
-> 32-bit transfer mode
-> Bit-shift translation
-> Ultra DMA access
Version 1.1 [11h]
Checksum
-> OK [reported=5Dh, should be=5Dh]
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
-
How do you know that was what he did? I looked around and didnt see him ever say thats specifically what it took to do it.
I found something on another forum somewhere that he posted, but havent been able to find it since then... HE changed the serial in firmware, not the volume ID number.
If you can read everything, why not try searching through the drive for the serial number, then changing it and seeing if it changes the sn of the drive? May fry a drive or two but hey heh :)
If you dont want to try, give me the info and I will...
-
I need to know what reserved area of the drive to try and access to read the serial number. I have two 10 gig DMS drives here so I'd be happy to nuke one of them trying to make it work. hehe.
So if we can find out what the protected region is addressed as in hex I can try and retreive data from the drive that way.
Perhaps if someone could debug a drive flash utility to see what commands it issues to the drive for reads or writes that would be a good place to start.
; Commands are:
; Rx = yy // put yy into register x
; REGS = yy1 yy2 yy3 yy4 yy5 yy6 yy7 // put everything to registers
; // hex values format: $xx, i.e. $FF
; WAITNBSY // wait-for-not-busy, i.e., wait for drive ready
; CHECKDRQ // check for DRQ, exit if no DRQ
; CHECKERR // check ERROR, exit if ERROR
; RESET // reset the drive (need WAITNBSY after)
; SECTORSTO = xx // Read sectors from drive's data register
; // to file xx (xx - filename)
; SECTORSFROM = xx // Write sectors to drive's data register
; // from file xx (xx - filename)
-
http://www.t13.org/project/d1321r3-ATA-ATAPI-5.pdf
might be useful in fingering out what we need to do..
This is pretty cool to...
http://www.t13.org/project/d1407r5-Address-Offset.pdf Dont think they are using this, but I dont know if this is the same thing as HPA or not. HPA is not in use.
-
I need to know what reserved area of the drive to try and access to read the serial number. I have two 10 gig DMS drives here so I'd be happy to nuke one of them trying to make it work. hehe.
So if we can find out what the protected region is addressed as in hex I can try and retreive data from the drive that way.
Perhaps if someone could debug a drive flash utility to see what commands it issues to the drive for reads or writes that would be a good place to start.
can't you try brute force searching? heh... how are you querying the reserved area? Just from that text-gui?
If we could get say a linux program to query a single byte, could easily make a routine to search every possible address
-
You need to know what to tell the drive to read and then retrieve the data from the buffer.
The app that I mentioned before MHDD has a scripting interface (thats a sample script I posted) ... to use Linux you'd need to code something that used the Int13 interface to call those registers. It could be done but I ain't no programmer like that my friend.
I'm meeting a buddy this weekend to try and debug a fujitsu HDD flash util to see what its putting in the command registers.
#$(*&@#$ I hope this isnt another waste of time.
-
Doubt that the flash util will be writing the area that contains the serial number. I spoke to a friend who works for WD a while back, and he said that it's all proprietary and since WD dosn't make laptop drives there wasnt really anything he could do to help me. Of course that dosn't meant we can't figure it out ;)
I could ask him if WD stores it on protected area of the hdd itself or on flash...
-
Doubt that the flash util will be writing the area that contains the serial number. I spoke to a friend who works for WD a while back, and he said that it's all proprietary and since WD dosn't make laptop drives there wasnt really anything he could do to help me. Of course that dosn't meant we can't figure it out ;)
I could ask him if WD stores it on protected area of the hdd itself or on flash...
Yeah, that would be helpful.
the command set is standard, the location isnt, the memory registers seem to varry from company to company. hmmm...
Any little bit helps though.
-
Copy of my t0/s0 from the link below
(http://phatbox.bigfloppydonkeyballs.com/t0s0.jpg)
-
I really doubt that the drive's serial number is actually stored on the platters... I think the only reasonable place would be either the flash (firmware) or even better (not for us!) some EPROM allowing to write it only once! Why should they place it anywhere where it could be changed afterwards? There's no need to...
Para
-
I know that its rewritable... I don't doubt that part.
However, the major concern I have right now is, WHEN we get the ability to change the drive serial... I say when because it will happen... are there any other hdparm items being used in the key gen. If so we may only be able to duplicate the exact drive size to non phatnoise sourced drives.
Example: Terry took a 60 gig Fujitsu drive and made a dupe to another 60 gig Fujitsu. Could we do this to a larger Fujitsu drive? Thats the big wildcard right now.
If we cannot make larger than 80 gig drives using this method I'll be really unhappy because all we have done is lock phatnoise out of sales of any existing inventory they have on hand of drives and DMS carts. That would not be my desire, although I also do not desire to pay their insane markups on drives.
I mean seriously, the drives are not special, I dont care what anyone thats not a phatnoise employee says. And until a phatnoise employee comes out and says we have X number of special drives made by toshiba to Y spec (that would be significantly diffrent than the published specs of the normally sourced drives) its all just speculation for the purpose of self justification of an outrageous markup on standard consumer goods. [/rant]
I really REALLY wish someone at phatnoise would take a suggestion and set up an app where we pay them a reasonable (<$50) fee for signing a drive we place in a USB cradle that uses some web connection to their servers for authorization or something. I'd buy several drives and have phatboxes of some sort in all my cars and my extended family vehicles.
-
I know that its rewritable... I don't doubt that part.
However, the major concern I have right now is, WHEN we get the ability to change the drive serial... I say when because it will happen... are there any other hdparm items being used in the key gen. If so we may only be able to duplicate the exact drive size to non phatnoise sourced drives.
I really REALLY wish someone at phatnoise would take a suggestion and set up an app where we pay them a reasonable (<$50) fee for signing a drive we place in a USB cradle that uses some web connection to their servers for authorization or something. I'd buy several drives and have phatboxes of some sort in all my cars and my extended family vehicles.
I agree that it's possible to reflash serial number etc info on (most) drives. Whether parameters other than the serial are taken into account during the key making process is something that we could prove quite easily once we had one working "cloned" drive. Just change the other available values/try other drive sizes and see when it stops working...
Re Terry Kennedy, I find it a bit odd that someone should ask for help on other public boards, solve (to some extent) the problem - then not share the solution they've found with others... but maybe that's just me... I guess we're all different :) It would only take a URL to the right flash utility/HD Tools program and someone could run with it.
I agree on the $50 (or whatever price they come up with) suggestion, I said something similar on another thread. One compromise might be to just sell the (empty) DMS cases at a (slightly) inflated price and maintain the goodwill/userbase?
-
Some people are just like that I guess.
I know hes signed up to the boards but I am not going to beat around the bush about it.
Thats pretty gay.
However, thats enough of that...
I don't think phatnoise thinks we will ever get around their setup, or worse yet, the just dont care. Now if it was contract related, I might be more understanding but they've been too tight lipped with the fans to date so its hard to say.
I mean, I've bought 3 kegs and a VW phatbox, thats a pretty loyal customer eh?
-
Yep, completely agree with you! And by the way the online signing "subscription" is a great idea! I'd love to go that way but...
Anyway, how do you know a drive's sn can be changed? Ever witnessed that? I mean, I hope you're right but I just don't the reason why they would build it like that.
Para
-
well, if you think about the way a drive build process would work, the PCB's would be made someplace and the spindles made in another area, wouldn't it make sense that they would put the serial number on the drive somehow?
Just like with the phatbox I am sure they come off some assembly line and are flashed and tested.
Has anyone here swapped the PCB on a drive and seen if the serial number changes? That would be pretty telling.
-
Anyway, how do you know a drive's sn can be changed? Ever witnessed that? I mean, I hope you're right but I just don't the reason why they would build it like that.
Quote from: http://www.salvationdata.com/hfrpro_detail.htm
SalvationDATA HDD Firmware Repairer PRO can change model number and serial number of HDDs, it can also modify the maximum value of HDDs and restore S.M.A.R.T list; Reads and writes on HDD firmware zone; Start up the built-in selfscan function of the defective HDD...
Unfortunately that's only for maxtor, they do have a version that works with Fujitsu but it dosn't SAY it can change serial number
-
I have two identical drive I can try swapping PCBs on, but they're 20gb IBM travelstars heh...
Also, I think they change the serial number whenever they refurbish a drive
-
still might be an interesting test.
-
^^^ I mean the drive swap of PCB's
also the site you linked mentions a method of hot swapping the PCB to be able to flash a drive thats firmware is toast. so that pretty much settles it in my book. :)
-
^^^ I mean the drive swap of PCB's
heh, running into technical difficulties: anybody know where the *&^%%$# I can get those teeny weeny hex drivers?
-
think they have them at homedepot or walgreens :) Dunno if they have that in HI or not. havent had the chance to make it out there.
Also timewarner in austin's DNS is not querying the phathack.com domain properly for some reason.. I had to go to the name server hosting it from a whois to get the IP and put it in my host file. stupid timewarner DNS server.
-
SalvationDATA HDD Firmware Repairer PRO
Ok, sounds interesting. I just thought even if these drives are assembled in different steps they might use an EPROM which will be programmed once to hold the sn. This way it couldn't be changed while it's still easy to programm it for individual drives even if they do it after their final tests... Time will tell, hopefully ;)
-
Well, I found the appropriate hex drivers.... and swapped the boards... at which time NOTHING happened. The BIOS wouldn't even detect the drive... switched back and everything worked again
-
That is an interesting situation..
I have swapped drive boards before and had luck with full size hard drives instead of the laptop drives. Hmm...
-
Emule has thrown up some Fujitsu ATA drive diagnostic stuff. I haven't downloaded it cos I've got a Toshiba waiting for a "blessing" :-[
-
A user over at Phatnoise turned me onto your forum here, ...........I've been determined, it seems, to do the switch and save HD as well, looks like it may not be as easy as I originally hoped, but not surprised phat has encoded something to keep making the big money on selling drives!
As far as I know, and it's no where in your realm of knowledge,
1. size dosen't matter
2. Phat software is able to reformat and partition their drives for you.
3. is it possible you all are looking the wrong way?
The key is the BOX, the lock is the Drive, rather then the reverse?
-
A user over at Phatnoise turned me onto your forum here, ...........I've been determined, it seems, to do the switch and save HD as well, looks like it may not be as easy as I originally hoped, but not surprised phat has encoded something to keep making the big money on selling drives!
As far as I know, and it's no where in your realm of knowledge,
1. size dosen't matter
2. Phat software is able to reformat and partition their drives for you.
3. is it possible you all are looking the wrong way?
The key is the BOX, the lock is the Drive, rather then the reverse?
The "software" you mention I can only assume you mean the boot disk / cd that repartitions and formats the DMS but works with any drive... that is because it is a series of scripts that avoid touching the portion of the hard disk that the "magic sectors" are stored in so any drive would work using those scripts I assume. However once you try and use it with the box, the box is going to check the drive for a key.
The box is not tied to the drive, the key stored on the drive is how they determine if the audio (audible content for example) belongs on that drive and will then allow you to play it.
Hope that helps.
-
Well thanks, it probably won't help me much since, I'm pretty good at rebuilding hardware in PCs, and writting POS systems, when it comes to the level of you all, I'm a dumb duck.
YES, I was refering to the software you recieve with the box, and your reply makes absolute sense.
As for the seriel numbers, hmmm, old box works with much newer DMS , they must have really thought ahead...........
Here's something to pounder though!
I just recieved my 3 Phatnoise systems which I purchased on EBAY, full sets for my Audi, cable, L brackets and 20 gig dms, each for $180.00.
Brand New, how can that possibly be since Audi wanted $798 each and just to buy a 20 gig DMS from phat is would have cost me nearly as much as the entire System just cost me?
Kind of makes trying to install any of my 100 gig drives a waste of time, except, it would be so cool to break this!
"Is it true, that Phatnoise will not function, or for some reason will not use NTFS, and sticks to the FAT32?
If so, why would that be?
Thanks
-
linux, which is what the phatbox runs, has to have support to read the filesystem. The way the phatbox is set up it expects the file system to be Fat32 for both partitions on the DMS. if they wanted to they could add NTFS support but it would increase the size of the kernel and maybe not fit in the flash rom, but I dont know for sure.
further more.. I dont really see any reason at all to add NTFS support to a device like the phatbox.. NTFS features are for servers and workstations.. logging file system, security etc are all rather pointless for an embedded music player. and filesystem compressions doesnt really buy you anything but increased CPU usage when dealing with MP3s and the like as they dont compress much if at all.
-
Well, the only nice thing would be to have a journalling filesystem like ext3/xfs - which is of course a linux thing! Guess what... ::)
-
why would you want journaling on an mp3 player? not much gets written to disk and even if it did, its not critical that the data be intact for things like logs... journaling creates additional disk I/O and in an embedded system you want to get rid of extra things like that because it means CPU overhead which might cause skippy audio. :)
and for the guess what im either going to say that since the kernel has EXT2 support to mount the ramdisk that means it has EXT3 maybe depending on the kernel build out... or that you have finished your software initial release, or you were going to say chicken butt... :)
-
You're right, ext3 doesn't make that much sense although I always like to have my fs consistent even in case of the drive being pulled out of the box or some kinda power-failure...
However, the biggest advantage for Linux users is the better syncing! Have you ever tried to do a clean sync between a unix filesystem and vfat/fat32. It really sucks! Using a case-sensitive, timestamp-using filesystem on both sides makes it lot easier - thumbs up! And yes, there's ext3 support available :o
Para