sxc Posted August 22, 2004 Report Share Posted August 22, 2004 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 Quote Link to comment Share on other sites More sharing options...
dex Otaku Posted August 22, 2004 Report Share Posted August 22, 2004 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... Quote Link to comment Share on other sites More sharing options...
Latexxx Posted August 22, 2004 Report Share Posted August 22, 2004 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. Quote Link to comment Share on other sites More sharing options...
Latexxx Posted August 22, 2004 Report Share Posted August 22, 2004 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/ Quote Link to comment Share on other sites More sharing options...
dex Otaku Posted August 22, 2004 Report Share Posted August 22, 2004 good stuff, latexxx. Quote Link to comment Share on other sites More sharing options...
jadeclaw Posted August 22, 2004 Report Share Posted August 22, 2004 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. Quote Link to comment Share on other sites More sharing options...
Latexxx Posted August 22, 2004 Report Share Posted August 22, 2004 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 Quote Link to comment Share on other sites More sharing options...
dex Otaku Posted August 22, 2004 Report Share Posted August 22, 2004 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. Quote Link to comment Share on other sites More sharing options...
Christopher Posted August 22, 2004 Report Share Posted August 22, 2004 I'm splitting this new development into it's own seperate thread. Fantastic work guys, keep it up and keep us informed. :happy: Quote Link to comment Share on other sites More sharing options...
dex Otaku Posted August 22, 2004 Report Share Posted August 22, 2004 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. Quote Link to comment Share on other sites More sharing options...
sxc Posted August 24, 2004 Author Report Share Posted August 24, 2004 So I guess no advance on the unlocking of uploaded files? Quote Link to comment Share on other sites More sharing options...
dex Otaku Posted August 24, 2004 Report Share Posted August 24, 2004 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. Quote Link to comment Share on other sites More sharing options...
Latexxx Posted August 24, 2004 Report Share Posted August 24, 2004 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. Quote Link to comment Share on other sites More sharing options...
[StrangeByte] Posted September 6, 2004 Report Share Posted September 6, 2004 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. Quote Link to comment Share on other sites More sharing options...
laszlo Posted September 30, 2004 Report Share Posted September 30, 2004 Maybe someone sould look at tempering with the firmware for the thing to record MP3 instead of Atrac. L K Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.