Obok plugin can sometimes use the wrong key for decryption #1718
Comments
|
It would be awesome if there was a fix because I'm having to log out of the Kobo app and do a fresh download of the books every time in order for obok to recognize that the files is actually encrypted. |
|
You're right. It's not difficult to remove this feature. You just have to delete line 378, and 399, and change line 400 to:
Please note that in line 400 you'll have to remove one indent as well, so it'll have the same level of indents as line 396, 397, and 398. However, someone has definitely added these lines here. At first glance it should be fine to remove them, but I wonder why they were put here, does it fix another bug? |
|
It seems this code has a different function. I've just imported 3 Kobo books (I only have 3 encrypted books) from the PC (not the device) with the code, as well as without. What happened is that in both cases the 3 books not only were imported successfully, they were decrypted successfully too. However, without this code, a number of extra tests were performed even though the books were already confirmed to be decrypted successfully. For one book, that happened dozens of times. So it looks like this code is meant to prevent that. Both times all books were successfully imported, and decrypted successfully, but without the code the log file contained 624 line, while with this code, it contained 315 line. So it looks like this code is useful, and I wonder if your issue is caused by something else. |
|
Obok 7.1.0 works for me, but 7.2.1 doesn't. Won't decrypt or import. |
|
@ableeker I think you may have a small misunderstanding of the issue. The way the decryption in the CLI script works is for each possible key it decrypts each file, then for each decrypted file with a recognized mime type it does a sanity check, verifying that it has a correct-looking header. If every one of these sanity checks passes, then it's very likely that the key was the correct one. The way the plugin does it is almost the same, except that it only does a sanity check on the first decrypted file with a recognized mime type. If that check passes, it assumes the key is the correct one and doesn't do any further checks, it just decrypts the remaining files. This works most of the time, but as I discovered it is possible for the stars to align and the wrong key to appear to correctly decrypt that first file (in this case it was the ASCII branch of the check, which is relatively easy to pass as it just needs to have a small number of characters be in the correct range. You can see in my original post that the incorrect key decrypted to gibberish, but enough of that gibberish was in the ASCII range for it to pass the test.) The result is that in some (probably still fairly rare) cases the incorrect key is chosen and the book is imported using that, meaning the imported book is gibberish. The fix will do more work, as you say (you are seeing more lines in the log because each of those additional checks outputs a few lines), but it's not actually that much more work per chapter, and it will vastly decrease the probability of using the wrong key. |
I don't think this is the same issue. My issue imports the book but the book is unreadable because it was decrypted with the wrong key. |
|
@MentalHolyGlobe Good point. I've had a closer look at the code, and I think the person who has introduced this code probably concluded that all these test weren't needed. And that may well be true in most cases, for instance with the Kobo books we've tested the code. But because it introduces an issue, we shouldn't use it. Are the books decrypted successfully with the version I have attached? |
|
@ElleKayEm I've checked again, I've definitely been using Obok plugin 7.2.1, dated April the 11th, and my Kobo books were successfully imported, and decrypted. Was there anything useful in the log file? |
Yes, I can confirm that this version decrypts the problematic book successfully (as well as a small sample of books that already worked previously). |
|
Great! I've submitted pull request #1753 with the fix. |
I'll let you be the judge: calibre Debug log Tried with the version you attached and got the same. Here's a successful log with 7.1.0: Running Obok DeDRM v7.1.0 |
|
@ElleKayEm I see what you mean, so the answer to that would be, "Not really, no... ", it just doesn't find the right key. Is it working with this version? |
|
@ableeker Yes, that works! Whereas regular 7.2.1 only finds 4 possible keys and it doesn't work. 7.1.0 found 12 and it worked. This finds 16. Here's the log: calibre 5.22.1 [64bit] embedded-python: True is64bit: True |
As with the 7.2.1 includes one of my commits that is necessary to have obok work on some machine, but introduces a regression on others; in the current pull list there's a fix for this regression that uses both methods (pre 7.2.1 as standard and post 7.2.1 as fail-over) to retrieve the keys. Can you check if that resolves the issue? |
|
That's most likely what happened here. I had noticed that there has been only one change, this changes the way the plugin tries to find the MAC-address of the PC that's needed as part of the decryption. So my version just reverses this method change, and uses the old method. Both methods work on my PC, but that's not the case with all PC's, as @ElleKayEm has found out. So both methods by themselves will not work on all PC's. But fortunately @journeyman88 has submitted pull request #1691 that solves this problem by trying both methods. I've implemented this fix in this version, is it working? |
|
Yes, that works for me. |
|
Your patch resolved my issue as well. I mentioned my success in your merge request, @ableeker. Thank you! |
I just discovered this issue because there was a book in my library that appeared to successfully decrypt, but when I tried to open it the book was still encrypted gibberish (or I guess technically wrongly decrypted gibberish). I then tried decrypting the same book from the command line with the obok.py script, and it succeeded. Looking at the logs (see below), it was clear that the plugin was finding a key that passed the plaintext check for the first encrypted file, but the CLI ruled that same key out because the next encrypted file check failed.
You can see in the code, the plugin decryption short-circuits the check after the first file passes, while the CLI script checks every file.
At first I assumed the check was short-circuited for performance reasons, but looking at the code it doesn't seem like it's very expensive, it's probably marginal compared to the cost of the actual decryption. So I think the fix is probably just to perform the check on every encrypted file, just like the CLI script.
Relevant logs from plugin:
Relevant logs from CLI (starting from the same key the plugin settled on, you can see how the very next test fails):
The text was updated successfully, but these errors were encountered: