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