USB Sniffs of various MZ-NH1 actions.

[hobgoblin]

this is one funny thread people, nice find on that error message fuz (and sorry to hear about the messed up library, some sacrefices have to be done in the name of science and all that).

hmm, that talk about hidden areas and i got thinking that, as even windows cant get at part of the area and hi-md supposedly use standard usb protocol for when windows transfers files, there must be some chip in the md players themselfs that regulate what part of the disc that windows gains access to.

did anyone spot any interesting deviations from when a song was copyed onto the disc to when a data file where?

im still surprised at the lengths that sony and similar can go to obfuscate what thier stuff does so as to avoid people useing them in ways not liked...

[ksandbergfl]

Anyhoo, to cut a long story short, theres this teensy little file called 'omg_id.dat' in the omgkey directory which just happens to have data thats found throughout an OMA file.

...

The OMG_ID.DAT file is the data that identifies your PC to SonicStage. It is the 20-bit key, without song-specific info.

Take a look again at the 20-bit key in one of your OMA songs (or in the TRKIDXxx file). You will see your OMG_ID.DAT key, plus the song-specific info filled in. See the last byte? Say it's 5Ch. Search for a folder on your PC called "procfile". This is where SonicStage keeps all the key files for OMA songs that SonicStage has generated. Open the folder "procfile/5C". See the OPF file? It will have the same name as the key, ie 0105500040112233445C.OPF.

The OPF file has all kinds of info... whether the original file was a WAV or a CDDA (CD rip) or an MP3, for instance. See bytes 0008h thru 000Fh? This is the song's MAC ID. These 8 bytes get inserted into the MACLIST.DAT files in the "OMGKEY" folder (same folder as the OMG_LOG.txt file). Every time you convert a song to OMA, another 8 bytes gets inserted into the MACLIST.DAT file at byte 0028h (which pushes the other bytes ahead by 8).... and the song counter at byte 001Ch gets incremented by 1. I assume the MCLIST.HMA files on the HiMD itself work similarly.

>>warning<< You have to be very careful inserting bytes into the MACLIST.DAT files, or you will trash your SonicStage installation and have to start over.

Finally, if you have Microsoft Access, open up the most recent MTDATAxx.dbf you find in the SonicStage folders. You will see all the SonicStage data for the OMA songs your PC has processed. I won't go into detail here, but you should easily be able to identify the OMA key info, the bitrate, etc.

All these different files have to be "in sync" for SonicStage to play an OMA file. Any "hack" or utility that wants to copy OMA data, restriction-free, from HiMD (or to transfer OMG/OMA files from PC to PC) will have to factor in all of this.. plus maybe more that I haven't come across yet. I haven't had much time to hack around this week, but maybe on Friday I can make some more progress.

I hope my contributions are helping you all out. Happy hacking!

[dex Otaku]

Geebus, man. You remind me of me and my friends maybe 13 years ago.

I'm with the thinking that your contributions are of enormous value.

Happy hacking indeed!

[poorlyconditioned]

The OMG_ID.DAT file is the data that identifies your PC to SonicStage. It is the 20-bit key, without song-specific info.

Take a look again at the 20-bit key in one of your OMA songs (or in the TRKIDXxx file). You will see your OMG_ID.DAT key, plus the song-specific info filled in. See the last byte? Say it's 5Ch. Search for a folder on your PC called "procfile". This is where SonicStage keeps all the key files for OMA songs that SonicStage has generated. Open the folder "procfile/5C". See the OPF file? It will have the same name as the key, ie 0105500040112233445C.OPF.

The OPF file has all kinds of info... whether the original file was a WAV or a CDDA (CD rip) or an MP3, for instance. See bytes 0008h thru 000Fh? This is the song's MAC ID. These 8 bytes get inserted into the MACLIST.DAT files in the "OMGKEY" folder (same folder as the OMG_LOG.txt file). Every time you convert a song to OMA, another 8 bytes gets inserted into the MACLIST.DAT file at byte 0028h (which pushes the other bytes ahead by 8).... and the song counter at byte 001Ch gets incremented by 1. I assume the MCLIST.HMA files on the HiMD itself work similarly.

>>warning<< You have to be very careful inserting bytes into the MACLIST.DAT files, or you will trash your SonicStage installation and have to start over.

Finally, if you have Microsoft Access, open up the most recent MTDATAxx.dbf you find in the SonicStage folders. You will see all the SonicStage data for the OMA songs your PC has processed. I won't go into detail here, but you should easily be able to identify the OMA key info, the bitrate, etc.

All these different files have to be "in sync" for SonicStage to play an OMA file. Any "hack" or utility that wants to copy OMA data, restriction-free, from HiMD (or to transfer OMG/OMA files from PC to PC) will have to factor in all of this.. plus maybe more that I haven't come across yet. I haven't had much time to hack around this week, but maybe on Friday I can make some more progress.

I hope my contributions are helping you all out. Happy hacking!

Dear Hackers:

Keep up the good work. I can't contribute, but I'm hoping all the evil scheming gets cracked. It just makes me wonder how much effort Sony put into DRM, and consequently, how little resources they must have remaining to write software that actually works!

One thought. Do you think that all this DRM stuff is written by some other company? Or maybe it is written in some high level database language? It just seems way too complicated for Sony to come up with on their own.

Richard

[streaml1ne]

Any updates gents?

[marcnet]

Nope. I can follow and confirm what poorlyconditioned wrote. But thats about it. I have no idea what the other values are in the .OPF file

[fuz]

I'm also sorta at an impasse.. but thats me being busy doing other things (do you know how hard it is to pack one's worldly belongings into just 20 kgs?).

Only thing i've had a chance to play with is the EKB stuff (theres a directory with .ekb files in it) and all i've done is made sonicstage incapable of using HiMD media.. eheh.. oops.

I think the weirdest/not-so-goodest thing i've noticed is how uploads work, it seems to transfer the data (and all relevant keys/data/ident/whatever) to the pc, munge things on the MD and then do a big conversion thing on the PC side. I really hope that conversion step isnt critical as its something not easily duplicable by simply copying bits around..

[ksandbergfl]

Here's a summary of my notes for the past week:

The MACLISTx.dat files in the OpenMG folder are not required for OMA song playback... if these files are trashed, SonicStage will still play the OMA file,as long as it was created on that PC. This is not what I expected, but very handy to know. With this information, I did another test. I installed SonicStage on two PC's (PC1 and PC2). Immediately after installation , I copied the PC key (in the OpenMG/OMGKEY/omg_id.dat file) from PC1 to PC2, so both PC's had the same ID. I generated OMA songs on both PC's. I copied the OMA song (and all of it's related key info in the *.OPF file, MTDATA.mdb, etc.) from PC2 to PC1. As far as I could tell, all the pieces were there, on PC1, to make PC1 think the OMA file was created on PC1. However, PC2's song still would not play on PC1 (got the "invalid rights management info" message). All the songs created on PC1 would still play OK.

So, that leads me to believe that there is additional key info, specific to each PC, that is somehow getting written into the OMA data itself. I am 90% sure that this info is in the OpenMG/OMGRIGHT/*.ICV files. An ICV file gets created for every OMA song during conversion. The ICV file is a 4-byte file. I think that these 4 bytes are inserted at various points inside the OMA file, as either a file marker or perhaps some sort of checksum. I need to do much more experimenting. First, I guess, would be to convert the same audio file on each PC, and do a byte-for-byte comparison of the resulting OMA files, and see what's different.

[ksandbergfl]

On a different note, has anyone taken a look at the files in the EMDKEY folder? In my install of SonicStage, there are 4 folders, 001 thru 004. Each folder has two files, a CERT.DAT and a PRIV.DAT. The data in these files indicates that they are "permissions" or "privilege" for specific apps to use to be able to decode OMA files. 001 has the rights for SonicStage; 002 has the rights for Windows Media Player; 003 has the rights for IBM EMMS player; and 004 has rights for Liquid Audio Player.

If you rename/trash the files in 002, for example - Windows Media Player can no longer play OMA files.

I'm not sure what value this information is, but maybe it will give someone an idea of another way to decode OMA data in "faster than real-time", ala HIMDRenderer with local OMA files. I am wondering if a "virtual HiMD player" is possible.... that is, a software version of an NH600 that runs on the PC, and can play any OMA file and/or directly read the *.HMA files on a HiMD disk.

[streaml1ne]

Resurrecting an old thread. Found this in the openmg readme file:

* Notes for Net MDs

- Unlike Memory Stick-equipped products, NetMDs do not support restoring usage rights if content checked out on Minidisc is deleted.

You can reset rights on Memory Stick?

I tried running a Visual Studio debug on the Sonic Stage process and I get a bunch of asm code then it pukes. Anyone know how to keep it from crashing?

[marcnet]

Yeah ... If you can somehow get the Kernel function of IsDebuggerPresent() to return FALSE, or if you can replace all references to that function in the sony dlls to nops (bare in mind that the function is not linked directly - its called via LoadLibrary and GetProcAddress)

I caught a luckey glipse of the debugging prevention code when I was looking at NetMD stuff a while ago... Never figured out how to remove it though.

[streaml1ne]

heh, Anyone try running sonic stage through VMWare?

[streaml1ne]

http://home.t-online.de/home/Ollydbg/

I'm playing with this and the MP3 conversion util, but I have no clue what I'm doing =)

[Fraggle]

How goes the hack?

[streaml1ne]

How goes the hack?

←

Seems like it's pretty much dead-ended.

[samplehunter]

Just a thought: If the protocol is there to extract encryption keys from the device, and the actual music data can be read from the big .hma file, then you have your own .oma file maker.

This could make my HIMDRenderer program even better :smile:

But... Im not promising anything - just that Ill have a really good look at some point in time.

←

If you're able to do this, you will be the new god of the HiMD users.

...or propably shot by Sonys secret service

[samplehunter]

just another idea:

if you record a long period of digital silence in pcm with the unit and look at the encrypted HMA file, along with the other infos you've got.

Wouldn't this help to learn about the encryption?

if you know every byte of the soure stream (which is possible with pcm)

you probably get the key...

[marcnet]

if you record a long period of digital silence in pcm with the unit and look at the encrypted HMA file, along with the other infos you've got.

Wouldn't this help to learn about the encryption?

if you know every byte of the soure stream (which is possible with pcm)

you probably get the key...

Thats assuming they use straight XOR to encode the data..

If they using bit shifting / subtraction / multiplication / other mathematical or logical operations then it will make the key more difficult to obtain. Also, byte X in the encrypted stream could depend on byte X-1... X-100 ... X-Y .... X+1.... X-1+key[1].... X-1 >> key[5]....

you get the point.

[hobgoblin]

it isnt the key itself thats interesting, its the algorithm (sp?). do they use a normal cpu to handle it or do they use a special chip to do the decodeing. and if so, what will be the most cost effective way of doing it in time and power use? rember that it must be done on a file that have to be continualy read unless you have the ram to store the whole file, decode it and then feed the decoded song to the d/a converter.

after compareing the hma to the pcm one should be able to, in theory atleast, build a algorithm that can copy the transformation.

i wonder, can one use media formated using one sonicstage install to store files from another (i dont have a hi-md player so i cant test it. i was holding back until it was sure if we would get mp3 support or not)? and can one play media from one hi-md unit on another? if the first is no but the second is yes then most likely the key is transferd to the media at format, locking the media to a install of sonicstage.

could one then do comparison of dumps of the formated but blank media from diffrent sonicstages to see where the diffrence is? most likly there is where the key is stored for use with recording and playback. turning the key more into a form of fingerprint then a encryption key.

then one have the key, and then one gather up some keys and files made by the keys but with the same pcm source. then one look for patterns.

if one can then nail down a kind of pattern based on the keys one can in theory recreate the algorithm used. or atleast one that behaves the same way given a key and some data.

problem is that its a whole freaking lot of work...

[samplehunter]

Thats assuming they use straight XOR to encode the data..

If they using bit shifting / subtraction / multiplication / other mathematical or logical operations then it will make the key more difficult to obtain.  Also, byte X in the encrypted stream could depend on byte X-1... X-100 ... X-Y .... X+1.... X-1+key[1]....    X-1 >> key[5]....   

you get the point.

←

I also don't think they do a simple xor. (that was too easy :-) )

But if you put in a well defined pcm signal (e.g. bunch of zeros, don't know if it's eqal to dig. silence) then you will get kond of pseude random noise in the encrypted file on the disc.

And maybe there is a chance to recognize a pattern or the "noise" will somewhere repeat (an indication for the keylength maybe).

Then reformat the disc and copy the same file (the silence) again and look at the "noise". if it is different you could repeat this a few times and look at the differences between the encrypted versions.

As a next step it could be tested if there is a difference between recording zeros via SPDIF in and via SS.

If the "noise" is really always the same (this would be almost too good to be true)

the next step would be recording a bunch of 0001x, 0101x or FFFFx or some other word value and then a 32236 words long ramp from 0000 to FFFF and so on...

I think there must be a kind of repeatness in the encrypted zeros as the algorithm may have only a limited number of keys.

The algorithm may also have a limited complexity as the decoding in the unit has to be done in realtime and it surely has to be not too expensive.

Maybe Sony also decided to use an encryption algorithm that is free for comercial use rather than spending huge licence fees.

Anyway, I think it's just worth another try and the cracking of an algorithm would surely be easier if you exactly know the plain data you put in.

[samplehunter]

...

i wonder, can one use media formated using one sonicstage install to store files from another (i dont have a hi-md player so i cant test it. i was holding back until it was sure if we would get mp3 support or not)? and can one play media from one hi-md unit on another? if the first is no but the second is yes then most likely the key is transferd to the media at format, locking the media to a install of sonicstage.

...

←

on the unit side, you can always play every disc. the whole security thing is related to the transfers to a pc.

you can transfer some audio to the himd, some other should also be able to transfer some audio to the disc from his pc, send you the disc back and you will be able to play the whole disc on your unit.

But transfers FROM the unit to the pc are heavily restricted.

The only thing that could be transferred to the pc are recordings made with the unit and this only once per track. So if you have made a recording with the unit, then give the disc to someone, he would be able to transfer this track to his pc. If he gives the disc back to you, the track will be marked on the disc as being transferred already and you won't be able anymore to transfer it to your pc.

[megnez]

on the unit side, you can always play every disc. the whole security thing is related to the transfers to a pc.

you can transfer some audio to the himd, some other should also be able to transfer some audio to the disc from his pc, send you the disc back and you will be able to play the whole disc on your unit.

But transfers FROM the unit to the pc are heavily restricted.

The only thing that could be transferred to the pc are recordings made with the unit and this only once per track. So if you have made a recording with the unit, then give the disc to someone, he would be able to transfer this track to his pc. If he gives the disc back to you, the track will be marked on the disc as being transferred already and you won't be able anymore to transfer it to your pc.

←

so what about recording a known track (PCM or a known signal e.g. a sinus), store all files. download it with sonicstage and compare all files? wouldn't you get a answer of what sonicstage changes while 1st download?

[hobgoblin]

so the encryption system is more like a fingerprinting system then anything else? a recording done with the hi-md device should in theory be unlimited transferable if one finds the bits that are set to indicate its transference.

but files that have been written onto the hi-md is allso encrypted using the "fingerprint" of the sonicstage that did the write? and reinstalling sonicstage changes said fingerprint (and most likely puts some checks here and there in the files to make sure that you dont change the fingerprint after the install).

hell, it may even be that they dont encrypt in any way at all, but instead just tag the files with fingerprints to indicate where they are comeing from. that is unless i have skipped something and someone have allready sendt over a pcm file and seen that it changes when on the hi-md itself.

Edited March 16, 2005 by hobgoblin

[samplehunter]

I just have found this document:

http://www.sony.net/Products/SC-HP/cx_news/vol20/pdf/tw.pdf

describing the encryption technology of the MG Memorystick.

I think it would be similar to the HiMD encryption.

From other sites i've read i guess that the algorithm could be a kind of DES.

Hope that helps.

(Sony can be proud... the DVD encryption was cracked after a few months and this "Open"MG thing goes about since 2002)

[Latexxx]

PSP's specs mention that it supports AES MagicGate. So AES it shall be. See http://www.us.playstation.com/consoles.aspx?id=4

[samplehunter]

PSP's specs mention that it supports AES MagicGate. So AES it shall be. See http://www.us.playstation.com/consoles.aspx?id=4

←

Yes, right. This seems to be a quite valid source.

OK, so it's AES 128bit. Now that we know the "enemy", do we know any weaknesses?

Any chances for brute force in a time shorter than a human life?

Or could it be done with more sophisticated methods?

[samplehunter]

so what about recording a known track (PCM or a known signal e.g. a sinus), store all files. download it with sonicstage and compare all files? wouldn't you get a answer of what sonicstage changes while 1st download?

←

This was the first thing we all have tried i think.

The files are changed indeed. Bit this doesn't really help.

Just do the following: record some audio, make an image of the disk, transfer the file, restore the old image to the disk. It's now unplayable!

There are kind of two partitions on the disk. One for the user data which is FAT formatted and shown as a removable drive.

And [mystic sounds here] THE OTHER! The "dark side" of your HiMD. It's where the Content keys and the storage keys and other system data is stored.

This part is not accessible from the pc. this part is maintained by the unit only i think. you can request a session key and a content key to encrypt atrac or pcm data to send it to the unit.

So if you transfer something to the pc, there is something changed in the protected area and a flag in the file. If you restore the old image of the user area the checksums/keys/whatever wont match anymore and it cannot be played.

I think it works as follows:

You have to log in to the unit and request new keys which are used to decrypt the data from the usb. i think it's the unit that marks these tracks as transferred. So the second time the function will fail. the only thing you can do unlimited times is requesting to stream a track as pcm in realtime. this is encrypted too, but as it is not the original file there is a virtual content key generated which enables Sonicstage to "play" the HiMD via the soundcard.

So we first have to do authentification to the unit:

-Request a key or passphrase from the unit.

-send the right answer to this phrase to the unit.

-the unit recognizes you as a valid application and sends a session key.

This would be the most difficult part. You'll have to find out where and how the authentification process is done in sonicstage.(Any success with debugging yet?)

all further keys transferred from and to the unit are encrypted with this session key.

To read a file, the unit sends the encrypted content key which you can use to decrypt the data.

the 1:1 transfer of a file would still be possible only once. alternatively you can request (with another command) a pcm stream of a track. you get the valid content key for THIS stream, not for the file.

If the track was recorded in pcm this doesn't matter, because it will be a "pcm->pcm" conversion which is identical.

an atrac file would be first decoded to pcm.

Unfortunately this is done only in realtime i think. If this is wrong and faster speeds are possible this would be interesting nevertheless.

Otherwise Total recorder would be much easier to use.

BTW: is there a freeware alternative to Total recorder?

[hobgoblin]

the question is, how smart is the hi-md player? i dont think its the player that messes with the secret partition but sonicstage via the special protocol.

so again, did anyone find a diffrence in the usb traffic from tranfering normal files to transfering songs? that diffrence will be important if one can nail down what changes from transfer to transfer and what stays the same.

[streaml1ne]

the question is, how smart is the hi-md player? i dont think its the player that messes with the secret partition but sonicstage via the special protocol.

so again, did anyone find a diffrence in the usb traffic from tranfering normal files to transfering songs? that diffrence will be important if one can nail down what changes from transfer to transfer and what stays the same.

←

The sniff files at the beginning of this thread contain portions of a regular Windows file transfer and a Sonic Stage transfer. They're large and contain alot of repetitive crap which turns this into a needle in a haystack kinda thing. I'm not entirely sure how to decode what's in them so I couldn't tell off the bat if there were major differences or secret protocols. Any USB programmers around?

[hobgoblin]

damn...

[fishstyc]

Another thought...

I was wondering, do you think that an OMA-file contains ALL the information to be played back, or would either the unit or sonicstage need some other information (stored somewhere else) in order to play back a file (converted on your pc)?

- In the first case, would it be an option to try to work around all the checks that the Sonicstage dlls make to see if a file CAN be played back? (Then, to do with your own recordings what you please, would mean download them once and then upload them again to the unit, and from that moment you could copy them again out of the ".hma files on the disk.)

- In the other case it would be a lot harder to make oma's "portable" from any device to any device.

I am sillently hoping for the first case... what do you think aout it?

[ozpeter]

BTW: is there a freeware alternative to Total recorder?

I started a now-lost thread just before the forums fell over in which I reported that, with my soundcard at least (Echo Mia Midi) one can record direct into Adobe Audition / Cool Edit / whatever (I imagine) from my NH900 via USB, and get a result which is bit for bit the same as would be obtained via Total Recorder. I did it by appropriate settings of the soundcard mixer in conjunction with looping its digital output back to its digital input. Playback is still via SonicStage, as if using Total Recorder - you can't readily get around that (or at all).

I also mentioned that if I changed the sampling rate of the soundcard to 88.2 (from 44.1) the MD would play back (via USB) at double speed and could be recorded like that, then resampled to 44.1 - eureka, high speed digital download with no DRM. But - and there had to be a 'but' of course - the MD kept stopping after a couple of minutes. It also resets to normal speed for each new track. When I tried at 48kHz the MD seemed to be happy with that slightly faster speed and didn't bomb out after a couple of minutes. The double speed (88.2) just seems to be more than it can handle.

In essence then, playback from MD to PC via the USB seems to work on much the same basis as playback through any other type of digital connection.

This all indicates that there's some possibilities through that kind of technique, but as it stands it's probably more trouble than it's worth.

Sorry this is slightly off the present topic but I thought it worth chucking into the knowledge pool here anyway, as I can't find similar reports already posted.

Edited April 8, 2005 by ozpeter

[fishstyc]

The OMG_ID.DAT file is the data that identifies your PC to SonicStage.  It is the 20-bit key, without song-specific info.

Take a look again at the 20-bit key in one of your OMA songs (or in the TRKIDXxx file).  You will see your OMG_ID.DAT key, plus the song-specific info filled in.  See the last byte?  Say it's 5Ch.    Search for a folder on your PC called "procfile".  This is where SonicStage keeps all the key files for OMA songs that SonicStage has generated.  Open the folder "procfile/5C".  See the OPF file?  It will have the same name as the key, ie 0105500040112233445C.OPF. 

The OPF file has all kinds of info... whether the original file was a WAV or a CDDA (CD rip) or an MP3, for instance.    See bytes 0008h thru 000Fh?  This is the song's MAC ID.    These 8 bytes get inserted into the MACLIST.DAT files in the "OMGKEY" folder (same folder as the OMG_LOG.txt file).    Every time you convert a song to OMA, another 8 bytes gets inserted into the MACLIST.DAT file at byte 0028h (which pushes the other bytes ahead by 8).... and the song counter at byte 001Ch gets incremented by 1.    I assume the MCLIST.HMA files on the HiMD itself work similarly.

>>warning<< You have to be very careful inserting bytes into the MACLIST.DAT files, or you will trash your SonicStage installation and have to start over.

Finally, if you have Microsoft Access, open up the most recent MTDATAxx.dbf you find in the SonicStage folders.    You will see all the SonicStage data for the OMA songs your PC has processed.  I won't go into detail here, but you should easily be able to  identify the OMA key info, the bitrate, etc.

All these different files have to be "in sync" for SonicStage to play an OMA file.    Any "hack" or utility that wants to copy OMA data, restriction-free, from HiMD (or to transfer OMG/OMA files from PC to PC) will have to factor in all of this.. plus maybe more that I haven't come across yet.  I haven't had much time to hack around this week, but maybe on Friday I can make some more progress.

I hope my contributions are helping you all out.  Happy hacking!

←

Any new ideas in the meantime? Is someone still following this path?

(If you make a backup of your db, and you mess up, can you start over just by restoring the backup made with the backup tool, or is it worse?)

[hobgoblin]

i just grabbed the usb logs and is having a look at them.

i have armed myself with a spec of the usb protocol.

im no usb tech tho so god knows how long this will take. still, it looks similar to a packet sniff from a tcp/ip connection if i can filter out the payloads from the background traffic i should be able to figure out what SS (how fitting) does compared to just a normal file transfer...

[toxigenicpoem]

Just a thought, at work right now, and school afterwars, so I wouldn't be able to get to it for about 8 hrs. But has anyone tried copying the full installation directory of SS from one pc, to another pc? And exporting said registry keys from one PC to another?

Edited May 16, 2005 by toxigenicpoem

[fishstyc]

Just a thought, at work right now, and school afterwars, so I wouldn't be able to get to it for about 8 hrs. But has anyone tried copying the full installation directory of SS from one pc, to another pc? And exporting said registry keys from one PC to another?

←

Why would you do that? You can use the backup tool, no? (Except probably for downloaded content, but so far I have none...)

I mean if you want to be able to play your created tracks on 2 pc's, you can delete all files 'from your library' - don't delete the actual files if you want to keep them (drm info will still exist), make a backup and put it back on the other machine.

The thing is, we would like to get new files into this database, so we don't have to backup our entire installation every time, or find a way to disregard all the drm crap of course and just play any file of course.

Tell me if I am missing your point here.

[toxigenicpoem]

Right I understand your thoughts. I guess my line of thinking runs with the duplicating keys on both systems, if you have the same key available on both systems, then there shouldn't need to be any backup needed.

Needless to say, last night I tried this, and obviously prob. 1 was that OpenMG wasn't installed, so I installed OpenMG, and SS, but DID NOT run them. I didn't go through the 'Creating Key' process.

I then tried to run SS from a backup, and the program would NOT load. It would not return an error, it would not do anything funny, except start to the load, and then bomb out.

And I also thought of a 2nd question, has anyone tried to get the BIOs from the Hi-MD?

Edited May 17, 2005 by toxigenicpoem

[fishstyc]

i just grabbed the usb logs and is having a look at them.

i have armed myself with a spec of the usb protocol.

im no usb tech tho so god knows how long this will take. still, it looks similar to a packet sniff from a tcp/ip connection if i can filter out the payloads from the background traffic i should be able to figure out what SS (how fitting) does compared to just a normal file transfer...

←

From what I know so far, downloading a track creates a temporary track somewhere, that seems like a normal oma file, with the same data that can be found in the big data file in the hmdhifi folder, so you will probably see all this data pass by.

Afterwards some info on the disk gets changed, namely part of the key and some bits indicating this track can be uploaded, and also one small file (forgot which one) gets completely messed up.

Afterwards I assume you will find the "magic key" (if it exists) will be handed over (because that is what fails if you already transferred the file, but edited the bits indicating that it is a transferable file, to tell your himd this file can still be transferred).

Afterwards the file is converted to a file encrypted with your own machine-key, and put in the drm database.

[hobgoblin]

so far, all i have been able to kind of isolate is some of the background usb traffic

basicly the logs in their current state is hard to match to the specs for the usb protocol. it seems to have taken the usb packages apart somewhat.

and i thought that tcp had a lot of overhead at times. its featherweight compared to this

[toxigenicpoem]

Do you think they pad it, to make up for the slow speed of the Hi-MD recorder?

My next question, because I havn't seen this yet, has anyone done a HD/REG snapshot and compared this to 1) a New installation, and Key generation of SonicStage, and 2) A new file creation/upload.

If someone beats me to the punch, here is the software I was looking @ for snapshoting the harddrive, and comparing the file, and registry differences.

http://www.gold-software.com/DiskandRegist...review13099.htm

Wheres DVDJohn when you need him !

Edited May 17, 2005 by toxigenicpoem