View Single Post
Old 11-27-2009, 02:20 AM   #5
delphidb96
Wizard
delphidb96 ought to be getting tired of karma fortunes by now.delphidb96 ought to be getting tired of karma fortunes by now.delphidb96 ought to be getting tired of karma fortunes by now.delphidb96 ought to be getting tired of karma fortunes by now.delphidb96 ought to be getting tired of karma fortunes by now.delphidb96 ought to be getting tired of karma fortunes by now.delphidb96 ought to be getting tired of karma fortunes by now.delphidb96 ought to be getting tired of karma fortunes by now.delphidb96 ought to be getting tired of karma fortunes by now.delphidb96 ought to be getting tired of karma fortunes by now.delphidb96 ought to be getting tired of karma fortunes by now.
 
Posts: 2,999
Karma: 300001
Join Date: Jan 2007
Location: Citrus Heights, California
Device: TWO Kindle 2s, one each Bookeen Cybook Gen3, Sony PRS-500, Axim X51V
Quote:
Originally Posted by wallcraft View Post
Perhaps it is worth summarizing what happens in a normal MOBI ebook. Here is what I think happens, but I am nor certain this is right and I am skipping over some technical details.

The actual encryption is done before the ebook leaves the publisher, with a (book specific) key. Only a small part of this file is then customized for the 1-4 PIDs allowed in a delivered MOBI ebook. The customization encodes an encrypted marker of the PID and the book key in the file, and this can then be extracted by entering the PID (e.g. by a MobiPocket Reader or by mobidedrm). So the process is PID -> book key -> plain text.

The K4PC AZW files are largely the same as AZWs for other devices, in other words the book key and the basic encryption is the same. What clarknova is suggesting is that Amazon has changed the PID -> book key process. This is plausible, because Amazon only needs 1 PID per file (not 4) and in principle they could do anything that used the same basic structure as the standard MOBI file. If this is the case, then this would be disappointing because MobiPocket never designed the PID to be a secret. Since it is only 8 characters long, with 36 values per character, it is in principle discoverable using a Brute force attack. In effect the PID is a password, subject to Password cracking. I don't know how long it would take to crack the PID from a MOBI file, but this seems practical even using brute force and there might be faster ways. This is a complete waste of effort for standard PIDs, because we already know them. Even the "secret" PIDs of Kindles and the Kindle iPhone app were discovered by other techniques, not relying of cracking the PID from a MOBI file. Since we don't know the PID of K4PC, cracking might be appropriate - but only if we know that K4PC is actually using a conventional MOBI PID.

Note that most DRM schemes are not broken by brute force or other attacks on the cipher, but rather on some flaw in the system that allows discovering the PID (or whatever). This "flaw" has to be there because DRM is being asked to do the impossible. The reader app is in the possession of the "attacker" and it has to know how to decrypt the ebook.
Except that the .azw files are directly de-DRMable using MobiDeDrm. (Presuming you've retrieved your iPod/iPhone/Kindle serial number and run it through a script to generate the PID.) In order to make that work with a single non-standard key that is NOT a mobi-format PID would mean that either a) the PID one generates from an iPhone/Kindle is somehow hashed with all the other Kindle-specific PIDs one has (six in my case, 2 iPod Touches, 3 PCs and one Kindle), and mind you, I've downloaded some of my purchases *BEFORE* owning K4PC and they are just as de-drmable using the current iPod PIDs as they were before, or b) that ain't how it works. Remember, my copy of MobiDeDRM does NOT have special "Amazon" de-drming modules - I'm actually running v0.04.

Derek
delphidb96 is offline   Reply With Quote