Mp3 Storage Format Reverse-Engineered On Sony NW-S

[Webmaster]

MP3 storage format reverse-engineered on Sony NW-S23 Network Walkman: Waider has figured out the MP3 file obfuscation algorithm on Sony's NW-S23 Network Walkman. He's reverse-engineered the obfuscation sufficiently that he can read and write files from the device. Is there similar hope for MP3 files on Hi-MD media?

http://www.livejournal.com/users/waider/415461.html

[Michael1980]

So he basically made the drag and drop possible?

[Webmaster]

He made non-SonicStage MP3 transfer possible. To do true drag and drop you'd need to add some kind of MP3 obfuscater/de-obfuscater as a layer of filesystem code between the OS and the device.

So he basically made the drag and drop possible?

←

[The_Stamp]

nice! so if a program was developed, all we would have to do is keep the program on the device, and simply run it whenever we want to put mp3's on there!

[bug80]

It would be very interesting to see if something similar can be done with Hi-MD. It would not only mean we can bypass SonicStage when transferring MP3's, but it would also mean Mac and Linux support is possible. Am I right?

[Christopher]

Possibly, yes. Time to get MarcNet out of the woodwork..

[Embio]

*cough* be nice for ATRAC also.....

[The_Stamp]

the atrac would be too hard. not only you would need to decypher the encryption, but you would have to hack any SS that uses it or make an atrac player. i dont think anyone out of sony knows how the decoding works =/

[JD24]

the atrac would be too hard.  not only you would need to decypher the encryption, but you would have to hack any SS that uses it or make an atrac player.  i dont think anyone out of sony knows how the decoding works =/

←

Woahh! That would be awesome!

[Andy]

You could implement drag and drop via a shell extension. This would mean that it would work on any computer with the shell extension on it.

Hopefully, Sony uses a similar scheme for their Hi-MDs, but there is no guarantee.

It really does show you that something is wrong when your own device is obfuscating your own files to prevent you from reading them.

[Breepee2]

You could implement drag and drop via a shell extension.

The sweet thing is you can implement it any way you want on any computer you running any OS you want. If it's compatible with HiMD and someone build a linux driver, then I'll know what to do.

[hobgoblin]

the atrac would be too hard.  not only you would need to decypher the encryption, but you would have to hack any SS that uses it or make an atrac player.  i dont think anyone out of sony knows how the decoding works =/

←

yes, its realy sonicstage thats the problem with atrac files as its the only program that can play them.

still, i wonder what they are doing with the pcm files. if they are doing something similar then atleast mp3 and pcm transfers should be teoreticaly doable outside of sonicstage. and with 128-bit mp3 recording for stuff that dont need high quality and pcm for the rest you dont realy need atrac unless your using it to get some extra recordingtime out of your md's...

[Ryzir]

There is a program for the Vaio Pocket and NW HDD series called Vaio Transfer Utility that allows Drag and Drop mp3 and atrac transfers. I wonder if this could be adapted for Hi-Md?

I have the NW-Hd1 and this utility works great. You can even drag WMA Lossless or Wav onto it and it will convert to atrac of your choosing on the fly.

[Andy]

The sweet thing is you can implement it any way you want on any computer you running any OS you want. If it's compatible with HiMD and someone build a linux driver, then I'll know what to do.

←

Just to nitpick, the driver is already available for every operating system and no one would rewrite that. This is talking about a level of abstraction above the driver, so you would need to write a shell extension for whatever shell you are planning to use the device in (e.g. Explorer, KDE, Gnome, Bash etc).

But yes, this is good news.

[zerodB]

Just to nitpick, the driver is already available for every operating system and no one would rewrite that. This is talking about a level of abstraction above the driver, so you would need to write a shell extension for whatever shell you are planning to use the device in (e.g. Explorer, KDE, Gnome, Bash etc).

←

I imagine some clever programmer could write an extension for Windows using the Shell Namespace object in order to facilitate drag & drop in Explorer. Wouldn't be too dificult to do based on what has been discovered I imagine, though I don't know terribly much about such things myself.

EDIT: Just thought about it... something similar to the GMail Drive shell extension.

Edited April 14, 2005 by zerodB

[Andy]

I imagine some clever programmer could write an extension for Windows using the Shell Namespace object in order to facilitate drag & drop in Explorer. Wouldn't be too dificult to do based on what has been discovered I imagine, though I don't know terribly much about such things myself.

EDIT: Just thought about it... something similar to the GMail Drive shell extension.

←

Yes, this is what I am saying. However, this is not the same as a driver. For example, if you open the command prompt (Start->Run, type "cmd"), then you won't be able to just copy things across like you normally would from the command prompt and have them work.

To interface with a device, usually, the chain looks something like this:

Device -> Driver -> Shell -> User

With SonicStage however, the chain is longer:

Device -> Driver -> Shell -> SonicStage -> User

With a shell extension:

Device -> Driver -> Shell -> User

Now, there are a lot of shells around (not so many for windows), but by writing a shell extension, it is specific to a certain shell - so you won't be able to use it from the command prompt.

If you had a new driver which managed to do the obfuscation/deobfuscation, then the chain would look identical:

Device -> Driver -> Shell -> User

But, it would work for every shell which is available (for the operating system the driver works for).

However, writing such a driver would be quite difficult (since is would break lots of things having file copying work differently to expected) and not worth the time.

What we could always hope for (unlikely, knowing sony) is a different device, such that:

Device -> Driver -> Shell -> User

Will work because the *device* just works. i.e. the driver is identical to the old one, you can drag and drop any files, and the shell doesn't need any extensions. But the device has some logic in it which says: "If you see an mp3 file, then allow it to be played back".

Summary

A shell extension will fix most of the problem, but not all, and it still requires far more work than if Sony were to just make hardware that didn't restrict its user.

That was a pretty poor explanation, and it isn't actually explaining much so don't worry too much about it.

[Breepee2]

I was trying to say that The driver is done, how you(r software) interface(s) with it, is besides the piont.

[zerodB]

Well at the moment, it's all speculation, at least as far as Hi-MDs are concerned. We don't even know if the file storage mechanisms are the same for Hi-MD. Though I don't see any reason to believe that Sony wouldn't have employed something similar in their 2nd gen Hi-MDs

[Tjerk]

This is just work around for the mp3filemanger, or atleast that's how I see it. So this will work for walkmans wich use the mp3filemanger. But the newer walkmans, like the NW-HD3 and the new HiMD units, use sonicstage not only to put atrac on it but also MP3 files. This means that on this new units thestorage format is completly different. So I wouldn't count on it that this is going to work for the new HiMD units, at least the mp3filemanger doesn't work on it.

[MAVickers]

I imagine some clever programmer could write an extension for Windows using the Shell Namespace object in order to facilitate drag & drop in Explorer. Wouldn't be too dificult to do based on what has been discovered I imagine, though I don't know terribly much about such things myself.

EDIT: Just thought about it... something similar to the GMail Drive shell extension.

←

An intriguing idea. I don't have one of the newer units, so I don't know how MP3's are arranged in the tree structure compared to OMG, but there may be a couple of considerations for drag and drop functionality - how to create the groups, how to order the MP3's in the various groups, etc.

[hobgoblin]

any news on this in combo with the latest hi-md units? it would be ncie to know that one dont need sonicstage to dump mp3s onto it

[MDfreak]

any news on this in combo with the latest hi-md units? it would be ncie to know that one dont need sonicstage to dump mp3s onto it

←

While the NW flash-players have stored their mp3's in separate *.dat files, on the second generation Hi-MD's mp3's are incorporated in the HMA-file that is also used for ATRAC3(plus) audio so the whole filesystems are diffent and mp3-filemanager will therefor not work on Hi-MD's.

[hobgoblin]

hmm, so basicly they are using the same wrapper for both the atrac and the mp3 files?