Nudge me in the right direction..? by wolupgm6 at 1:06 AM EDT on June 29, 2010
Alright, here's the situation. Megadeth's album "Rust In Peace" has been released for Rockband DLC. I managed to track down the DLC update online, but I have no intention of using it with Rockband. I merely wish to decrypt the moggs (multi-track ogg files) within it. After many hours of sampling around with numerous programs such as Arktools and RawkSD, I still have nothing. And then I stumbled upon something online. Someone had one of the vocal tracks. It had no distortion or such (from which you'd expect from a center-panned audio isolation method), and sounded exactly like the original. As far as things are considered, this means that it was taken from the mogg. Google has failed me, so I ask the elite here to help nudge me in the right direction, or to try the decryption process themselves. Link to the DLC update torrent will be provided, but due to legal reasons, only upon request.
Hmm. Thats about it. Hope I didnt forget anything, and thanks in advance.
The following search term in google will bring up the DLC update. Dont know if that'll help anyone or not, and didnt want to directly link to it, just in case.
the encryption you speak of is very complex & such only one person has managed to unscramble it "publicly" that is. there are at the moment 6 different encryptions.
"0A" is the decrypted version from any of the below
Format 01 - 0B (Rock Band / DLC) Format 02 - 0C (Rock Band / DLC) Format 03 - 0D (Rock Band / DLC) Format 04 - 0E (Rock Band / DLC) Format 05 - 0F (Rock Band / Network / Lego / DLC) Format 06 - 10 (Rock Band Beatles)
The "0A/0B..." is the first two bytes of the ".mogg" file so if you ever want to know which encryption they contain, just open them in any hex editor & check the first two bytes.
At the time of Rock Band 2 when they introduced a new encryption, they also scrambled up the file once decrypted so not only do you need the correct key, but you also need to work out how it rearranges the file into it's original form even after being decrypted with the key.
Probably not very helpful information but i've followed the rhythm game's for awhile so i know what i'm talking about, i ain't techy or anything but trust me, i've tried my fair share at this one too & it ain't happening anytime soon i'm afraid.
If anyone has any pointers, i'd be very grateful too & if you have any questions regarding particular parts of this game, let me know, i've studied it for a long time :)
The "rust in peace" track is type 0E. I tried some modifications to SongCrypt (which I finally found here) to handle what I thought was the issue, but I've had no luck.
If someone wants to send me binaries I could take a look, though I doubt I'll have much luck as I'm sure better minds than mine have been at it.
one mogg for each of the encrypted revisions, & ArkTool v6.1 With Source.rar, & ArkTool v7.0
@hcs, when you say you didn't have much luck, could it possibly be down to the scrambling rather than the key? the songcrypt from arktool 6.1 doesn't handle any type of the scrambling, only the version for arktool 7.0 but there's no source provided for that :(
Very interesting, I'll see if I can: a) port the descrambling from v7 into the v6.1 source we have (for 0C only) b) figure out what needs to be changed for 0E
I noticed that the actual decryption function will accept 0D as well as 0C, but it does the same thing. The initial check for file type, however, only accepts 0C. Also, the 0D file you sent (closer.mogg) was actually an 0C so I don't have a way to check that one.
edited 2:17 PM EDT September 4, 2010
Hmm, this whole thing is kind of a mess. I do see where the key calculation comes from, and the other three types. This is something that 0C and up do in addition to the scrambling, which I haven't pinned down in the xex yet. There's a table loaded in SongCrypt that doesn't seem to come directly from the code, so it may be something that was captured from RAM or precalculated. And there's a whole lot of confusing hardcoded gyrations after that. Gonna rest on this a bit.
my bad, i must have checked the other's & assumed that was "0D" without checking it, although it's been driving me mad for the past hour trying to find one with "0D", i can't see one that exists...
I checked the DLC & going by the release schedule at http://en.wikipedia.org/wiki/Complete_list_of_downloadable_songs_for_the_Rock_Band_series
i checked loads of them but it would appear "0E" begins from the song "Space Truckin'" (Dec. 30, 2008) & the last file with "0C" is a week before "DOA" (Dec. 23, 2008) & i checked the RB2 Disc for the 360 too, & there all "0C" so for some reason "0D" doesn't actually exist which is strange, i wonder if they did have "0D" planned but because it may have been too similar to "0C" they scrapped it & went straight to "0D" instead & may have even more structures added to it, hmm, definitely keep us informed if you notice anything, i never ever noticed there was no "0D" ever!
balls by balls at 10:12 PM EDT on September 17, 2010
I've opened up a variety of RB2 DLCs from different dates and they've all been 0E, from stuff as early as sept 09 to just the other week. Placedo, is this one person you speak of the one who did the GNR album?
I read on some forums that the underground communities that had the tracks and were keeping them only within their group wanted to release them after RB3 was released in attempt to make Hmx think that they didn't need to change the encryption of RB3. There are a few DLCs that I'd love to have separated, I'd even go through the process of doing the dta modification method to get each track if I had an xbox...
Anyone else noticed the odd KIBE header, before the BIK one? (when working with the Wii's BIK files, this is) I think it also appears on the mogg files.
Not sure how much help that will be. Its a decrypted version of "Chinese Democracy". Not sure what generation its from, I think the third. I'm not all that great when it comes to this stuff, but would it be possible to make some sort of comparison between the "encrypted" and this one, and work from there...?
Yeah, those were the first unencrypted moggs of the new generation I believe. I thought originally that if we know what the unencrypted version will exactly look like, someone could write a bruteforce script that would attempt to figure out what gets you from A to B, but I'm not sure that's possible.
it doesn't work like that, it's AES encryption & the point of AES is even if you have a decrypted & encrypted file, & compare the two, there is no way or being able to use any of that information to find the original key, that's the point of AES & why people are using it more & more
by arbingordon at 2:38 PM EST on November 23, 2010
And you're sure of that? You're sure that AES cannot be bruteforced? Or are you just saying that one cannot derive the key by nominally comparing the two files to "find" the key that way? (in which case, that is not what Blosk was saying, so read his post again until you understand what he said)
Brute force on AES is 2^128 (or 192 or 256 for those key sizes). As far as I know (not being a cryptographic expert) there is no known plaintext attack on it that is any better, so having the full plaintext isn't helpful.
@arbingordon, to answer the original question brute force is possible on AES (it's possible on anything given the time!), but realistically you're looking at maybe hundred's (maybe more) year's of waiting for it to throw something back at you, & that's with a few computer's constantly looking & assuming you don't have anything like Power Cuts down the line, so brute force is not really the way to go at this moment.
One could make the argument that trying all key-sized strings in the entire ISO would be completely feasible, but I am certain that they would not simply store the key in plain sight.
No truly effective cryptographic attack exists. Only attack that would be successful is if you find a flaw in the implementation of AES in the host product.
it seems to me that Chinese Democracy provided here wasn't actually decrypted but instead created via xbox track isolation method re-record (so it should have some dec->enc conversion flaws). I judge by it's structure: it doesnt contain 0A header, it has different libvorbis version (much newer one) and it has some typical tags (ARTIST, etc) - RB2 moggs don't have them.
But i found another post-jan2009 mogg that may be decrypted honestly: Guns n Roses prostitute.mogg. Structure very same to that in regular RB2 files, it has 0A header and even "Xiph.Org libVorbis I 20050304" substring. I can send it to email if anyone needs.
to date it's the only one i cold found, but it gives hope that decryption at least possible. I tried to search for a guy who did this but failed =(
brute-force is not an option really, the only way to me is to go reverse engineering game code to look how goes the decryption process, or maybe some luck guessing it
btw what about PS, Wii versions? theirs DLCs also encrypted the same way? actually i wasn't able to find them =)
I'm assuming that the member balls is either a spam bot, or just another retard who wakes up at 9 in the morning to necropost in random topics, using male body parts as one-liners.
Currently in the works for my copy of the forum; a way to pull the IP addresses of specific members from the forum's database & create an HTACCESS file to ban them.
hcs; would you actually implement this on your site if I created this?
As far as the KIBE files go, that's actually an extra header slapped onto the bik file, which has some decryption info in it. Unlike the moggs, they only encrypt the bink audio/video frame data, not the bink header. Also, unlike the moggs, the bink audio uses an XTEA block cipher instead of an AES one, I guess because the Wii would have been slowed down too much by having to do AES every 16 bytes. The bink is not "big-endianified" or anything silly like that.
The mogg/bik files used in the Beatles game use a completely different encryption, something called Cloakware Whitebox drm by Irdeto. For the bink files, they only use the Cloakware on the first 16 bytes of every 8kb chunk of data, since it is so slow. The rest of the data just uses a simple LCG to generate an xor stream. For the mogg files, however, the Cloakware is pretty deeply integrated into the code, it looks like they even modified the libogg/libvorbis libraries to include the DRM there
by LadiesMan217 at 3:46 PM EST on December 13, 2016
Any updates on this? I have 3 moggs that use Format 06 - 10 that I'd love to be able to use.
I have been poking around the SELF executable on Rock Band 3 for PS3, I have seen that the PPU Thread named Bink Audio gets called whenever a song is 'loading' in the game.
PM me @ps3hax if you want the debug EBOOT for the game, we could work something out by dumping the RAM after the .mogg is loaded and decrypted by the Bink Audio Thread in the PPU.
Could you release an update to SongCrypt for the newer 0x10 or 0x0F Encryption?
Why hasn't anything real been released in years? I was hoping for a mod menu or something to be released that you could dump the mogg from or something. Why do Warez groups fear HMX more than any other dev?
I think there hasn't been anything released in years because the only person who had both the skills needed and the desire to do so got a Cease and Desist letter pretty quickly. Everyone else who could reverse-engineer things just wasn't interested in Rock Band, and everyone else who was interested in it did not have the reverse-engineering skills required.
Not only that, but it also seems that the majority of people were complacent about just getting the "analog hole" recorded multitracks.
And then of course there's the fact that HMX is just an indie studio, and if anyone wants Rock Band to continue to exist, it's wise to not be releasing decryption tools, because that just makes it harder for them to continue to support the series with new DLC, etc. Imagine if they were released between 2013 and 2015 - we probably wouldn't have a Rock Band 4 at all.
I am looking to at least get a tool to decrypt up to 0x10 Encryption, I'd love to get a ton of songs that have the 0x0E encryption type.
A wild 0x11 appears! by maxton at 3:06 AM EDT on October 16, 2017
Looks like they've gone and made a new revision to the file format for DropMix, so now we're up to 0x11. If you ask me, we should be up to 0x12 by now since we have two different 0x10s, but meh...
so... by Half Mile Ride at 3:58 AM EST on December 12, 2017
Why would they revise it if not even 0C has been cracked?
I see that this subject interests you as much as me at this moment. Obviously, nothing really crisp to find on Google. But it seems that moggs up to RB4 are already decrypted. So, there are methods that are direct or indirect for that.