|
Ok Ken, let me go into all the details for why I have reached the conclusion that my credit card is no longer involved in encrypting the books on my account. I welcome you or any one else to poke holes in my conclusion. I would really love to be wrong about this.
I looked at 5 copies of the same book each downloaded when a different credit card was the default. I used the Tampermonkey script for each download. I signed out of my B&N account and exited my browser after each credit card change to make sure I was getting a fresh copy.
Copy #1 was downloaded when credit card #1 was the default.
Copy #2 was downloaded when I switched the default to cc#2 which was already on my account.
Both of these can be unlocked with my name (first last) and their respective cc number. Both of the credit cards have my name with the middle initial.
Copy #3 was downloaded after I added cc#3 with a completely different name and made it the default.
Copy #4 was downloaded after I switched back to cc#2.
Copy #5 was downloaded after I switched back to cc#1.
These last 3 copies will not unlock with any variation of my name, the cc name, or any combo that I could come up with.
I then took each copy of the book, changed its file extension from epub to zip, unzipped it, and compared the files inside there which handle the encryption (mainly a file called rights.xml). Copies 1, 2, and 3 are different from each other. Copies 3, 4, and 5 are identical.
Therefore, since the encryption previously changed when I changed my default credit and now it does not, I can only conclude that my credit card number is no longer involved. It may still use my B&N account name as one of the seeds to create the hash since that hasn't changed. But I can't see how it still uses the credit card number.
|