Adventures in discovering the K4PC PID.

[delphidb96]

Anyone done this yet? Anyone want to detail their experiences so far?

Perhaps if we detail this in this thread we can finally make the breakthrough we want.

Derek

[clarknova]

What good is the 'pid'? The book key isn't encrypted in the same way as normal mobi books in k4pc books. Who knows if a mobiPID is even used anymore in the new key encryption. This is fairly obvious if you look at the DRM sections from two different books.

[delphidb96]

Originally Posted by clarknova

What good is the 'pid'? The book key isn't encrypted in the same way as normal mobi books in k4pc books. Who knows if a mobiPID is even used anymore in the new key encryption. This is fairly obvious if you look at the DRM sections from two different books.

Maybe, maybe not. I agree that an .azw1 (Topaz) format Kindle ebook is different, but what about the .azw (Mobi) formatted Kindle ebooks? From a quick scan of the two that are currently resident on my PC, the .azw ebook looks exactly like a standard .mobi ebook.

Derek

[wallcraft]

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.

[delphidb96]

Originally Posted by wallcraft

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

[scancode]

For version 1.0.25338.0 (MD5 348F25D496FBDDF2CE4A9CE0C2A7E1ED) deregister K4PC, set a breakpoint at offset 005B2A59, register again, and look at the stack

0012C144 01A13110 ASCII "https://firs-ta-g7g.amazon.com/FirsProxy/registerDevice?deviceType=AXXXXXXXXXXXXS&deviceSer ialNumber=PXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX3 &deviceName=%25FIRST_NAME%25's%20Kindle%20for%20PC %25DUPE_STRATEGY_2ND%25&pid=NXXXXXXK"
Note that the PID is 8 chars long.
MobiDeDRM failed at decrypting after removing the checkum check.

[wallcraft]

Originally Posted by delphidb96

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.)

I agree that the Kindle 1/2/DX and iPhone AZW files are standard MOBI files with standard PID processing, which I outlined above. The question is how are the K4PC AZW files different (if at all)?

Something I did not make explicit in my description above is that MOBI allows up to 4 PIDs per ebook, i.e. has "slots" for 4 PIDs in the file structure, but Amazon only uses 1 PID per ebook. In other words each AZW file will only work on one device.

[wallcraft]

Originally Posted by scancode

0012C144 01A13110 ASCII "https://firs-ta-g7g.amazon.com/FirsProxy/registerDevice?deviceType=AXXXXXXXXXXXXS&deviceSer ialNumber=PXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX3 &deviceName=%25FIRST_NAME%25's%20Kindle%20for%20PC %25DUPE_STRATEGY_2ND%25&pid=NXXXXXXK"

Is the PID what you get by running kindlepid on the deviceSerialNumber? It is clearly being generated on the PC, hopefully from some local unique id.

[clarknova]

Originally Posted by wallcraft

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.

About 7 days on 1 core of a 2.0ghz processor. This would be faster if you know the PID is a Kindle/Mobi pid (Which ends in either $ or * and limits the combinations to 105046700288) However for a Kindle 4 PC or iPod these increase to 1785793904896 combinations. I got lucky and it only took me about a day to brute force my Kindle 4 PC pid.

Originally Posted by delphidb96

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.

That's all irrelevant. If you'd just LOOK at the DRM sections you would see. If you open up any book from a Kindle, you'll look a the DRM section and notice that the "00 00 00 43" has been encrypted (16 bytes later) into the same string on EVERY book for that kindle.
Now if you look at books for your Kindle 4 PC, you'll see that "00 00 00 43" is encrypted DIFFERENTLY on every* book. This means they've introduced an IV into the book key encryption method.

* - So how did I brute force my PID when the encryption's changed? Because when I first installed K4PC I downloaded one book out of my library. It came across with the old encryption. Every book since has had the new encryption, and the only way I can readily tell which encryption method the book will use is by that EXTH 208 record (you know the one: "atv:kin:1:{base64 data}:{base64 data}" ). If that record has a length of 0xC7, then the book seems to use the old (normal) book key encryption. If the length is 0xDB, then it's the new method.

[scancode]

Originally Posted by wallcraft

Is the PID what you get by running kindlepid on the deviceSerialNumber? It is clearly being generated on the PC, hopefully from some local unique id.

The deviceSerialNumber looks nothing as any other kindle S/N i've ever seen before.

FWIW, I found that the PID actually IS used to decrypt books (only tried on www.amazon.com/gp/product/B002ENBM7G , prc format)

[delphidb96]

Originally Posted by scancode

The deviceSerialNumber looks nothing as any other kindle S/N i've ever seen before.

FWIW, I found that the PID actually IS used to decrypt books (only tried on www.amazon.com/gp/product/B002ENBM7G , prc format)

But does it (the deviceSerialNumber) work in KindleFix to generate a valid PID? That's what I'm unclear on.

Derek

[clarknova]

Originally Posted by scancode

The deviceSerialNumber looks nothing as any other kindle S/N i've ever seen before.

What he's saying is to run that through kindlepid.py (you'll have to modify the code to treat it like an iPod device number) then see if it matches the PID.

Originally Posted by scancode

FWIW, I found that the PID actually IS used to decrypt books (only tried on www.amazon.com/gp/product/B002ENBM7G , prc format)

Again, you either 1) got lucky or 2) downloaded that book within the first day or so of Kindle for PC being released.

Now, why don't you try newly downloading a free book (like http://www.amazon.com/gp/product/B000FBJBA4) and see how far that PID gets you. Once that fails, you could also try deleting that book you listed before, re-downloading and seeing if it still comes down with the old encryption method.

[scancode]

Originally Posted by clarknova

What he's saying is to run that through kindlepid.py (you'll have to modify the code to treat it like an iPod device number) then see if it matches the PID.

> iPhone serial number (UDID) detected
> Mobipocked PID for iPhone serial# {SERIAL} is S*1*S*H*AT

The PID that's sent to the server (and used in decryption AFAICT is N*I*7*F* [calc checksum: VZ])

They do NOT match

[delphidb96]

Originally Posted by scancode

> iPhone serial number (UDID) detected
> Mobipocked PID for iPhone serial# {SERIAL} is S*1*S*H*AT

The PID that's sent to the server (and used in decryption AFAICT is N*I*7*F* [calc checksum: VZ])

They do NOT match

Neither of those look like the serial number *I* got by following the instructions to generate my PID using the k*fix python script. When I extracted my UDID/Serial info from iTunes (my iPod Touch was connected), I got a standard-length Mobipocket-style PID.

Derek

[daffy4u]

Originally Posted by delphidb96

Neither of those look like the serial number *I* got by following the instructions to generate my PID using the k*fix python script. When I extracted my UDID/Serial info from iTunes (my iPod Touch was connected), I got a standard-length Mobipocket-style PID.

Derek

You mean you used the Kindlepid script not Kindlefix for your PID, right?