Here are the results of two tests I've run so far.
Test #1:
In order to determine if the magic key testing routines are part of the code for the first-run processor (for lack of a better term) I added an empty file named "forceupdate" in the root of the PHTSYS partition. I did this on my non-Phatnoise Toshiba drive - the same model as my Kenwood DMS drive, but with a different firmware revision I've since found out. Anyway, after a raw sector by sector copy of my original DMS to this non DMS drive the Keg wouldn't recognize the drive. So by adding the forceupdate file, and seeing the drive get rejected in exactly the same manner as without this file, it appears the key checking code is indeed part of the first-run processors routines, and runs before the code that updates the firmware.
Interestingly, the garbage (key) stored between the partition table and the start of the first partition is about 130k in size. I'm wondering if this isn't actually part of the first-run processors code!
What I would like to do now is to rename a file or two on the DMS just to be absolutely certain that the Keg doesn't load anything off of the drive, after mounting it, in order to check the key. What I need is for someone to tell me the order that the files are loaded. Is the file linux loaded first of all, and then royallin.ux? What are these two versions anyway? I assume one of them has to be loaded before rc.sh is called, right? Please let me know.
Test #2:
I wanted to see if the partition sizes can be changed. Having a small 10GB DMS and seeing 230+MB of space wasted on the PHTSYS partition prompted this. In a nutshell, it worked!
Here are the gory details:
I first tried to reduce the partition down to about 31MB and use FAT16. Barf. The keg only recognizes FAT32. Of interest is the fact that when I plugged the DMS into the Keg with the FAT16 PHTSYS partition, it passed the key check and started a firmware update! (The drive was initialized due to the reformat, hence the forceupdate file on the DMS. ) The firmware update didn't complete in over 30 minutes so I knew it wasn't working, it couldn't read the format of the drive. I had no choice but to pull the DMS out while the lights were blinking, and they didn't stop blinking! I had to unplug the Keg to HU cable to kill the lights.
I then reformated the partition to the smallest size (around 33MB) that FAT32 would allow and reformated. Unfortunately, I couldn't force the 1k cluster size I wanted, it defaulted to 1 sector per cluster. I was hoping to reduce the FAT size during this experiment as well. I figured it couldn't hurt. By the way, the original cluster size was 8k, so there was a bit of slack waste, but not anymore, and the FAT is roughly the same size it was before. I wonder if the Keg caches the FAT. I'm guessing not so a smaller FAT would mean faster file access. I think the format utility that comes with XP allows for forcing the cluster size, so I might play with that next for some more fun. Anyway, after reformatting and reinitializing, the DMS worked fine!
So I gained around 230MB, which is roughly 4 or 5 more CDs. And I also feel this proves that there is no partition table data in the key as well. AND as a side effect of this I corrected Phatnoises somewhat wacky partition table. They use a Linux utility to do the partitioning and to the best of my knowledge it doesn't break any rules, it just does things in an unusual way. It starts the second partition in the very next sector after the extended partition tables sector. Usually a head (side) is skipped. This is one of the reasons that programs like Partition Magic won't operate on the partition tables of the DMS. Nortons Disk Doctor also complains about problems with the partitions. At least mine did. Phatnoises partitioning program also incorrectly sets up the extended partition as just that, an extended partition, not an extendedx partition, which is really what is should be, seeing as how the partition crosses the 1024 track boundary. Maybe this doesn't matter with Windows, but it does with DOS. Anyway, my partition table are cleaned up and Norton and Partition Magic and DOS and Windows and the Keg are all happy with it this way.
I do want to say that I wouldn't recommend that anyone attempt to repartition their DMS unless they are absolutely sure they know what they are doing. Most partition utitlities WILL erase the magic key. If there is enough interest I will post a guide on how one can change their partition sizes, but even then it will require some understanding of partition tables and also the tools to manipulate them.
So here are some questions, maybe they might be better in their own thread. I'll leave it up to the answerer to start a new one.
What is the boot order of the DMS files?
Are there two different versions of Linux on the DMS? Royallin.ux, and Linux?
Does anyone know what the first-run processor is?
I also did a sector copy using "Acronis True Image", good dms and "exact" non dms 10gb drive
No joy...
I think that royallin.ux is the master self-extracting linux os that loads into memory... I'm looking into it
QuoteIf there is enough interest I will post a guide on how one can change their partition sizes, but even then it will require some understanding of partition tables and also the tools to manipulate them.
I am interested if you get a chance to post it.
Thanks,
Sean
QuoteI also did a sector copy using "Acronis True Image", good dms and "exact" non dms 10gb drive
Can Acronis copy sectors that fall outside of partitions? For instance Norton Ghost only works with partitions and cannot copy the magic key, but DiskEdit will copy every and all sectors making complete bit for bit copies.
And are the firmware versions of your two 10GB drives the same? I'm just curious to know if you have a more exact match than I do, my model is the same but with a different firmware revision.
How do I find the firmware revision, thru code, or physically written on the disc?
QuoteHow do I find the firmware revision, thru code, or physically written on the disc?
You can try this - it's not ideal as it is needs to be installed. Also not sure if it picks up all drives or not as I can't test vs. a DMS at work.
http://www.browsedatabase.com/hdd101.zip
Sample output...
HDD Firmware Serial Number & Other Details:
===========================================================
Controller = 0, Master Drive
HDD Firmware Serial Number: CLP429F4HGEW3A
HDD Model Number: IC25N040ATCS05-0
HDD Controller Revision Number: CS4OA61A
===========================================================
*** Please note this is NOT a serial number for a DMS !!!! ***
If anyone has a better solution please share...
PS I'm pretty confident PN must be using this HDD info and then encrypt it using a Private Key and save it to the DMS when they "bless" the drive before selling it.
The Phatbox then decrypts the encrypted string it reads from the DMS using the corresponding Public Key and compares it to the actual value(s) it gets using hdparm.
If they match, you're in, otherwise flashing lights ad infinitum......
That also means without the Private Key we are scr*wed unless the whole check can be bypassed somehow.
QuoteHow do I find the firmware revision, thru code, or physically written on the disc?
I used an older version of IBMs drive fitness test.
http://www.tacktech.com/display.cfm?ttid=287
QuoteThe Phatbox then decrypts the encrypted string it reads from the DMS using the corresponding Public Key and compares it to the actual value(s) it gets using hdparm.
I'm guessing that the key is checked using only the first-boot processors code, or that the first boot-processors code is the key itself, or part of it. I need to get a handle on the order of the boot files so I can start renaming some of them to see if it interferes with the key check. I suspect it won't.
Remember, it seems that the first-boot processor is responsible for performing the firmware updates and the key check appears to occur before the firmware update routines. It's still just speculation though.
Maybe that's why there appears to be two kernels on the DMS, one for the first-boot processor and one for the main processor. We need to find out.
We also could use a kindly Red box owner who wouldn't mind doing a few tests such as renaming some files to see if they are used on the Red box.
Quote
...Maybe that's why there appears to be two kernels on the DMS, one for the first-boot processor and one for the main processor. We need to find out.
Maybe. Maybe not.
Royallin.ux (Royal Linux) is for embedded devices...
http://wwww.embeddedsoftwaregroup.com/royallinux.php
Probably for the main ARM processor...
http://www.cirrus.com/en/press/releases/P161.html
But this link implies PN did their own port...
http://linuxdevices.com/articles/AT6469667521.html
(Those links are a bit old and probably refer to the Red Phatbox design).
All a bit confusing....
What we need is a disgruntled PN employee to leak us a copy of the signing utility ;)
Any takes? They're bound to be lurking here just for laughs...... ;D
According to press kit they are all very happy though :( (but some good PN history in here)...
http://www.phatnoise.com/downloads/PhatNoise_Press_Kit_10.2004.pdf
Has anyone tries aprocaching
Vincent Busam... he left Phatnoise in February
from vinces website:
------
December 2000 - Februrary 2005 PhatNoise, Inc.
Los Angeles, CA
Advanced Products Development
Helped develop car-based MP3 player, controlled by CD interface to existing head units.
Led design and implementation of client/server networking product.
Designed and implemented other leading-edge features for product, including Palm interface, TCP/IP networking, video playback, and game emulation.
Resposible for all of the "user level" programs running on the PhatBox in the car to manage the system and interface with kernel drivers, audio decoders, song database, and playback control mechanisms. Most projects involved embedded Linux development in C.
------
can't find the video playback or game emulation on my music keg ? ;D
also from sixpak...
http://boxster.sixpak.org/mp3/
i'd never explored that part of the site before - very cool story!
As far as I know, you can make the two partitions any size you like so long as you don't overwrite the first two sectors in the process...
The first partition is limited to being no smaller than 33MB, this is the smallest partition that FAT32 recognizes. There was some speculation that the partition table or table information was involved in the key, but by changing my partitions I basically negated that. So other than the above restriction, it does appear that any sized partitions should work.
Also the first sector has to be changed, that's where the partition table is. The second sector is empty and is probably safe to overwrite. It's sectors 1792-2047 that you should avoid overwriting.
What about the Master Boot Record?
Maybe there is something special in there, maybe the PB will mount the DMS and the MBR will start the entire boot process?
Anyone care to take a look?
There is no MBR on the DMS. I'm guessing booting handled from ROM or firmware.
I'm interested in one thing which I doubt anyone will try:
If one backups his DMS completely by a raw sector copy (maybe using dd), would it possible to restore that image to the SAME drive and have it running again? This way one could at least save some money if he ruins the DMS layout by accident :-/
Para
I don't see how it would be possible for that NOT to work... so yes that should be safe if you're going to try something strange with your DMS... part of why I have a full image of mine
I've wiped and reformatted my 10gb dms without any issues, the only thing you have to do is file copy (BUT Include the invisible files and directories)
Huh? And what about the "blessing" sectors holding the key...?
QuoteI've wiped and reformatted my 10gb dms without any issues, the only thing you have to do is file copy (BUT Include the invisible files and directories)
I'm guessing you mean just reformat, not repartition? The repartitioning is where problems could arise....
Exactly. What I mean is I wanna dump the complete DMS and be able to restore it regardless what has happened (includes repartitioning, hex editing, shreding, wiping, of course nothing physical) to it! This way I could play around with it without being anxious to kill it - which would mean a costly return to Phatnoise...
have you actually run the phatbox formatter... it repartitions as well!
and yes... my DMS has been repartitioned
Phatnoises bootable DMS repair disk seems to set up the partitions correctly to avoid overwriting the key sectors. Other partitioning programs may not be so nice. I agree that a backup and restore (of at least the key sectors) should work. No I haven't tried it, but I'm very close to attempting it.
Uh, good luck 8)
How are you going to do it? Just using dd?
Thanks
I've used the Phatnoise repartitioning program quite a while back. It was probably 2 years ago and I don't remember why I needed to do it, but it worked fine.
Quotethe only thing you have to do is file copy (BUT Include the invisible files and directories)
AndyMan,
I don't seem to have any hidden files or directories on my DMS. Can you tell me about what's hidden on yours?
Has anyone else found any hidden files or folders?
There is a directory called
"System Volume Information" it's system and hidden but it contains multiple directories apparently containing what appear to be restore points...
Well, that's Windoze! As soon as you hook up the DMS to a Windoze PC it'll create that directory for you. Isn't that nice of Bill?! Nothing the PB will ever use...
Para
QuoteThere is a directory called "System Volume Information" it's system and hidden but it contains multiple directories apparently containing what appear to be restore points...
This directory is not relevant to PhatBox, it is made by Windows when you have had the DMS in it's docking.
Either you are using Windows 'System restore' function, or you have deleted files from the DMS from windows explorer, which then has made this directory to hold the recycler.
Thats a windows XP feature that has nothing to do with the keg/phatbox. All your drives have that if you have system restore enabled.
Right click on my computer and select properties, you can disable system restore on the system restore tab and reboot, you should then be able to remove that folder from the DMS.
EFB!!
Quote
can't find the video playback or game emulation on my music keg ? ;D
It's in the new PhatBox that's going into the GM "cross-over sport vans" soon.
Vince, there're so many other interesting questions raised in this thread and you answer just that one... ;)
QuoteVince, there're so many other interesting questions raised in this thread and you answer just that one... ;)
Well, you wouldn't want me to violate my NDA, would you?
Quote
Well, you wouldn't want me to violate my NDA, would you?
HA, no we wouldnt want to get you fired or sued or anything.
Speaking hypotheticaly, is it possible that phatnoise will open up the phatbox in the future to the community to further the development of features and what not?
I recall a discussion on the phatnoise forums a long time ago about file formats that the phatbox doesnt support and you said something to the effect that you couldnt spend time on them since they wouldnt sell more boxes / be widely used.
That of course makes perfect sense, but whats the harm in allowing the phatnoise phanboys waist our own time on getting nintendo audio files to play back on the phatbox?
Edit:
Or say update the flac decoder to work with vorbis tags? Although I have a feeling that you have had to do some customizations to the decoders to make things run smoothly on the limited horsepower of those boxes.
Does a new FLAC file with the new tags not play at all on the PhatBox? As far as I understood, the problem was properly getting the tags to put into the database, which is all done on the desktop. Look at the PMM hacking section for ways to write those files yourself.
I've already mentioned that there were no modifications to the FLAC and other open source decoders used. It's either fast enough out of the box (FLAC,OGG), or not (MPC).
The problem with allowing everybody to hack on the PhatBox is in DRM. It's basically an question of allowing either hacking or DRM playback. It's very hard to do both. Look at a system like the Empeg. Users can replace the kernel, and run any program they want on that. That makes it good for hacking (though it's still hard to add other decoders, it took years for the Ogg decoder to be added after it was available), but you'll never be able to licese DRM playback for it, since any owner can put in a kernel to capture the unencrypted stream. PhatNoise took the option of allowing DRM (audible, WMA someday?). I personally would have chosen allowing hacking. Ideally, a solution would be user configurable to allow hacking, or DRM. It would be technically difficult to do this securily, and even if you came up with something that worked, you could explain it to whomever's licensing you the codec until you're blue in the face, but the'd just hear that there was some way for users to hack the system, and wouldn't work with you.
The funny thing is either way you choose, you've either upset the hackers, or the people who want to play DRM protected music. It's just so hard to please everybody!
QuoteDoes a new FLAC file with the new tags not play at all on the PhatBox? As far as I understood, the problem was properly getting the tags to put into the database, which is all done on the desktop. Look at the PMM hacking section for ways to write those files yourself.
I've already mentioned that there were no modifications to the FLAC and other open source decoders used. It's either fast enough out of the box (FLAC,OGG), or not (MPC).
The problem with allowing everybody to hack on the PhatBox is in DRM. It's basically an question of allowing either hacking or DRM playback. It's very hard to do both. Look at a system like the Empeg. Users can replace the kernel, and run any program they want on that. That makes it good for hacking (though it's still hard to add other decoders, it took years for the Ogg decoder to be added after it was available), but you'll never be able to licese DRM playback for it, since any owner can put in a kernel to capture the unencrypted stream. PhatNoise took the option of allowing DRM (audible, WMA someday?). I personally would have chosen allowing hacking. Ideally, a solution would be user configurable to allow hacking, or DRM. It would be technically difficult to do this securily, and even if you came up with something that worked, you could explain it to whomever's licensing you the codec until you're blue in the face, but the'd just hear that there was some way for users to hack the system, and wouldn't work with you.
The funny thing is either way you choose, you've either upset the hackers, or the people who want to play DRM protected music. It's just so hard to please everybody!
So are you saying that it would be mutally exclusive to allow us to upgrade the drives ourselves (hax0rz!) using a phatnoise tool and having DRM abilities?
Wait.. let me rephrase the question.. in order to bless or whatever you wish to call it, a drive for the keg / pb it would render ineffective any DRM on the box?
Being that right now Audible is the only DRM that I know of that works on the keg / phatbox and I dont use that, i would GLADLY PAY to get rid of it with an open firmware to use whatever the heck drive I want.
I want an all FLAC based playback box with huge storage... thats the whole reason I am even bothering with this...
No, I'm saying it's mutually exclusive to allow DRM playback and user hacking of the software on the system (e.g. adding another decoder).
"Blessing" the hard drive is unrelated to DRM playback. All I can say about that is I was not involved in that decision, and don't speak enough marketing/business to really understand it.
Fair enough. :)
That tells me that barking up the pkeysa.e tree wont get me much closer to the drive keying though (hopefully your being straight with me on that)
I suppose the marketing thought process is something not unlike the southpark underpants gnomes. I hate marketing people.
Gnome 1: This is where all our work is done.
Kyle: So what are you gonna do with all these drives you lock?
Gnome 1: Locking Drives is just phase one. Phase one: Lock Drives.
Kyle: So what's phase two?
[Silence]
Gnome 1: Hey, what's phase two?!
Gnome 2: Phase one: we Lock the drives.
Gnome 1: Ya, ya, ya. But what about phase two?
[Silence]
Gnome 2: Well, phase three is profit. Get it?
Stan: I don't get it.
Gnome 2: (Goes over to a chart on the wall) You see, Phase one: Lock Drives, phase two-
[Silence]
Gnome 2: Phase three: profit.
Cartman: Oh I get it.
Stan: No you don't.
Kyle: Do you guys know anything about corporations?
Gnome 2: You bet we do.
Gnome 1: Us gnomes are geniuses at corporations.
edit: Vince, this is a general marketing jab so nothing personal. :)
Nice one judb! ;D
@Vince: thanks for providing that insight. That's at least a bit clearer... But you're right, it would be very clever to let the user decide (as a hidden/advanced option) which way he/she wants to go. Have yourself DRM or an open platform. Licensees should not be deterred by that solution as it won't compromise their DRM restrictions...
Para