where is registered device info stored

[grr]

Specifically, where are each of my PID's stored?

I know that if i image my hard drive and restore it on a different computer, PID is preserved. (ie, not linked to cpu serial # or other hardware)

short of that, is it stored in registry, some encrypted cfg file, etc?

Basically want to know how to reinstall same pid if my hard drive crashes (and the prc files i downloaded are not mobidedrm-able

[pilotbob]

Originally Posted by grr

Basically want to know how to reinstall same pid if my hard drive crashes (and the prc files i downloaded are not mobidedrm-able

I think the PID is calculated based on attributes of the PC rather than stored anywhere.

Even if you PID does change due to a system change... you can go to the ebook store, change your PID id and redownload the ebooks.

BOb

[grr]

Originally Posted by pilotbob

I think the PID is calculated based on attributes of the PC rather than stored anywhere.

Even if you PID does change due to a system change... you can go to the ebook store, change your PID id and redownload the ebooks.

BOb

Actually, insofar as you can add PID's for other devices/old computers, it can't just be calculated from hardware -- I was able to readd my kindle and my old desktop.

other problem is that some ebook sellers don't allow redownload w/diff PID, go out of business, restrict number of re-dls etc (this isn't typically an issue -- tho i did have 3 _new_ hard drive head crashes in the last 6 months, including dropping my laptop from ~6 feet above a hard surface).

I tried installing/adding the mobi software, and then importing kindle device PID in a sandbox/virtual machine -- there might be registry changes that might be falsely relevant.

Other than that, it seems like

c:\tmp\tmp_sandbox\USERNAMEXXX\DefaultBox\user\cur rent\Application
Data\Mobipocket

contains the following files:
MBP_global_configuration.mbp
mobibook.mbl
mobireader.xml
sync.xml
MobipocketCache.mbp

The first chunk of mobireader.xml seems like it contains the relevant info in plaintext (after interpreting the XML)-- tho it could just be a nonvital copy of an encrypted PID stored elsewhere on the computer:

Note that I snip/modify my actual info below

DEVICE1(Windows)
PC
[my mobipocket ID]
USERNAME Snipped
C:\Documents and Settings\USERNAME XXX\Application Data\Mobipocket\setup\img\pc.jpg
x86
Microsoft Windows



1
1
0
1
1
0
0
0
0
0
NaN

0

0
0


Device2(Windows)
PC

0
[my 2nd mobipocket ID]
USERNAME Snipped
C:\Documents and Settings\USERNAME XXX\Application Data\Mobipocket\setup\img\pc.jpg
x86
Microsoft Windows
DesktopPC


1
1
0
1
1
0
0
0
0
0
NaN

0
0


Amazon Kindle
Amazon Kindle
[Amazon kindle PID snipped]

C:\Documents and Settings\USERNAMEXXX\Application Data\Mobipocket\setup\img\default.jpg
ARM
Amazon Kindle
Amazon Kindle
Amazon.com
[kindle serial number snipped]
1
1
0
1
1
0
0
0
0
0
Sat Oct 4 21:02:43 UTC 2008

I could test this by manually modifying the PID info in the file, and seeing if mobipocket software reflects the change, and so on

[grr]

per correction from user: wallcraft, recognition of kindle PID and storage as an additional device is insufficient -- what I really need to do is restore the original PID from the instance of mobireader that was installed on my original hard drive.

Note that the hardware-generated PID hypothesis still seems less likely, or is at least not the ony variable.

As an experiment, I tried running a copy of mobireader in a sandbox, after editing the mobireader.XML file in a naive fashion (eg, replacing each instance of my "new PID" w/ "old PID")

This resulted in the generation of yet another PID (the 3rd) -- I'm assuming that the integrity of the xml file was violated (through some checksum test, or whatever, stored in another file), and thus, mobireader created a new PID for what it thought was a new machine.

If I restored the old, correct xml file and reran a sandboxed instance of reader, it did not create a new PID

By looking at the sandboxed files that were accessed by the sandboxed instance of mobireader, I think i can conclude that the key files are stored somewhere in the files mentioned above:
MBP_global_configuration.mbp
mobibook.mbl
mobireader.xml
sync.xml
MobipocketCache.mbp
...or else in the registry.

I'm a rank amateur when it comes to actual programming, etc -- hoping someone else can contribute something better informed.

Going back to the original issue -- I have a crashed hard drive which I lack an image of (but do have relatively extensive backups of data and settings files for). How do I

1.Restore the original PID as the primary device on my new hard drive install

2.Going forward, back up the original PID so that it can be restored to a hard drive install as the primary PID

For #2, the "definitely works" instance is to image your entire primary drive partition and the partition on which mobireader is installed, if that is a different partition.

I previously wondered if a hacky, but less involved solution might be to create a tiny drive partition that contains just the install of mobi reader, and image/restore that image.

This seems unlikely to be sufficient given the fact that a combo of registry changes and C:\Documents and Settings\USERXXX\Application Data\Mobipocket\ files are needed (again, not sure of registry changes -- I just can't rule it out w/my current lack of sophistication)

However, I wonder if simply copying files in C:\Documents and Settings\USERXXX\Application Data\Mobipocket\ would be sufficient -- this is something I could test more easily (and plan to do next).

[grr]

The above approach (dump in old application data files) seems to fail (for any of a number of reasons):

1.Registry changes also matter

2.I backed up the app data files on my old hard drive, but failed to recall the version of mobi reader I was using -- maybe I need to use the correct version of mobi reader as well on my new install. [This is less trivial than it sounds -- there have been a large number of builds of each of 6.0, 6.1, and 6.2 -- OTOH, the version number may be buried in the one of the files in my mobireader "application data" backup]

3.Unlikely, but maybe I'm misusing the sandbox application (Sandboxie) -- and there are additional data files that are being changed (in addition to "app data" files and registry. [This is unlikely because of straightforward interface of Sandboxie -- _not_ because I think I'm a power user of it.]

4.Some other factor that I'm overlooking (constrained by the following -- that if I restore a hard drive image to a new physical drive, then I'm able to keep the old PID as primary)

[pilotbob]

Originally Posted by grr

4.Some other factor that I'm overlooking (constrained by the following -- that if I restore a hard drive image to a new physical drive, then I'm able to keep the old PID as primary)

Interesting. What if you restore the image to a VM? Does that change the PID? What if you restore the image to a different PC?

I always assumed that it did some type of hash of identifying factors of the hard ware... like CPU serial number, or hard drive ID.. things that were pretty unlikely to change.

The reason I say this is because if it were possible to just set the PID in a config file somewhere... someone would have figured this out and it would entirely defeat the DRM. You would just need to supply the PID and your ebook to your buddy and he would be able to read it.

Of course it could store the PID somewhere and use DPAPI to store it in the register. This would mean you couldn't find the PID just by searching for it in the registry since it would be obfuscated. Also, DPAPI is for Windows only. So, it doesn't seem right that they would use this since it couldn't be used on a linux device (as far as I know.)

BOb

[grr]

A.As stated above, I've personally taken my old hard drive image and restored it to a new hard drive on a new computer, and verified that PID was preserved.

I should add the following caveat -- the new hard drive was exactly the same model/manufacturer/size/etc as the old one, and the new computer was exactly the same model as the old one (I have a lot of old Dell Latitude X300 laptops, though one fewer ever since I dropped my last one). So, I can verify that the mobipocket PID isn't generated from the truly unique set of hardware IDs (CPU serial, hard drive serial, etc, like windows genuine advantage), there could be some less "unique" hardware check. (no reason to think this, of course)

Also, I've seen 2nd hand references to this more generally being the case (but can't vouch for them w/the same level of confidence).

B.

The reason I say this is because if it were possible to just set the PID in a config file somewhere... someone would have figured this out and it would entirely defeat the DRM. You would just need to supply the PID and your ebook to your buddy and he would be able to read it.

Of course it could store the PID somewhere and use DPAPI to store it in the register. This would mean you couldn't find the PID just by searching for it in the registry since it would be obfuscated. Also, DPAPI is for Windows only. So, it doesn't seem right that they would use this since it couldn't be used on a linux device (as far as I know.)

There are intermediate levels of difficulty here as well.

Setting aside the fact that ereader DRM has been defeated, this is how ereader worked -- provide name and credit card # (really, only the last 8 digits), and anyone could decode your DRM copied ebook. [Presumably, one would be more loath to provide CC info than a PID to one's friends, but still... one could redownload the files with a defunct CC # as the decryption key, some 14 year old script kiddy might steal a CC #, buy lots of ebooks w/it, and then redistribute ebooks with said CC #, etc...]

I didn't expect my naive, "change the plaintext instance of PID" to work -- that being said, there might be any number of relatively secure methods (in the sense that the average mobi user w/avg level of technical expertise would have no idea how to circumvent them) well short of "unique hash generated from hardware ID's" -- and such schemes would be much less difficult to restore.

Finally, being able to reproduce PID's is logically equivalent to DRM circumvention (though not entirely -- for instance, one would be able to read other people's ebooks w/their cooperation, but not be able to convert a still DRMd ebook to html/print out the book, etc). However, the normal focus of reverse engineering efforts would be upon decrypting individual files and unlocking them completely (which I realize has already been done) -- not restore an old PID in order to read a book (and then having to change the PID every time one wanted to read one's old books)

C.

Interesting. What if you restore the image to a VM? Does that change the PID? What if you restore the image to a different PC?

Not sure -- I'm logical, somewhat tech-savvy, and can hackily program in perl, but these qualifications are nowhere near sufficient for being a real programmer/reverse engineer. Thus, my tools have been those that are relatively user friendly -- like using Sandboxie rather than a full blown, fully configurable VM.

Restoring the image to a diff PC has already been tried (per above).

I might try taking an ISO image and mounting it on a different computer (to rule out the intermediate hardware uniqueness scenario mentioned above).

[pilotbob]

grr,

Thanks for the information. I am curious as to how they are doing this... not enough though to work on it myself. However, I await any more info that you find out.

I guess my bottom line question would be, wouldn't it be easier to just remove the DRM from all your mobi files rather than figure out this PID issue? As you say, it is fairly easy to do that at this point, given you know one of the PIDs the ebook was protected with.

BOb

[grr]

no worries -- yes, I'm familiar w/mobidedrm, and have removed the DRM from the most recently purchased mobipocket formatted books that i bought for the old device (aka precrash hard drive). Thus, this has become an exercise in curiousity (and stubbornness), since I (whenever possible) buy my ebooks in ereader format (so I can convert to html and read on my laptop). I just find it annoying that I can't preserve my old mobipocket ID post-head crash.

I guess by restoring the old PID, I could also avoid having to hack together a perl script to mass convert the 10-20 mobipocket formatted ebooks that I bought less recently -- but that would take literally only a few minutes.

The only other hypothetical issue (which is totally a border case) is that I could have checked out some library books prior to head crash w/the old mobi PID (these expiring mobipocket books cannot be dedrm'd to the best of my knowledge), and not been allowed to redownload them w/the new PID, unless I had remaining checkout slots. (Afaik, there's no "return ebook before expiry date" option for library books in order to open up checkout slots.)

My amateurish hackery time is probably better spent on learning to use wget to redownload all of my ereader.com books (which I never fully backed up, on the assumption that I could always re-download off the site) -- there, the issue is that I can't easily view clean download links, as I click "download" buttons to redl the files.

[igorsk]

The computer PID is calculated from hard drive serial ("Volume Serial Number" in dir listings). Kindle's PID is calculated from Kindle's serial. Other devices also generally calculate PID from some kind of per-device serial.

[pilotbob]

Originally Posted by igorsk

The computer PID is calculated from hard drive serial ("Volume Serial Number" in dir listings). Kindle's PID is calculated from Kindle's serial. Other devices also generally calculate PID from some kind of per-device serial.

Interesting... thanks. Here is a way to change the S/N if someone wants to prove this out.

http://www.codeproject.com/KB/system..._drive_sn.aspx

BOb