USB Sniffs of various MZ-NH1 actions.

[toxigenicpoem]

Here is what I found after installing. The taking a snap shot of, and then running SS for the first time

File generated on 5/16/2005 at 11:51:11 PM by Disk and Registry Alert

Added -> C:\DOCUMENTS AND SETTINGS\ADMINISTRATOR\APPLICATION DATA\MICROSOFT\INTERNET EXPLORER\MSIMGSIZ.DAT
Added -> C:\DOCUMENTS AND SETTINGS\ADMINISTRATOR\APPLICATION DATA\SONY CORPORATION\OPENMG JUKEBOX
Added -> C:\DOCUMENTS AND SETTINGS\ADMINISTRATOR\APPLICATION DATA\SONY CORPORATION\OPENMG JUKEBOX\TEMP
Added -> C:\DOCUMENTS AND SETTINGS\ADMINISTRATOR\LOCAL SETTINGS\TEMP\HIMD
Added -> C:\DOCUMENTS AND SETTINGS\ADMINISTRATOR\LOCAL SETTINGS\TEMP\HIMDCONTENTS
Added -> C:\DOCUMENTS AND SETTINGS\ADMINISTRATOR\LOCAL SETTINGS\TEMP\HIMDDEVICE
Added -> C:\DOCUMENTS AND SETTINGS\ADMINISTRATOR\LOCAL SETTINGS\TEMP\HIMDFORMAT
Added -> C:\DOCUMENTS AND SETTINGS\ADMINISTRATOR\LOCAL SETTINGS\TEMP\HIMDHANDLER
Added -> C:\DOCUMENTS AND SETTINGS\ADMINISTRATOR\LOCAL SETTINGS\TEMP\HIMDMEDIUM
Added -> C:\DOCUMENTS AND SETTINGS\ADMINISTRATOR\LOCAL SETTINGS\TEMP\HIMDPACMANAGER
Added -> C:\DOCUMENTS AND SETTINGS\ADMINISTRATOR\LOCAL SETTINGS\TEMP\HIMDPROTOCOL
Added -> C:\DOCUMENTS AND SETTINGS\ADMINISTRATOR\LOCAL SETTINGS\TEMP\JETC7B0.TMP
Added -> C:\DOCUMENTS AND SETTINGS\ALL USERS\APPLICATION DATA\SONY CORPORATION\SONICSTAGE\PACKAGES\MTDATA.LDB
Added -> C:\PROGRAM FILES\COMMON FILES\SONY SHARED\AVLIB\CDWALKMAN
Added -> C:\PROGRAM FILES\COMMON FILES\SONY SHARED\AVLIB\CDWALKMAN\CDWALKMAN.LOG
Added -> C:\PROGRAM FILES\COMMON FILES\SONY SHARED\AVLIB\HIMDPACAPI.LOG
Added -> C:\PROGRAM FILES\COMMON FILES\SONY SHARED\OPENMG\OMG_CONTENT.LOG
Added -> C:\PROGRAM FILES\DISK AND REGISTRY ALERT TRIAL\DOLPHDSKA.DATC

Deleted -> C:\PROGRAM FILES\SONY\SONICSTAGE\DATA\XML\APP.XML_

[hobgoblin]

Wheres DVDJohn when you need him  !

←

pissing of the telcos in norway

seriusly, he i working on ways to send messages on the cheap as the price for a single sms here in norway is atleast x10 the mount it costs for the actual data being transferd pr gprs...

and unless he ended up with a minidisc player and wanted to transfer some music from linux i dont think he would be interested anyways. and i have a feel that he have a ipod as he have been messing with itunes for some time now.

[ksandbergfl]

#1.> There is no point in doing a USB sniff for any DRM info. The DRM logic is built into the firmware of the HiMD BIOS. Someone would have to reverse engineer the BIOS chip in order to learn how the "hidden" areas of the minidisc are managed. When your HiMD is plugged into your PC and you click "play" from SonicStage, the HiMD itself is decrypting the OMA internally and simply sending over the decrypted PCM bytes to your soundcard.

#2.> Even if two PC's had the exact same keys, you still couldn't swap OMA files between them without a lot of other work too. Part of the DRM mechanism is a "procfile" (look for a folder on your PC called PROCFILE). Everytime your OMA is played, transfered, edited, this procfile is updated with the current status. If the procfile is missing or corrupt, your PC won't play the OMA.

Additionally, Sony also puts some procfile-related info in the SonicStage database (look for a file on your PC called MtData.mdb). Even if you figured out how to copy an OMA file and its related procfile (the easy part), you still would have to update the SonicStage database accordingly (the part I haven't figured out yet). In short, for an OMA file to be transferred between PC's, SonicStage would have to think that the OMA was generated on that PC....

In my opinion the only way to make OMA's truly "portable" is to reverse-engineer Sony's ATRAC codec. An open-source OMA player. I wonder if it can be done.

[fishstyc]

#1.> There is no point in doing a USB sniff for any DRM info.  The DRM logic is built into the firmware of the HiMD BIOS.  Someone would have to reverse engineer the BIOS chip in order to learn how the "hidden" areas of the minidisc are managed.    When your HiMD is plugged into your PC and you click "play" from SonicStage, the HiMD itself is decrypting the OMA internally and simply sending over the decrypted PCM bytes to your soundcard. 

I am not really shure of that, since I have seen a temporary file on my harddisk (while transferring) with the same audio data as on the md, which makes me think the re-encryption (decrypt and encrypt again with computer-key) should happen on the PC. This means the PC gets a key from the player to decrypt your own recorded material, or doesn't need one if it's not encrypted (maybe just scrambled), then decrypts and re-encrypts the file using a key of his own.

(That's a different thing than playing of course.)

#2.> Even if two PC's had the exact same keys, you still couldn't swap OMA files between them without a lot of other work too.  Part of the DRM mechanism is a "procfile" (look for a folder on your PC called PROCFILE).  Everytime your OMA is played, transfered, edited, this procfile is updated with the current status.  If the procfile is missing or corrupt, your PC won't play the OMA. 

Additionally, Sony also puts some procfile-related info in the SonicStage database (look for a file on your PC called MtData.mdb).  Even if you figured out how to copy an OMA file and its related procfile (the easy part), you still would have to update the SonicStage database accordingly (the part I haven't figured out yet).  In short, for an OMA file to be transferred between PC's, SonicStage would have to think that the OMA was generated on that PC.... 

Nothing changes in the procfiles when I just PLAY a file using 'winamp' or 'media player classic'. I have 2 PC's, and one has been given a backup of the other one. I can play files from the harddisk of PC1 on PC2, as long as it's a track that was already in the DB when the backup was made of course. That also works with files I copied back to harddisk from an md using himd-Xtract.

I agree the hard part will be to make your pc believe a file was created on this pc. That would probably be impossible, if the generated key is dependent on the previously generated key. I hope it isn't, but I can imagine it is...

In my opinion the only way to make OMA's truly "portable" is to reverse-engineer Sony's ATRAC codec.    An open-source OMA player.  I wonder if it can be done.

←

I am still wondering what happens with downloaded music. Maybe you could trick your pc into thinking it downloaded rights info for a certain file from the internet.

[DJ_THE_CROW]

all this is senseless, get your music in WAV, unly use OMA or OMG when SS is converting them before uploading to HI-MD walkman, after that delete all those OMG and OMA crap things...

the only senseful way would be to replace the firmware of your walkman by a hacked firmware... after that you could copy and paste your WAV files to your Hi-MD walkman... but this seems to be a dream.... and thats why ive just bought a CREATIVE ZEN player, and i will write soon which one is better... HI-MD system or the CREATIVE ZEN....

[hobgoblin]

hmm, based on fishstyc's theory and that you can move a hi-md from player to player without trouble there is a theory about how it works:

the hi-md may(most likely) contain a hidden area but i belive all it keeps there is a encryption key for the disc. so when you write a song to the disc it then encrypts the song with the disc key and thereby locks the song to the physical media (kinda like what they where trying to do with the scc on dvd's). this key is replaced whenever a disc is formated.

allso, given that you can transfer recording done by the player ones, but older recorded files cant be transferd at all suggests that there are multiple filetypes hidden under the same oma structure. and as these files are allso wrapped up in encryption (and can be backed up by sonicstage keeping a list of uploaded recordings somewhere. most likely using sha-1 or similar checksum systems. checksum the file before transfer, keep checksum, if someone tryes to transfer a recording with the same checksum again refuse), trying to change one filetype to another by altering bits will most likely turn the whole file into a mess.

the thing is that if we can sniff the right signals from the usb traffic we may well be able to initate a file transfer without sonicstage. then we have a cleanroom transfer to work with. right now its allmost double blind trying to figure out the content on the disc...

[Breepee2]

Creating a custom firmware witch ditches everything but mp3 playback (and adds FLAC playback) would be the easiest I think.

Edited May 22, 2005 by Breepee2

[toxigenicpoem]

Well if we decide to ditch the firm ware, does anyone know instruction codes for the hardware? I spose we could throw overflow commands to the Hi-MDs microprocessor, and see if it spills back control commands.

Does anyone know what the microprocessor is inside the Hi-MD?

And who gets to be the lucky one to start hacking at thier FirmWare?

[Piggywinkle]

I'm interested in all of this because I lost the ability to play / transfer my collection of 250 CDs to / from my NW-HD1 after changing to a new hard drive.

After lots of playing around, I pretty much gave up on the idea of having access to my collection on the PC so wiped it off but now I have found that, even worse, I cannot add new music to my HD1 without first initialising it!!!!

Can someone tell me which files I need to recover from my old hard drive please either to reconstitute my collection and DRM or at least to enable me to copy new stuff to my HD1 without having to reformat it first?

Sorry to say that the old hard drive isn't bootable, so I can't run the backup tool against it. Also, sorry (ashamed) to say that I have never run the Sony backup program as I had always assumed that if my computer crashed I could simply copy back from the HD-1 !!!!

Cheers for you help.

[toxigenicpoem]

Not bootable, but can you connect the drive, and access the files. i would suspect that you would be able to run the sonicstage on the drive, and run the backup tool that way...?

[fishstyc]

A question for ksandbergfl

Additionally, Sony also puts some procfile-related info in the SonicStage database (look for a file on your PC called MtData.mdb).  Even if you figured out how to copy an OMA file and its related procfile (the easy part), you still would have to update the SonicStage database accordingly (the part I haven't figured out yet).  In short, for an OMA file to be transferred between PC's, SonicStage would have to think that the OMA was generated on that PC.... 

←

Can you explain a bit more what you mean by this?

Does this mean you already added another file to the drm database? What happened? Does it play? If not, what message do you get?

What information is stored in the MtData.mdb according to you? To me (at first sight) it seems only some information about files I have imported is in there (the library - is that what you mean when you say the 'SonicStage database'?).

"SonicStage would have to think that the OMA was generated on that PC", do you have an idea as to what makes SS know a file was generated on that PC? (Firstly probably the first part of the key, which is your PC's personal ID I think, but probably there is more.)

greetz

[jflattich]

Well, I don't know if this helps, but it seems that:

a) there is a session key for each communication with the player,

encryption is DES with ECB or CBC (but it is somehow possible to use no encryption),

c) there are two hidden areas in the recorder which can be read by the software:

-boot-zone

-system-zone,

d) Simple Burner has a debug feature: netmdsb.exe -debug (helps a lot in the debugging process with f.e. ollydbg),

e) if you debug, I would rely on Simple Burner, because it's just simpler

Greetings

jflattich

[tommypeters]

...and now there exists DRM-free OMA anyway...

[Christopher]

d) Simple Burner has a debug feature: netmdsb.exe -debug (helps a lot in the debugging process with f.e. ollydbg),

e) if you debug, I would rely on Simple Burner, because it's just simpler

←

Welcome to the forums. Anyone wish to expand further on this?

[emeb]

Well, I don't know if this helps, but it seems that:

a) there is a session key for each communication with the player,

That makes sense. Probably some sort of Diffie-Hellman exchange to set it up too.

encryption is DES with ECB or CBC (but it is somehow possible to use no encryption),

Wow - how did you nail that one? I've been searching for details on MagicGate for a while without any luck.

d) Simple Burner has a debug feature: netmdsb.exe -debug (helps a lot in the debugging process with f.e. ollydbg),

Also handy to know. How'd you find it?

[hobgoblin]

c) there are two hidden areas in the recorder which can be read by the software:

    -boot-zone

    -system-zone,

←

and i take it that the commands used to read said areas are ecrypted and so cant be reproduced unless its cracked somehow?

for if its cracked then a special program should be able to clone a md, or even allow for a simple file transfer app outside of simpleburner or sonicstage.

im guessing that the boot zone contains a disc specific key thats changed every time you initialize the disc. and the system zone contains a list of keys for the on disc music files.

[jflattich]

Wow - how did you nail that one? I've been searching for details on MagicGate for a while without any luck.

←

Those Sony guys are a bit arrogant - they left all debug-strings in their exes/dlls.

Just disassemble himdpacapi.dll and enjoy the strings.

To debug just use ollydbg with hidedebugger and Simple Burner or Sonicstage don't detect the debugger.

Btw. I just found the ICVs in a OpenMG folder - is there any information about this discovered yet?

[jflattich]

and i take it that the commands used to read said areas are ecrypted and so cant be reproduced unless its cracked somehow?

←

I was able to get the bootzone, but it's somehow disappointing:

It looks like there is only information about the name and the filesystem in it:

00D359D4  E9 00 00 4D 53 57 49 4E  é..MSWIN
00D359DC  34 2E 31 00 08 10 01 00  4.1.....
00D359E4  02 00 02 00 00 F0 1F 00  .....ð..
00D359EC  20 00 40 00 00 00 00 00   .@.....
00D359F4  C7 89 07 00 00 00 29 00  Ç.....).
00D359FC  00 00 00 4E 4F 20 4E 41  ...NO NA
00D35A04  4D 45 20 20 20 20 46 41  ME    FA
00D35A0C  54 31 36 20 20 20        T16

There is a disc id too, but it doesn't change after formatting the disc. F.e.:

01E3FE4C  02 00 00 00 00 00 04 12  ........
01E3FE54  03 03 00 00 00 00 11 82  ........

Perhaps I'll have a look at the system-zone today.

Edited September 2, 2005 by jflattich

[LupinIV]

c) there are two hidden areas in the recorder which can be read by the software:

    -boot-zone

    -system-zone,

←

Maybe that is not the boot zone we are looking for.

That boot zone may be the usual FAT16 Boot sector of any formatted windows filesystem.

We need to understand if there is a hardware locked boot/disk sector/ that is not part of the filesystem, but it is accessed by the himd.

[emeb]

Those Sony guys are a bit arrogant - they left all debug-strings in their exes/dlls.

Just disassemble himdpacapi.dll and enjoy the strings.

←

Oh, that's just lovely! Looking at the overall complexity of SS I figured that they were on their game. Apparently they have blind spots too.

To debug just use ollydbg with hidedebugger and Simple Burner or Sonicstage don't detect the debugger.

Btw. I just found the ICVs in a OpenMG folder - is there any information about this discovered yet?

←

Coolness. I don't know squat about WinXX software hacking (I'm a *nix geek) so it's great to have someone with experience banging on this stuff too. My biggest question is this: during upload of a PCM track from the MD recorder, what is the flow of data and what DLLs are invoked to process it.

Edited September 2, 2005 by emeb

[jflattich]

Maybe that is not the boot zone we are looking for.

That boot zone may be the usual FAT16 Boot sector of any formatted windows filesystem.

We need to understand if there is a hardware locked boot/disk sector/ that is not part of the filesystem, but it is accessed by the himd.

←

You are right: the mentioned boot- & system-zones are entirely for the visible filesystem data. But before the filesystem is mounted, the program makes some checks. Here is a debug snapshot:

[ 2005/09/02 20:06:38 ]  ROM:	0
[ 2005/09/02 20:06:38 ]  MEDIUM TYPE:	umd3
[ 2005/09/02 20:06:38 ]  FORMAT TYPE:	ddt is recorded
[ 2005/09/02 20:06:38 ]  WP	0
[ 2005/09/02 20:06:38 ]  PAGE CODE:	md play mode page
[ 2005/09/02 20:06:38 ]  TABLE NUMBER:	0
[ 2005/09/02 20:06:38 ]  SINGLE:	0
[ 2005/09/02 20:06:38 ]  SHUFFLE:	0
[ 2005/09/02 20:06:38 ]  REPEAT:	0
[ 2005/09/02 20:06:38 ]  START TNO:	0
[ 2005/09/02 20:06:38 ]  END TNO:	0

[ 2005/09/02 20:06:38 ]  get medium unique id
[ 2005/09/02 20:06:38 ]  OBJECT NUMBER:	0
[ 2005/09/02 20:06:38 ]  DISC ID	16 bytes
[ 2005/09/02 20:06:38 ]  mount file system

For me it looks like that the only real hidden information on the disc is the disc id.

So it looks like that the disc id or some combination with the disc id is the key for the encryption (disc id == 16 bytes == 128 Bit -> Triple-DES?)

[emeb]

For me it looks like that the only real hidden information on the disc is the disc id.

So it looks like that the disc id or some combination with the disc id is the key for the encryption (disc id == 16 bytes == 128 Bit -> Triple-DES?)

←

Sounds like a good theory. The disc id is probably combined with the various other keys in the TRKIDX??.HMA file and from that result the actual data blocks in the ATDATA??.HMA file is en/decrypted. So the big questions are:

1) What is the algorithm for computing the en/decryption key from the various media & track keys?

2) What type of encryption is used?

The answers to both of these are buried in the code for those "skilled in the art" to recognise.

[streaml1ne]

My guess would be AES, but I never found any tidbits to support that when I scanned through SS 3.x files.

[hobgoblin]

so are the files decrypted and reencrypted when transferd to or from the computer and if so where is it done?

and if its done by the player, can we fool it into talking to software outside of the sony ones so that we can upload and download files any number of times?

hmm, it would be even better if said software could be run of a md

as in, drop the app onto the md as data, then use the app to up- or down-load to said md

and could someone maybe produce some traffic of a mp3 transfer to the 2. gen units?

and, is it the software or the unit that upholds the uploaded flag on recordings?

as in, does the software check and refuse to accept the data if it have the flag set, or is it the unit that refuse to send a recording that have the uploaded flag set?

sure, this may not be relevant for new recordings with SS 3.2 or whatever the new version is. but from what i understand there are still people out there that have recordings with said flag set.

ok so there is tools available to get around that but it would still be nice to know

Edited September 3, 2005 by hobgoblin

[jflattich]

Sounds like a good theory. The disc id is probably combined with the various other keys in the TRKIDX??.HMA file...

←

Would someone be so kind to provide me with a 00010012.HMA file or a hex output of it? Before a transfer of the atdata-part, sonicstage checks 64 Bit (!) of this file.

Btw. is there any proof that the keys are really in TRKIDX?

and, is it the software or the unit that upholds the uploaded flag on recordings?

The software sends commands to the unit to read/write data, so to circumvent this you would have to crack the software.

My guess would be AES, but I never found any tidbits to support that when I scanned through SS 3.x files.

According to the debug-strings I stick to DES.

->

.data:6C38966C     \tENC FORMAT:\tdes cbc with session key
.data:6C389630      \tENC FORMAT:\tdes ebc with session key                                 

[hobgoblin]

The software sends commands to the unit to read/write data, so to circumvent this you would have to crack the software.

←

or basicly write a replacement.

as in get hold of the right signals to pass on to the hardware to get the transfer going.

the real problem comes from playing back the then uploaded atrac tracks. that is unless one stays with pcm and mp3

[jflattich]

or basicly write a replacement.

as in get hold of the right signals to pass on to the hardware to get the transfer going.

the real problem comes from playing back the then uploaded atrac tracks. that is unless one stays with pcm and mp3

←

Perhaps we can come to an agreement on which problem we should focus first (data transfer or decrypting the data), so that we can solve this specific problem with maximum force (I hope you understand this sentence - it looks a bit not well-formed to me )

[emeb]

so are the files decrypted and reencrypted when transferd to or from the computer and if so where is it done?

and if its done by the player, can we fool it into talking to software outside of the sony ones so that we can upload and download files any number of times?

←

I can categorically confirm that decoding is not done in the player during upload. I've got USB sniffs of an upload session where the track data is clearly visible and identical to that found in the ATDATA??.HMA file - ie it's still encrypted as it travels over USB.

[emeb]

Perhaps we can come to an agreement on which problem we should focus first (data transfer or decrypting the data), so that we can solve this specific problem with maximum force

←

Good point. My guess is that figuring out the data flow during decryption is the first step. That will tell us how much data transfer is required, since some of the data transfer can be done with simple file copies, but other aspects (like reading the media id) will require custom code.

[hobgoblin]

I can categorically confirm that decoding is not done in the player during upload. I've got USB sniffs of an upload session where the track data is clearly visible and identical to that found in the ATDATA??.HMA file - ie it's still encrypted as it travels over USB.

←

so one can then assume that sonicstage is repackaging the data after the transfer?

as i recall some older reports that the files created after a upload are diffrent from the ones on the disc.

hmm, could one trick the atrac codec into playing the uploaded file without requireing a repackage...

but yes, one needs to get the data transfer system working. then atleast one can make reliable backups.

[samplehunter]

I was able to get the bootzone, but it's somehow disappointing:

It looks like there is only information about the name and the filesystem in it:

00D359D4  E9 00 00 4D 53 57 49 4E  é..MSWIN
00D359DC  34 2E 31 00 08 10 01 00  4.1.....
00D359E4  02 00 02 00 00 F0 1F 00  .....ð..
00D359EC  20 00 40 00 00 00 00 00   .@.....
00D359F4  C7 89 07 00 00 00 29 00  Ç.....).
00D359FC  00 00 00 4E 4F 20 4E 41  ...NO NA
00D35A04  4D 45 20 20 20 20 46 41  ME    FA
00D35A0C  54 31 36 20 20 20        T16

how did you get this odd "line numbers" or sectors?

this seems to be the beginning of the visible "partition" of the HiMD.

You can read it just with a disk editor like dskprobe. This is logical sector 0.

Or have you managed to read physical sectors? Then the range 0-00D35D4 would be quite interesting...

[jflattich]

how did you get this odd "line numbers" or sectors?

this seems to be the beginning of the visible "partition" of the HiMD.

You can read it just with a disk editor like dskprobe. This is logical sector 0.

Or have you managed to read physical sectors? Then the range 0-00D35D4 would be quite interesting...

←

That line numbers are in fact the memory addresses in RAM.

I was just checking what the debug string "boot-zone" means and this was the result.

But now we are sure, that the only hidden information is the disc id.

Btw can somebody supply me with his 10****** file from his HiMD-disc?

I think if the information after EKB is the same as the information in my file, then the algorithm used is really the same as described in the patents someone found some time ago.

[jason222]

I've been reading the things you've found out this far, and am pretty impressed.

Well, I've been looking at the software side of things, and have found out a bunch of things. Although I dont have a HiMD myself (I have an older netmd player), I'm interested in 'cracking' the encryption used by OpenMG.

Really, I'm interested in 'fixing' the PC identifier it creates. Basically, so once the patch is applied, all .omg / .oma files it creates from that point forward, on any PC running the patch, have an identical ID (so you could copy a file between PCs / devices and the programs think it's all the same).

Anyway, I'm not into the hardware side of things much, but I've been looking at the software side.

Again, I only have a NetMD device, so the stuff I describe might be different or unrelated, but I think it's pretty close.

I looked at Simple Burner for this experiment.

It seems to start the conversion process by doing some stuff in OmgPcMan.dll. (PC I figured to mean Protected Content)

This is a COM DLL, it handles the conversion and management of data at a very abstract level.

Really, all it does up front is return instances to interfaces in omgconv2.dll.

Ultimately, I traced everything down to Salwrap.dll. This is the core of the encryption technology. It generates all the error messages like the "OpenMG oh my god!!" that we all have seen.

(BTW, that message seems to come up a lot when you tamper with the maclist files, and some of the other files as well)

Also, it seems that those .ocm files perform the actual conversions. However, they aren't valid DLL files as we expect. I'm figuring that they're some sort of packed code that the salwrap.dll unpacks and runs to handle everything.

Basically, if you want to disable the encryption, salwrap.dll is the place to look.

Oh yes: It's the DLL that causes stuff to crash when a debugger is run.

So in short, most of the other DLLs are just COM objects that eventually marshal everything down to that salwrap.dll.

As for the device side of encryption: NetMD (old ones) don't seem to have it, AFAIK. (Well, you can't copy data to PC again).

I have no clue how HiMD transfer-to-PC works, or how the encryption works, other than what I see here.

Just thought I'd share my findings on the software side of things.

[atrain]

jason using sonicstage v3.2 any oma/omgs can be imported without drm, meaning you can treat them as normal files for a back up or whatever. older files will need to be reconverted [you can do it to the same bitrate!] & will also be drm free.

[hobgoblin]

hmm, how about those mp3 wrappers?

[weissi]

Hi guys,

I read this thread and was impressed by your work. Yesterday I've worked on my HiMD with Linux very hard and that are my results:

- I created a document (will be released on http://www.sf.net/projects/himdhack -> Documentation, tomorrow) with the most important knowledge of this thread

- I experimented with ATDATAxx.HMA, my results:

* I'm able to identify the blocks of this file

* I can extract the raw ATRAC3 data for each track, which is the same as in the OMA files (except that ATDATA is organized in blocks, so OMA-data is split in several pars)

* I wrote a litte /bin/bash script which does this (will be released in C)

then I created this HiMD-Hacking Project on sourceforge.net.

AND I HOPE YOU WILL PARTICIPATE. If we all work together, great efforts can be made, I think.

So, if you're interested in participating, please mail me: weissi@tux4u.de

Best regards,

weissi

[Sparky191]

I assume you've all seen this thread http://www.atraclife.com/index.php?showtopic=440 Not immediately relevant to HiMD/MD but might spark some ideas.

Maybe not.

Edited November 24, 2005 by Sparky191

[fishstyc]

Hi guys,

I read this thread and was impressed by your work. Yesterday I've worked on my HiMD with Linux very hard and that are my results:

- I created a document (will be released on http://www.sf.net/projects/himdhack -> Documentation, tomorrow) with the most important knowledge of this thread

- I experimented with ATDATAxx.HMA, my results:

* I'm able to identify the blocks of this file

* I can extract the raw ATRAC3 data for each track, which is the same as in the OMA files (except that ATDATA is organized in blocks, so OMA-data is split in several pars)

* I wrote a litte /bin/bash script which does this (will be released in C)

then I created this HiMD-Hacking Project on sourceforge.net.

AND I HOPE YOU WILL PARTICIPATE. If we all work together, great efforts can be made, I think.

So, if you're interested in participating, please mail me: weissi@tux4u.de

Best regards,

weissi

I will post the last version I made of HiMD-Xtract (0.06b), a winXP commandline program that i think does the same thing you describe here - copying data on himd back to an oma file. Source code is inluded, please read the README file to get it working. So if you wanted to make something similar, looking at this code might help you not to make the same mistakes.

[attachmentid=1184]

The problem that stays though is on the PC side. Uploaded files that are not known in the SS library, cannot be played back, so we should be looking for a hack there. If we could find the decryption algorhythm, we could (i hope) decrypt any encrypted oma file and convert it to an unencrypted version. So I think we should focus on the dlls in sonicstage. It seems like jason222 is looking in the right place.

My personal feeling is that the "anti-debugging code" in ss got stronger and stronger, while older versions can play exactly the same files, so I think we have more chances of success, if we dig into ss 2.0 or 2.3 instead of 3.x.

I tried to OllyDbg a simple program called gplay.exe I used to play an oma file, hoping I could find out where the actual decryption was done, but while playing a file, a lot of threads are used, and I don't really know how to debug that.

Hope this helps you a bit.

HIMD_Xtract_0.06b.zip

[marcnet]

The Sony DLLS call a kernel API function IsDebuggerAttached (or something like that) to query if a debugger is attached. If there is then the DLL will make the program crash. I also know that LoadLibrary and GetProcAddress are used to obtain the address of the IsDebuggerAttached function. This means it wont appear in any of the DLL's function import tables.

There is a project somewhere on the web to patch the kernel DLL of windows so that this function always returns FALSE. It sounds a bit dangerous to me as using non MS patched kernel DLLs could potentially cause security risks / crashes / etc.

PS: Disk extraction is also in HIMDRenderer 0.52 ... Simply select "Scan HI-MD disk" (next to the "find" button) to find the tracks on the HI-MD disc , and select output file type as OMA.

[fishstyc]

You're right. (it's called "IsDebuggerPresent")

I forgot to mention I patched my kernel to get that far of course Such testing should best be done on a test machine, so you can't lose anything important, and you can screw up your ss installation as much as you like... Patching the kernel can be done with a simple hex-editor, I once posted how I did that but then the forums crashed and the post got lost. When I find that method again maybe this weekend I will repost it here , but it's not so hard to find it on the internet.

It's the only way to dig deeper into the inner workings of the secure module, I think. Install Windows and an old SS version and an old libraray backup on a separate partition, make a partition image so you can easily restart if you screw up badly , and there you go

Edited November 28, 2005 by fishstyc