Unlocking [hacking] Hi-MD files.

[sxc]

This is the thread I started on the T Board. I don't see why it's not possible. Anyone have any thoughts? When I have some time, I might start going through the Access database and see what I can find.

http://www.minidisct.com/forum/showthread....&threadid=24359

[dex Otaku]

Repost from T-Board: [sxc's post]

Hacking Uploaded Files 

Now it seems to me that the only thing that is stopping the burning of CDs from uploaded files is the "rights info" for the file. If you right-click a file that has been uploaded, it says "Remaining Audio CD Transfer Count = 0"

Isn't the rights info stored in an Access database at:

C:Documents and SettingsAll UsersApplication DataSony CorporationSonicStagePackages

Therefore, if we were able to identify the fields in the access database that stored the "Remaining Audio CD Transfer Count" and edit it to unlimited, then we would be able to burn the track to CD.

Anyone want to give it a try?

Um. Hey. Wow.

First..

Here we see the key to some of the tags

Here we see another part of the key.

Here are entries from tracks I have uploaded from the Hi-MD. Note that "checkout count" [1146] = 2, despite no checkouts ever havng been made.

Now a competely different view from another part of the rtackinfo db:

Column '102' always has a value of '-1' for uploaded tracks. For mp3's it is usually '0' [though sometimes also -1] and CDs I've ripped with SS2.1 show up here with '3'. I suspect this might be a source id tag.

Column '103' has value '18' from CD-ripped material, value '8' for mp3s, and '1' for tracks uploaded from Hi-MD.

104 = bitrate; 105 = filesize; 106 = tagged track #; 107 is always 0 in my db; 108 looks like a software source tag maybe - it's 6 for anything that originated on the Hi-MD or in SS2.1 and '4097' for anything encoded outside of SS [i had one track that read '4098' which was a 24-bit 96kHz file that SS resampled]

offscreen .. 109 is -1 for SS tracks, 0 for non; 200 is the genre tag; 201 is the artist tag; there are a few obgious ones here including path to file, but the next interesting one is 205, which appears to be the auth# of the encoder used - meaning that SS encoded tracks show up with one #, whereas tracks I've uploaded all show up with a different # - i.e. the player id...

208 is 1 for cd-ripped tracks, 2 for mp3's, and 3 for uploaded tracks - another source id or maybe this is an assumed generation count with uploaded tracks being set outside the range, sort of like uncopyable SCMS? ..

I find it most interesting that this db is completely open [i copied it first to not disturb the original] and unencrypted. And that parts of it include a key file to id what all the tags are. It's like they're begging us to mess with it.

I'll be making sure I have all my uploaded tracks backed up and then I'll be digging into this.

edit: Please note that when I say 'mp3' here I actually mean 'imported track' as any valid [decodable] file brought into SS appears to fit under this, whether .wav or .mp3 [the only two I've imported so far, since I use nothing else]

Ack more edits already: the key actually identifies some of the columns, I hadn't even looked at those two side by side until posting this. d'oh!

edit again: I swear, the last time - a much simpler view. And a promising one...

[Latexxx]

I posted the following also at T-Board.

I got some good results by hacking the database files.

Here is what I did:

I opened database called MtType and then its table t_propertySpec which appears to contain some explanations . It contains the following line.

1160 mbjContent_copyRemain

So I thought that ID 1160 must have something to do with copies.

Next, I opened database MtData which appears to an exact duplicate of files MtData1 - MtData5. It contains table called t_property which contains some properties. I added a line which has 1160 as PropertySpecID, 63 as ObjectId (see t_object table to get an ObjectID for a file), 1 as IntegerValue and 1 as PropertyTypeID (see t_type). Then I added this same line to all MtData files (this is essential).

And the result? Look at it!

If somebody posted me a copy of a MtData file, which contains entries for files which have copying restrictions, I would be more than happy to take a look at the file.

[Latexxx]

My previous post definately proves that it is possible to alter files' DRM properties by editing the database files.

More images: http://www.nic.fi/~lhahne/temp/ss/

[dex Otaku]

good stuff, latexxx.

[jadeclaw]

Well, that looks VERY interesting.

What caught my eye is property 1252, the mediumkey. That makes me think, if this key is transported along with the associated .omg or .oma file, it might be possible to 'merge' and synchronize SonicStage databases, instead of killing one database when importing another one.

Thanks dex & latexxx, now I have to find tools to work on Access2000 databases, those included with my VisualStudio aren't up to the task.

[Latexxx]

Here is an MSN log from a conversation between me and Dex.

Never give out your password or credit card number in an instant message conversation.

 

lhahne says:

good evening

dex_Otaku says:

13:00 here, you must be in europe?

lhahne says:

in Finland

dex_Otaku says:

I'm trying a couple of different methods to see what unlocks what

lhahne says:

t_property table appears to contain interesting things

dex_Otaku says:

I tried changing the 'checkout count' alone to see if it would affect anything negatively and it didn't

lhahne says:

did you change that in all MtData files?

dex_Otaku says:

no, only the base one

lhahne says:

Different MtData files appear to be some kind of backup copies

dex_Otaku says:

yes, mine are all dated differently

lhahne says:

My trick only worked after I had edited all the files.

dex_Otaku says:

ah

dex_Otaku says:

I'm not really well-versed in access actually

lhahne says:

same here

dex_Otaku says:

so what did you do..  just add the propertyid for every objectid?

lhahne says:

I added a new line to t_property tables.

dex_Otaku says:

I'm going to try it with an uploaded track

lhahne says:

ObjectId links the property to the file

dex_Otaku says:

I'm in central Canada, btw

lhahne says:

which city?

dex_Otaku says:

Brandon, Manitoba

dex_Otaku says:

hmm.  I'm trying to use t_object to identify a specific track in t_property

dex_Otaku says:

uploaded tracks in t_property just have id #s in hex

lhahne says:

I don't have any uploaded tracks to play with 

lhahne says:

see http://www.nic.fi/~lhahne/temp/ss/

 

The following message could not be delivered to all recipients:

see http://www.nic.fi/~lhahne/temp/ss/

 

dex_Otaku says:

still there?

lhahne says:

yep

lhahne says:

any progress?

dex_Otaku says:

I only had to update mtdata.mdb for it to work

lhahne says:

great

dex_Otaku says:

however, because the uploaded track was still id'd as uploaded it still says yo can burn no CDs, which is really what is needed

lhahne says:

it appears that changing just MtData.mdb doesn't work here.

dex_Otaku says:

you're using ss2.0 or 2.1?

lhahne says:

2.1

dex_Otaku says:

hm.  same here.

lhahne says:

it may be that SS uses one file today and the next tomorrow etc

dex_Otaku says:

perhaps

dex_Otaku says:

though all the numbered ones here haven't been touched in some time

lhahne says:

do you know what id 109 (=-1 for ripped tracks) is?

dex_Otaku says:

no, there's no clear id for it

lhahne says:

same here

dex_Otaku says:

that's the one I was suspicious of

dex_Otaku says:

it's 0 for imported tracks though

lhahne says:

MtData4 appears to be file

dex_Otaku says:

mine just touched mtdata2 when I closed SS

dex_Otaku says:

it looks like it alternates every time it opens, maybe

lhahne says:

if id 1252 = Medium Key is what I believe it is, Sony has really screwed up

dex_Otaku says:

I'm about to find out actually

lhahne says:

I changed id 109 to 2 in every file and didn't do a thing

dex_Otaku says:

it's worth noting that all uploaded tracks have -no- 1252 tag

lhahne says:

if 1252 = encryption key, then uploaded files could be unencrypted

lhahne says:

my problem is that I only have ripped tracks

dex_Otaku says:

and yes, it alternates db's with every opening.  I just happened to pick the right one the first time by accident

lhahne says:

that's basicly what I thought it does

lhahne says:

BTW, can you transfer Atrac3 132 kbps files to Hi-MD without transcoding?

dex_Otaku says:

no

lhahne says:

Sony says so

dex_Otaku says:

Hi-MD mode tracks only to Hi-MD mode discs, MD mode tracks only to MD mode discs

dex_Otaku says:

mind you, I haven't tried it, but that's how I've understood it so far

lhahne says:

http://www.sony.net/Products/Hi-MD/capacity.html#3

dex_Otaku says:

(censored)

lhahne says:

have you tried ID 1161 SCMS

dex_Otaku says:

not yet

dex_Otaku says:

somehow I doubt it's needed though, it's not on any of the other tracks

lhahne says:

could you send your MtData file?

dex_Otaku says:

sure, hang on

 

The transfer of the file "MtData.mdb" has been blocked because it could be unsafe. Why was this file considered unsafe?

 

lhahne says:

Messenger blocked that. Could send as zip?

lhahne says:

-Could you-

dex_Otaku says:

blocked.. hmm.  yes.

dex_Otaku says:

.rar acceptable?

lhahne says:

yep

 

dex_Otaku would like to send you the file "MtData.rar" (92 Kb). Transfer time is less than 1 minute with a 28.8 modem. Do you want to Accept (Alt+T) or Decline (Alt+D) the invitation?

 

Transfer of file "MtData.rar" from dex_Otaku has been accepted. Starting transfer...

 

You have successfully received E:Documents and SettingsLauriMy DocumentsMy Received FilesMtData.rar from dex_Otaku. Before opening this file, you may want to scan it with a virus-scanning program.

 

dex_Otaku says:

the uploaded tracks are all long hex numbers

lhahne says:

de you have files from connect?

dex_Otaku says:

not a one.  I don't plan to ever use such a service.

dex_Otaku says:

aside from which, I downloaded sonicstage 2.1 and when it figured out I was in Canada it told me that Connect is not available in my region.

lhahne says:

is E:SonicstageHi-MD2004-08-16-01-engine idling.oma uploaded?

dex_Otaku says:

anything in the himd folder is, yes

lhahne says:

i guessed that

lhahne says:

I must go. Is it OK if I'll post this conversation to MD Forums?

dex_Otaku says:

sure.  just crop out the part about my being distracted 

[dex Otaku]

Conclusion thus far:

The file itself carries the tag saying 'no copies.' I have manipulated the database at length [even copying the exact format of an OpenMG PCM file ripped from one of my CDs that I -know- can be burnt] and nothing I have done would change the # of burns available.

If I knew how to crack encryption I would hack the file itself, but alas, such is not one of my specialties.

[Christopher]

I'm splitting this new development into it's own seperate thread. Fantastic work guys, keep it up and keep us informed. :happy:

[dex Otaku]

To note: I officially stand corrected on the issue of whether atrac3 files can be played in Hi-MD mode.

I also tried encoding some songs at 132kbps atrac3 and all I can say is - I can't believe anyone even finds this acceptable for listening in a car. It's unbearable.

[sxc]

So I guess no advance on the unlocking of uploaded files?

[dex Otaku]

I did say the words 'conclusion thus far' and that ended my part in this.

It appears to me that the tracks themselves [on PC] carry their DRM info. The database is merely a reference.

What we need are some people who can hack encryption.

[Latexxx]

Easy hex editing ('compare' function of 010 editor - I couldn't found a free editor which would have had the same functionality) reveals that at least ripped files have some header information even as plain text. Somebody should compare ripped files to uploaded files. If anybody bothers to send a small (max 1 Mb) uploaded file (encryption doesn't matter) to -removed-, I promise to a look at it.

[[StrangeByte]]

It appears to me that the tracks themselves [on PC] carry their DRM info.  The database is merely a reference. 

Yeah. I made similar database experiments with OpenMG Jukebox 1.x some years ago (i think 2000!). The technology is still the same as with MemoryStick Walkman. I had no success, neither.

[laszlo]

Maybe someone sould look at tempering with the firmware for the thing to record MP3 instead of Atrac.

L K