Several people have pointed me to the news that claims of cracking AACS (the content protection system protecting both Blu-Ray and HD-DVD discs) have been leveled. Here is a doom9 thread on the matter. My first reaction was, “What took so long?” Conceptually, it should have been pretty straightforward to understand the entire system and recover secret keys since technical documents on the matter are quite openly available. I always considered that rather odd since a large part of DRM’s efficacy hinges on obscurity.

Good news, nonetheless, if it’s accurate.

While babysitting the tedious resurrection processes of a number of Gentoo machines on life support, I took some time to put my money where my hypotheses were regarding the recently unearthed V.Disc multimedia formats. I lost. But you might be interested to see what I came up with anyway.

Read the rest of this entry »

I finally got around to prying open that V.Flash V.Disc cartridge. All it required was a screwdriver acting as a chisel, a hammer, and a blood sacrifice (technical veterans will recognize that last item as a mainstay of computer repair methodology). I have to give VTech proper credit for the strength of the cartridges. Sega could have learned something from VTech when they manufactured their flimsy, oversized Sega CD and Sega Saturn jewel cases. Anyway, it is confirmed: The V.Disc is a simple CD-ROM.

The particular title I have, The Amazing Spider-Man: Countdown To Doom, contains around 313 MB of data. The largest directories on the disc are labeled kw01/, kw02/, and kw03/. They contain combinations of files bearing the extensions .mjp, .ptx, and .snd. I strongly suspect that these are Motion JPEG, raw picture, and pure audio files, respectively. Various other directories on the disc also contain .mjp files with ‘cutscene’ in the filenames.

The .mjp files begin with a MIAV signature and draw influence from the AVI format in that media chunks are denoted variously by ’00dc’, ’01wb’, and ’02wb’ FourCCs. The chunk format is FourCC – chunk number within stream – chunk length – payload. The 00dc chunks contain what resemble JPEG chunks. But something seems off about them. My first clue is a FourCC ‘FJFI’. Then it comes into focus– it’s byteswapped JPEG data (the usual signature here is ‘JFIF’). In fact, the first chunk begins with the bytes 0xD8 0xFF 0xE0 0xFF– byteswapped from the standard marker bytes 0xFF 0xD8 0xFF 0xE0. The 01wb and 02wb streams, I would guess, represent 2 separate audio tracks. Perhaps this disc can be played in 2 different languages? Or perhaps there is a director’s commentary track? I think I like my first hypothesis better. I didn’t see anything on the box or cartridge to indicate that the game has more than one language. But it could be that the same media is marketed in a different region with different printed materials. If that were true, it would indicate that the game could query the region of the V.Flash to know which language it should present to the player.

I am not sure what format the audio data takes. It could be low-volume, 16-bit, little endian PCM (mono or stereo), it could be 8-bit stereo PCM that’s dominant only on one channel, or it could be some other unusual encoding. The .snd files might provide a little more insight. The .snd files turn out to be straight-up WAV files.

The .ptx files are all 262188 bytes, which is (44 + 2¹⁸) bytes, so I suspect that these files have a 44-byte header followed by 2¹⁸ bytes of raw image data. The first byte in the file is 0x2C = 44, so that’s a good validation sign. I’m trying to decide what the dimensions and color resolution could possibly be. The square root of 2¹⁸ = 2⁹ = 512. A 512×512 image would not make sense for a television screen. But that would assume 8-bit palettized data anyway. However, if the data was 15- or 16-bit RGB, then the image might be 512×256 which is plausible. The header encodes the number 480, which is a common image height, but does not divide evenly into 2¹⁸. Plus, there is no sane parameter encoded in the area around 480 to indicate height, so I have to assume that 480 is a coincidence. Hey, Robert and Reynaldo: is that RGB recovery utility ready yet?

For program code, the disc contains a file called 0system/boot.bin. I think Ian Farquhar called it when he speculated that the V.Flash uses an ARM processor. Running ‘strings’ on this binary reveals “MORE v4.0 SDK ARM9T version”. The binary format itself I am unfamiliar with, but it is a chunked FourCC format that contains such FourCCs as ‘BOOT’, ‘REL\0′, and ‘DBG\0′. A clue regarding the toolchain, however: “GNU AS 2.13″. The string “OggSRIFFdV” also shows up.

Update: Here are some samples of the .mjp and .ptx files (the .snd files are just straight PCM WAV files).

This is, hands-down, the most interesting math book I have ever read:

Who Is Fourier?

Over the course of 13 chapters, the book manages to progress from “1 + 1 = 2″ (in fact, you can read that particular page through Amazon’s “Look Inside” facility) through fundamentals of calculus differentiation and integration (without ever using the word ‘calculus’, at least, not that I noticed), and eventually teaches the reader how to perform a fast Fourier transform (FFT) by hand on paper. All of this is done using fairly small words, humorous illustrations, and curious storytelling. Since the FFT is so widely used in audio and video compression technology, consider this book if you don’t quite understand how the transform operates. And refer to it again everytime your knowledge lapses and you forget how the transform works.

The book is published by an entity known as the Transnational College of Lex. I realized from their Amazon listing that they also have books teaching about DNA and quantum mechanics. If I had interest in either of those areas, I imagine these would be fantastic books for getting started on the subjects.

I journeyed to the bookstore today in search of an O’Reilly pocket-sized Python reference, in an effort to tip the balance toward the positive in my newfound love/hate relationship with the Python programming language. I found what I was after, and on prominent display. I had not perused the computer book aisle in quite some time so I took a moment to look around. Every current and trendy computer language and development fad was well-represented, including a few of which I was previously unaware. That’s when it dawned on me how hard it is to find a simple book on the C programming language in these sections.

Maybe C just isn’t good for selling books.

This episode reminded me of the difference I observed long ago about the differences in computer book selections at bookstores vs. academic libraries vs. public libraries. A bookstore will stock thick, vastly expensive tomes covering whatever the latest hot computing fad or language happens to be (wait for the fad to blow over and in 6 months the book will be less than $10 on the clearance table). Rewind 10 years to 1996 when Java was taking off in a big way. I think the local Barnes & Noble shop had an entire section devoted to the language. And I seem to remember that every one of the books was essentially the same: A few chapters discussing the basics of the language, with the remaining 4/5 of the book devoted to a verbatim reprint of the official Java language and API reference that was freely available online.

An academic library, such as the one found at your local technical university, will stock a few of the fad books about specialized skills but will feature far more texts on fundamental and advanced computer science theory (think “general theory of fishing” vs. “learn bass fishing in 3 days!”). A community public library, in my experience, will have a decent mix of both types of books.

I finally got something semi-useful accomplished on the Hachoir project: A RealMedia (.rm) file parser. Here is a screenshot of the hachoir-urwid frontend (one of several frontends available for the project):

I have long held an interest in thoroughly and usefully documenting the rm format which has always struck me as one of the most ad-hoc multimedia formats available, at least in terms of the support available in open source programs. I was eager to write this parser to help me study the format and write down all of the things that are present in various open source demuxers but are currently missing from any public documentation (that I am aware of). The parser I have written so far is the easy stuff; I want to move on to documenting that type-specific data field highlighted in the screenshot, which is the really interesting and useful part of the format.

But hey, if you would like to help, the code is now in the Hachoir Subversion repository.

So the Free Software Foundation has launched badvista.org, ostensibly a clearinghouse for informing computer consumers just how harmful Microsoft’s impending Windows Vista is for their digital and online health. To be honest, I haven’t really examined the literature too thoroughly, mostly because I just don’t personally care about Vista (“Yadda yadda, Microsoft bad, proprietary software implicitly wrong and evil, ad nauseum”). Though it did finally get me to thinking about the multimedia-related implications of the new OS upgrade. Per my reading, there will be no new actual multimedia container formats, video codecs, or audio codecs. But there are supposed to be layers upon layers of new DRM and associated rules encapsulating the existing formats and determining where/when/how a user can consume a particular piece of media.

Strange, but with my experiences using Linux over the last year, and particularly in the last week, I could set up a similar site about various shortcomings of Linux (as if that hasn’t been done to death already). But I notice that badlinux.org does not appear to be taken as of this writing.

Sometimes, while using the the Xv hardware YUV interface with xine, the program briefly displays the ghost of some other image momentarily as it creates a new video window. Typically, the ghost depicts images that were recently shown in my Firefox web browser. So memory isn’t zeroed out somewhere along the line. That all makes sense.

What puzzles me is something I saw last week: I was working in Linux, rebooted into Windows and worked for a little while, then rebooted back into Linux. When I started xine, I saw an image that I had previously brought up in my web browser before I had rebooted into Windows. That image had staying power.

I realized that, though all of this, I had never actually cut power to the machine, only did warm reboots. Thus, I suspect the data was left over in an area of video RAM that Windows never had occasion to touch.

You crossed the line this time, Gentoo. I stuck with you through the tough times, even through this humiliation. But when you specifically tell me to do something that renders my computer completely useless, that warrants a big, sloppy, kiss of death. I might be able to recover from this latest disaster but why should I have to put up with it?

The only question that remains is whether there is another Linux distribution that supports x86_64 as well as Gentoo. Maybe I should just run in a pure 32-bit mode. Stuff is better supported for x86_32 anyway.

Pursuant to yesterday’s Real Linkage experiment, I decided to repeat the same experiment only using the regular inverse transform as opposed to the one for handling the optimized case of only a non-zero DC coefficient. Thankfully, the results were exactly the same as the DC-only I-transform when the general I-transform is fed a DC-only matrix. A little guru told me that the 169 constant (a.k.a. 13²) is also a characteristic of the SVQ3 I-transform. I would like to run some sample vectors through both transforms to see if they arrive at the same output. But I am not sure how to instrument the SVQ3 4×4 I-transform to print before and after data sets.

So, still working on that. Then deciding where else to take this project afterwards.