Kindle for PC is there

[ekaser]

Originally Posted by Hellmark

Found a file of some interest at C:\Documents & Settings\usernamegoeshere\Local Settings\Application Data\Amazon\Kindle For PC\{AMAwzsaPaaZAzmZzZQzgZCAkZ3AjA_AY}\kindle.info

The bracketed folder is obviously randomly generated, and the file contains a 10kb string of similarly seemingly random generated characters. My guess, the PID is in there.

Yes, I found that file, too. The folder is NOT randomly generated, or if it is, the seed is always the same, because that's the exact folder name on at least two other systems, too. That's the only place I've seen that would be a likely place for the PID to be stored, but 10KB is a big area to look for an encrypted 10-byte string, especially when it's probably encrypted with fairly strong encryption. I suspect it would take some kind of "end run" to acquire the PID, such as is used to get the key for LIT files. The CONTENTS of the kindle.info file is certainly different on different machines (users), although very similar, mostly alpha characters with occasional punctuation characters thrown in.

The only characters used in the two examples I've seen are 0-9, A-Z, a-z, and hyphen, colon, underscore, and open-brace. Interestingly, there are exactly 10 open-braces and exactly 10 colons in both files AND they're all in EXACTLY the same locations in both files. A further impossible-to-be-coincidence, is the addresses (offsets into the file) at which they occur. The offsets are not consistent, but when looked at as hex values, the least significant digit increments by 2 EVERY TIME. In hex, the offsets of the '{' characters are:
0000
01E2
04F4
0686
0828
124A
13FC
160E
24B0
2652

The offsets for the ':' characters are:
0021
0203
0515
06A7
0849
126B
141D
162F
24D1
2673

Notice that the '{' offsets start with their least significant digit at 0 and that digit increments by 2 each time, while the ':' offsets start with a least significant digit of 1 and increment by 2 each time. But those 20 characters are at the exact same places in both instances of the file that I've studied.

Whether it has any bearing on anything, who knows (not enough data points, so it may be pure coincidence) but there's 10 {'s and 10 :'s in each file, at the exact same locations, and there are 10 characters in a MobiPocket PID. Very possibly coincidence, but then maybe not, too.

Another interesting curiousity: The file is, by FAR, mostly A's, Z's, a's, and z's. In kindle.info #1, there are:
1815 A's
1152 a's
1753 Z's
1299 z's
In kindle.info #2, there are:
1777 A's
1153 a's
1764 Z's
1343 z's

Those four characters account for around 60% of the file. The other 60 characters (24 uppercase, 24 lowercase, hyphen and underscore) each have a "random scattering" of between about 50 and 130 instances each.

And that's about all the time I have to spare to spend on the issue. But maybe some of this will mean something to someone else, or be of help.

[ekaser]

Originally Posted by slayda

Below is a file of the three contiguous sections of the hex values that were different;

I could recreate the output that would include the hex addresses if necessary.

Yes, please? That would be quite useful. Thanks!

EDIT: by the way, I just looked at your file closely, and realized that the two middle lines are identical. Grabbed one of them from the wrong file???

[llreader]

Originally Posted by ekaser

Whether it has any bearing on anything, who knows (not enough data points, so it may be pure coincidence) but there's 10 {'s and 10 :'s in each file, at the exact same locations, and there are 10 characters in a MobiPocket PID. Very possibly coincidence, but then maybe not, too.

Could the segments between the { and : be an encrypted digit of the PID?

[ekaser]

Originally Posted by llreader

Could the segments between the { and : be an encrypted digit of the PID?

Very possibly. I forgot to point out in last night's post that, if you subtract the '{' and ':' characters, which appear to always be at the same points in the file, then that leaves exactly 64 other characters (26 upper, 26 lower, 0 to 9, hyphen and underscore), which would lead one to believe that the file is an ASCII encoding of some sort, where each character represents 6 bits (0-63) of the "value".

Also, a week ago when Kindle for PC was first released and I'd first installed it, I did a directory listing of my entire hard disk (redirecting it to a file), then sorted that file by date and time, to see what folders and/or files had been created or modified with the same time-stamp as the Kindle for PC installation. I found that a file was created in a sub-folder of:

C:\Users\(username)\AppData\Roaming\Microsoft\Prot ect

(The 'Protect' folder is a hidden folder, so you have to do a /ah directory search to find it, or CD directly to it, knowing the path.) Another "made up name" folder existed in that, within which was a half-dozen files, all with made-up names (apparently 'random' digits and letters), all of the same length (the names) and the same file length (the data) of 388 bytes. Upon searching the web for info about this, I found this page that talks about the Protect folder and DPAPI (Data Protection Applications Programming Interface):
http://technet.microsoft.com/en-us/l...8WS.10%29.aspx
Anyway, the most recent of those 388 byte files was created with the exact same time/date stamp as the Kindle for PC installation, and the Preferred file in that same folder had also been modified with the same time/date stamp.

So, I suspect that Kindle for PC is using the Windows Data Protection API to encode and scramble the Kindle PID and store it in the kindle.info file. But I don't have any experience with the DPAPI layer, and know even less , so figured I would leave it to other more cryptographically-minded folks to puzzle it out.

[pilotbob]

Originally Posted by ekaser

So, I suspect that Kindle for PC is using the Windows Data Protection API to encode and scramble the Kindle PID and store it in the kindle.info file. But I don't have any experience with the DPAPI layer, and know even less , so figured I would leave it to other more cryptographically-minded folks to puzzle it out.

Using DAPI is pretty easy to do, especially with .Net. The think about DAPI is that you don't need to know the key (iirc) since the encryption is based on the currently logged in user of the PC.

BOb

[slayda]

Attachment 39407

Originally Posted by ekaser

Yes, please? That would be quite useful. Thanks!

EDIT: by the way, I just looked at your file closely, and realized that the two middle lines are identical. Grabbed one of them from the wrong file???

Apparently I did use the wrong file.

Here is the output. I've added spaces where there is a break (unless I missed one) in the addresses. File also attached.

EDIT; After rereading the posts above re. the ":" I looked at both files again with that in mind and have modified the attached file.

[Alexander Turcic]

Please keep in mind our guidelines in regard to posting sensitive information in regard to DRM. Basically don't post anything that could be used as a step by step guide to break DRM, don't post proprietary code or disassemblies, and don't attach any tools that coud be related the breaking of such code. Thank you!

This is merely a friendly reminder.

[Hellmark]

Alex, as a techie who deals with DRM'ed files for a living, and responsible for a community of geeks and hackers, I'm fairly well abreast of legal matters regarding this, and so far all is kosher.

[ekaser]

Originally Posted by slayda

EDIT; After rereading the posts above re. the ":" I looked at both files again with that in mind and have modified the attached file.

Yes, I've just been looking at the two .PRC files I've downloaded from Amazon, and found a similar block in both (at different addresses than in yours), that seem to use ':' and '=' as delimiters of data blocks. In both books, there's a block that looks like this:

:kin:1
COLON(171 random alphanumeric characters plus '/' and '+' characters)=
COLON(27 random alphanumeric characters)=

The 171 and 27 blocks of characters are different in the two books, but they're the same LENGTH in both books and preceded by ":kin:1", and the two books both have the 171 and 27 character blocks bracketed by a colon/equals pair.

I just did a check on your latest diff file, and lo and behold: the address of the =: pair in your file is 0xC0C, and the address of the starting : is 0xB61.
0xC0C - 0xB61 = 0xAB, which in decimal is (are you ready?) 171. The trailing '=' is at 0xC29 and the first character after the =: pair is at 0xC0E. That equals a difference of (are you ready again?) 27 bytes. In other words, the same 'size' and arrangement as the blocks that I found in my two files. The third block of different data that you found appears to be BINARY data, not ASCII encoded, and LOOKS like it is probably 24 bytes long (or very close thereto). On the two books I have, it is at a different offset from the above data block, because there is book title and publisher information in between the two. But the 24-byte block (or however long it is) appears to follow shortly after the ASCII string "EBOK".

These blocks seem to be a similar encoding to what's in the kindle.info file, except that they use : and = as the delimiting characters and / and + as the two characters that fill out the 64 character "data set", whereas kindle.info uses { and : as the delimiting characters, and - and _ as the 64-character set filler.

I've done a little more playing around with kindle.info, and it is structured thusly (on my system):

{(32 chars)
COLON(448 chars)
{(32 chars)
COLON(752 chars)
{(32 chars)
COLON(368 chars)
{(32 chars)
COLON(384 chars)
{(32 chars)
COLON(2560 chars)
{(32 chars)
COLON(400 chars)
{(32 chars)
COLON(496 chars)
{(32 chars)
COLON(3712 chars)
{(32 chars)
COLON(384 chars)
{(32 chars)
COLON(400 chars)

I've added CR's to break things into understandable units. Notice that the : and { characters are paired in an alternating pattern, and each { is always followed by exactly 32 characters, while each : is followed by a varying number of characters. This leads one to believe that the { is specifying a "variable name" (or "value name"), and each : is specifying the value associated with that name. Interestingly, the first 200 characters of each "data" block are IDENTICAL. The only variation exists AFTER the first 200 characters (the 200 doesn't count the leading ':').

The theory that the characters in the kindle.info file comprise data that has been encoded into ASCII, with each character representing 6 bits of the data is somewhat supported by the fact that if you multiply the number of characters in each field by 6 and divide by 8, it always comes out to an equal number of bytes. Further, the number of 'bytes' (if that's what it translates to) is always a multiple of 4. In other words:

32*6/8 = 24
448*6/8 = 336
752*6/8 = 564
368*6/8 = 276
384*6/8 = 288
2560*6/8 = 1920
400*6/8 = 300
496*6/8 = 372
3712*6/8 = 2784
384*6/8 = 288
400*6/8 = 300

That's all for now. I REALLY do have "real work" I have to be doing. (But puzzles are just SO darn much fun! )

[ekaser]

Originally Posted by Alexander Turcic

Please keep in mind our guidelines in regard to posting sensitive information in regard to DRM. Basically don't post anything that could be used as a step by step guide to break DRM, don't post proprietary code or disassemblies, and don't attach any tools that coud be related the breaking of such code. Thank you!

This is merely a friendly reminder.

Thanks, Alex! Absolutely. I'm just enjoying the 'puzzle' of it at this point. Were I ever to actually "break through" to DRM breaking territory (which I doubt I'll ever do, I just don't have the where-with-all for that anymore), I certainly wouldn't post anything "in the public eye."

[slayda]

Originally Posted by ekaser

Thanks, Alex! Absolutely. I'm just enjoying the 'puzzle' of it at this point. Were I ever to actually "break through" to DRM breaking territory (which I doubt I'll ever do, I just don't have the where-with-all for that anymore), I certainly wouldn't post anything "in the public eye."

I agree completely except that I am retired and barring "honey-dos", I don't have any "real work". Puzzles are very interesting and entertaining. I just wish I were smart & educated enough to solve this.

Originally Posted by ekaser

Yes, I've just been looking at the two .PRC files I've downloaded from Amazon, and found a similar block in both (at different addresses than in yours), that seem to use ':' and '=' as delimiters of data blocks. In both books, there's a block that looks like this:

Yes, I noticed the same thing in another book.

[volwrath]

The way I see it, this is round 3 for Amazon, with the Kindle and IPhone being rounds one and two. I imagine that Amazon is going to make it extremely tough to determine the pid, because if/when it is found, it will be all over. Although I suspect if this were the case Amazon would sell more books.

[llreader]

Originally Posted by volwrath

The way I see it, this is round 3 for Amazon, with the Kindle and IPhone being rounds one and two. I imagine that Amazon is going to make it extremely tough to determine the pid, because if/when it is found, it will be all over. Although I suspect if this were the case Amazon would sell more books.

EXACTLY! They would sell more books. I would buy from them, and I have a Sony. The open question is whether Amazon thinks they can really force their closed standard on the market and win, or whether they are making a "good faith" effort in order to satisfy the publishers.

The first seems delusional, but companies have done it before. The second seems likely, even if the first is also true. Pricing is a whole different issue (like selling ebooks for more than the hardcover version ).

[4-eyes]

Originally Posted by volwrath

The way I see it, this is round 3 for Amazon, with the Kindle and IPhone being rounds one and two. I imagine that Amazon is going to make it extremely tough to determine the pid, because if/when it is found, it will be all over. Although I suspect if this were the case Amazon would sell more books.

If it should prove possible to determine the PID and then apply a suitable python script to allow me to convert to ePub format for my Sony as I do with mobipocket format, they'll certainly be selling a lot of books to me.


No PID, however, means no sales to me.

[Sweetpea]

Originally Posted by 4-eyes

If it should prove possible to determine the PID and then apply a suitable python script to allow me to convert to ePub format for my Sony as I do with mobipocket format, they'll certainly be selling a lot of books to me.


No PID, however, means no sales to me.

For me, it would either be a PID or a WinMobile application... (the latter would have my preference, as I could read topaz file then as well)