[FileType Plugin] ACSM input plugin

[Leseratte_10]

Yeah, the main error from this log is "E_LIC_ALREADY_FULFILLED_BY_ANOTHER_USER", which means that the ACSM has already been opened by another Adobe account. Probably your app that started automatically is linked to a different AdobeID than the Calibre plugin, and so it was unable to download the book again.

[patrik]

Yes, I followed your tip and created a new adobe-id.

Which probably also did that even though the book got fetched, I can't open it. I'm guessing the adobe-credentials in Calibre are for my other adobe-id. (It's been quite some time since I installed v5 portable to test so I don't remember what I did or didn't do.)

Guess I give up and remove the new adobe-id and use my good ol' one instead.

[BrentEubanks]

Originally Posted by Leseratte_10

Wrong as in "invalid username & password" but it still accepted and saved that? Or wrong as in you want to use a different Adobe account now?

The second. I had initially been unable to locate my old adobe credentials so I created new ones; then I found the old ones and want to use those. (Good thing too because the new credentials couldn't access my old ACSM - not a surprise I realize now.)

Anyway thanks, that worked to reset the plugin.

Thanks for mentioning the limited activations. I don't actually care about that for the current (new) credentials but I do care for my old adobe credentials - those have been with me for 6-7 years and have followed me through at least one computer upgrade.

Do you know how to find out from Adobe how many activations you have left on a particular account?

At this point, I've already installed and activated Adobe Digital Experiences (version 2.0) which is my old workflow and that seems to work. I'd like to use your plugin, but I'm not sure that I want to use up another activation (depending on how many I have). Ideally I could kick ADE to the curb and do everything within Calibre.

[BrentEubanks]

Originally Posted by patrik

Yes, I followed your tip and created a new adobe-id.

Which probably also did that even though the book got fetched, I can't open it. I'm guessing the adobe-credentials in Calibre are for my other adobe-id. (It's been quite some time since I installed v5 portable to test so I don't remember what I did or didn't do.)

Guess I give up and remove the new adobe-id and use my good ol' one instead.

I just had the exact same experience. (I'm moving to a new computer, and re-learning how all this ebook DRM crap works.) Fortunately I was able to find my old ADE credentials.

[jhowell]

Thanks for this plugin. I was able to use it to download a PDF that was too large for my installed ADE version 2.0.1 to handle. (It would crash when receiving a 1.5GB file, probably because it is only a 32-bit program.)

Have you considered adding the ability to import an activation from an already installed and activated ADE? That would be useful in avoiding using up an activation on the plugin.

[Terisa de morgan]

Originally Posted by jhowell

Have you considered adding the ability to import an activation from an already installed and activated ADE? That would be useful in avoiding using up an activation on the plugin.

This! I agree it would be very useful.

[Leseratte_10]

Originally Posted by BrentEubanks

Do you know how to find out from Adobe how many activations you have left on a particular account?

No, I don't think they make that information public. According to some standards document I found online a while ago, every AdobeID starts with 6+6 possible activations (6 for computers and 6 for eReaders), and gains 1+1 additional activation every year. If you need more than that, you can contact Adobe and they'll usually reset the limit for you. (Of course don't mention this plugin, just say something like "I had to reinstall my computer a couple times and now it says I ran out of activations".)

Originally Posted by jhowell

Thanks for this plugin. I was able to use it to download a PDF that was too large for my installed ADE version 2.0.1 to handle. (It would crash when receiving a 1.5GB file, probably because it is only a 32-bit program.)

Yeah, some other people have told me that as well - my plugin being able to download a bunch of PDF files that even ADE can't handle. It seems to be related to file size somewhat, but not just file size as some large files did work in ADE for them. Maybe it's just general complexity and running out of RAM while parsing the internal structure, so a large simple PDF might work but a large complex one fails.

Originally Posted by jhowell

Have you considered adding the ability to import an activation from an already installed and activated ADE? That would be useful in avoiding using up an activation on the plugin.

I have thought about that, but A) that's pretty complicated and B) it probably drastically increases the chances of Adobe detecting what you're doing. It would require you to already be using one particular old-ish version of ADE (the one the plugin emulates) so Adobe doesn't notice that you "downgraded" an activation which is normally not possible. Also, in the data sent to Adobe there's tons of device IDs/machine IDs sent to Adobe in hashed form. These are just stored in the plugin settings as they are dumped / generated the first time, so moving one activation with this plugin around to multiple machines is fine (that's why it always says "Authorized on device X" even when you copy the activation over to other computers).

This means, that if there's errors in my plugin on how these IDs are generated (which there probably are), then Adobe is not going to know that and it doesn't matter - because all they see is the constant hash. However, if I import an activation from ADE (which does NOT store this hash and instead re-generates it from machine data every time it's needed), I would need to generate that data myself again, and due to the fact that the hash my plugin makes almost certainly wouldn't be identical to the one ADE would create, that would be another thing Adobe could use to detect this.

I don't think it's worth the effort, considering it does increase the chances of Adobe detecting what you do.

What I could try doing would be to import an existing authorization for an eReader. Some/most/all (not looked into that much) eReaders seem to do the same thing my plugin does and just dump all the data into files once, so if the Adobe authorization data is visible to the user through the USB filesystem, then they could potentially be imported into the plugin.

Of course you should only do that if you have an eReader that's capable of turning ACSMs into EPUBs. Would be pretty easy to detect if a Sony PRS-T1 - which does not have any capability to fulfill ACSM files - would suddenly start sending requests to Adobe to fulfill an ACSM file (with these requests actually coming from Calibre instead).

Given that you can call Adobe to have that limit reset, and given that you could also just make a new dummy AdobeID if you're using DeDRM, I don't think it's worth all the effort. The only issue / potential problem with this method (dummy ADE ID) would be if you're buying books from publishers that enforce the new, uncracked DRM, then the books would be stuck on the dummy account.

[jhowell]

Originally Posted by Leseratte_10

Given that you can call Adobe to have that limit reset, and given that you could also just make a new dummy AdobeID if you're using DeDRM, I don't think it's worth all the effort. The only issue / potential problem with this method (dummy ADE ID) would be if you're buying books from publishers that enforce the new, uncracked DRM, then the books would be stuck on the dummy account.

Another reason for cloning an existing ADE activation is that it would provide a means to verify that the interaction between the plugin and Adept servers matches that of an actual ADE installation using the same credentials and keys by comparing packet captures. That could be used to catch any remaining discrepancies between ADE and the plugin, making it less likely that use of the plugin could be detected by Adobe. Of course that would only work if the activation being cloned came from an ADE version that the plugin is able to emulate.

I do agree it would be a fair amount of additional work for little potential benefit.

----------------

Thinking about this raises the question of what ADE version does the plugin emulate?

I have ADE for Windows version 2.0.1 installed on my PC running Windows 11 and it identifies itself as clientVersion 2.0.1.78765, softwareVersion 9.3.58046, and clientOS of "Windows Vista". (Looking at the code it has a fixed set of possible Windows versions that it can report with Vista being the newest possible.)

I also have an installer file for ADE version 3.0. It will apparently will identify itself as clientVersion 3.0.1, softwareVersion 10.0.85385, and clientOS going up to "Windows 8.1".

The plugin appears to identify itself to Adobe as clientVersion "Desktop" with softwareVersion 10.0.4, and clientOS of "Windows 10". I am curious to know what ADE version this is intended to correspond to.

[milady133]

Originally Posted by BrentEubanks

Thanks for mentioning the limited activations. I don't actually care about that for the current (new) credentials but I do care for my old adobe credentials - those have been with me for 6-7 years and have followed me through at least one computer upgrade.

Apart from what they have said that Adobe adds activations each year, I did reach the limit of activations some years ago (new computer + testing different applications in Android and Windows to download epubs) and had to contact Adobe to add more devices/applications to activate. They didn't answer immediately from what I recall, but in a few hours or a day max I was able to activate more. So don't worry much about reaching that limit.

[Leseratte_10]

Originally Posted by jhowell

Thinking about this raises the question of what ADE version does the plugin emulate?

I have ADE for Windows version 2.0.1 installed on my PC running Windows 11 and it identifies itself as clientVersion 2.0.1.78765, softwareVersion 9.3.58046, and clientOS of "Windows Vista". (Looking at the code it has a fixed set of possible Windows versions that it can report with Vista being the newest possible.)

I also have an installer file for ADE version 3.0. It will apparently will identify itself as clientVersion 3.0.1, softwareVersion 10.0.85385, and clientOS going up to "Windows 8.1".

The plugin appears to identify itself to Adobe as clientVersion "Desktop" with softwareVersion 10.0.4, and clientOS of "Windows 10". I am curious to know what ADE version this is intended to correspond to.

That's a good question. That stuff is taken almost 1:1 from libgourou, and I have to admit I haven't looked into this too much.

Looking at the source code, "clientVersion" is hardcoded to the device's "deviceClass", which is hardcoded to "Desktop". softwareVersion is hardcoded to 10.0.4 which is described as "hobbes version" and is apparently the RMSDK version.

That would make sense, ADE 2.0.1 using RMSDK9 and ADE 3.0 using RMSDK10. It would also mean, with the plugin using 10.0.4 (maybe that's from an old eReader) that Adobe could deliver books encrypted with the new DRM to this plugin. I don't think switching this around with an existing activation is a good idea, but maybe I'll try adding a setting that can be set during authorization to either emulate RMSDK9/ADE2.0.1 or RMSDK10/ADE3.0.

As for the client OS, that's currently just set to "platform.system() + " " + platform.release()". Meaning, "Windows 10" or "Windows 11" depending on the Windows version, or "Linux 5.xx.x-xx-generic" for Linux. That's probably a bad idea as a value of "Linux" for the OS probably immediately tells Adobe that there's something fishy.

I will play around with that a bit, make a couple more dummy accounts, and add an ADE2.0/ADE3.0 switch during authorization. And I'll ditch that code that sends the actual OS and just always have it use "Windows Vista" for ADE2.0 and "Windows 8.1" for ADE3.0.

[Leseratte_10]

Okay, there's definitely something wrong with how the plugin currently sends version numbers.

I have no idea where that 10.0.4 is from - I just took that value from libgourou, which is also sending "10.0.4" as clientVersion. Looking at what kind of weird data other software is sending to Adobe as their "clientVersion" (Sony Reader for PC, Aldiko, ADE 1.7.2, ...) this is unlikely to cause issues, though. But given that it's a 10.x.x version number, the server will probably see that as an ADE3.0-compatible client and could send you books with the new DRM.

With the next version of the plugin (v0.0.13) which I'll probably release tomorrow, you will be able to select the ADE version to emulate. You can choose between ADE 2.0.1, 3.0.1, 4.0.3 and 4.5.11 while authorizing, and you can freely change between them (and ADE 1.7.2) afterwards. To Adobe this should just look like you have multiple versions of ADE installed on the same machine - though I obviously can't say for certain, so I wouldn't switch between versions too often.

To prevent breaking stuff or causing inconsistencies, the updated plugin will continue to send the old, broken data it is sending now until you explicitly go into the plugin settings and choose one of the available versions.

[Leseratte_10]

Status update: I did decide to look into how exactly ADE stores its activation, and the next version of the plugin will also support importing an existing activation from Adobe Digital Editions into the plugin without using up an activation. I have tested this with ADE on Windows and ADE on Mac (they both needed completely seperate implementations ...) - it will not work (yet) if you're on Linux and you are running ADE in Wine.
Thanks jhowell for poking me and suggesting that again

With that new update (not released yet), there will be a new button "Import activation from ADE" in the plugin settings when it's not authorized. If you're on Mac, you will need to enter your keychain password when asked. If you're on Windows, it'll just work by clicking the button.

Now, the next interesting thing would be taking a Calibre activation and writing that back into ADE... That would mean that you could basically use Calibre to copy one single ADE activation around to multiple different ADE installations on multiple different machines ...

[gbm]

Originally Posted by Leseratte_10

Status update: I did decide to look into how exactly ADE stores its activation, and the next version of the plugin will also support importing an existing activation from Adobe Digital Editions into the plugin without using up an activation. I have tested this with ADE on Windows and ADE on Mac (they both needed completely seperate implementations ...) - it will not work (yet) if you're on Linux and you are running ADE in Wine.
Thanks jhowell for poking me and suggesting that again

With that new update (not released yet), there will be a new button "Import activation from ADE" in the plugin settings when it's not authorized. If you're on Mac, you will need to enter your keychain password when asked. If you're on Windows, it'll just work by clicking the button.

Now, the next interesting thing would be taking a Calibre activation and writing that back into ADE... That would mean that you could basically use Calibre to copy one single ADE activation around to multiple different ADE installations on multiple different machines ...

What I hope is that it will import my ADE activation from my Win10 VM to my linux calibre.

bernie

[jhowell]

Originally Posted by Leseratte_10

Status update: I did decide to look into how exactly ADE stores its activation, and the next version of the plugin will also support importing an existing activation from Adobe Digital Editions into the plugin without using up an activation. I have tested this with ADE on Windows and ADE on Mac (they both needed completely seperate implementations ...)

You may have solved this already, but just in case... There is a difference between an activation.xml file and the ADE activation data in the Windows registry. The privateLicenseKey is stored encrypted in Windows. DeDRM has code to decrypt that, but it incorrectly uses an IV of all zeros, causing the first 16 bytes of the decrypted value to be incorrect. That doesn't matter for DeDRM since it does not use those bytes, but it may matter for your plugin. The IV to properly decrypt that field is the first 16 bytes of the base-64 decoded fingerprint.

Originally Posted by Leseratte_10

Thanks jhowell for poking me and suggesting that again

Thanks you for all of the work that you are putting into this.

[Leseratte_10]

Originally Posted by gbm

What I hope is that it will import my ADE activation from my Win10 VM to my linux calibre.

Yeah, that should be possible once the update is released. Install Calibre and the plugin inside the VM, import the activation from ADE then export it into a ZIP file, then copy that ZIP over to your Linux machine and import it into the plugin.

Originally Posted by jhowell

You may have solved this already, but just in case... There is a difference between an activation.xml file and the ADE activation data in the Windows registry. The privateLicenseKey is stored encrypted in Windows. DeDRM has code to decrypt that, but it incorrectly uses an IV of all zeros, causing the first 16 bytes of the decrypted value to be incorrect. That doesn't matter for DeDRM since it does not use those bytes, but it may matter for your plugin. The IV to properly decrypt that field is the first 16 bytes of the base-64 decoded fingerprint.

Wow, I did not know that. I am using the decryption code from the DeDRM plugin to decrypt that and the decrypted form did work (so the first 16 bytes probably aren't that important), but this might explain some other oddities I ran into. I will try decrypting that with the first 16 bytes of the fingerprint instead and see what that results in. The fingerprint is stored unencrypted in the registry so it should be easy to add that.