Closed JJTech0130 closed 1 year ago
JJTech0130
commented
1 year ago Second part was my mistake, for some reason I thought that this plugin did decryption, but with proper rights checking. I see now that it just leaves that for an DeDRM to deal with. I thought DeDRM was only necessary if you wanted to export it something... anyway, still confused about the activation token
Leseratte10
commented
1 year ago The returned data from the /Activate request (the activation token) gets stored inside the activation.xml file, as is. Maybe some of the data isn't needed there, but I tried to implement the XML files identical to how Adobe does it.
I believe the only values that are actually needed are "device", "fingerprint" and "deviceType". "deviceType" will always be "standalone" for authorizations done by this plugin, but as the plugin also supports exporting the authorization files I wanted to keep them as they are supposed to be.
Never looked into that "signature" tag the server returns, I'm assuming it's intended so that the client can somehow verify that the response came from a legit Adobe server and hasn't been modified in transit. As there was no need to implement that signature check to have the plugin work, I never looked into how that parameter works, and I don't think libgourou contains any code related to that either.
If you figure out how to validate that signature parameter feel free to let me know and I'll add it.
And as you already noticed, this plugin does nothing to remove the DRM from fulfilled books. It would be fairly simple to add as all the keys are already there, but I don't want to get involved in potential legal issues.
JJTech0130
commented
1 year ago Yeah, since this was intended to be a reader plugin and will not ever be on a computer with adobe software, I was going to simplify things a bit. For now at least, I'm just going to store the device in the normal preferences store (not XML), along with the fingerprint (which we generate, right?)
JJTech0130
commented
1 year ago Maybe sometime I'll improve it to be identical to ADE, but for now I just want a working implementation 😄
Leseratte10
commented
1 year ago If this is going into an eReader plugin, it might be a good idea to attempt a mobile authorization instead of a standalone Desktop authorization. Each Adobe ID starts out with 6 desktop and 6 mobile authorizations available, and each activation through ADE, readers, or this plugin will use one of these. If reader plugins / eReaders identify as mobile authorizations as intended, people can actually use more of their available authorizations.
Especially if you plan to "deviate" from the standard and/or do not plan to have an import/export functionality for an existing authorization like my plugin. If you do plan to have that and people can clone their authorizations then desktop auth is probably fine IMO, but that would require you to store the data like Adobe does.
JJTech0130
commented
1 year ago That's a good idea, I'll put it on my to-do list. Perhaps I'll even allow both. Anyhow, I should get basic functionality first 😄
So, I just would like to clarify a few things: First, when activating, do we actually need to save anything it returns, other than the Device UUID? I'm a little confused, as the "activation token" you send to the server is not what is returned by the activation request, and is instead just constructed from the user and device UUIDs... so what is the signature for?
Second, where in your plugin is the book decrypted? I see that it downloads the epub, and inserts rights.xml, but what happens next so you can read it?