Sorting XML keys for activation

[JJTech0130]

Sorry to bother you again, but I'm a little confused. In order to verify that the activation request came from the user you claim to be, you sign the SHA1 of the request with your auth key, correct? The only thing I don't get is the key sorting: do you need to sort the XML you send to adobe, or only sort before you sign it (and still send the unordered version to adobe, who re-sorts it on the other end) The reason I ask is that when I'm signing the keys, I could sort them pretty easily, as they're parsed and I can move them around, etc. The problem is that the XML builder I'm using doesn't support sorting, so in order to sort them in XML form I would have to modify it significantly.

[JJTech0130]

I tried printing out what you were adding to the hash (with the raw bytes function), and I got this hexdump:

``` 00000000 01 |.| 00000001 00000000 00 19 |..| 00000002 00000000 68 74 74 70 3a 2f 2f 6e 73 2e 61 64 6f 62 65 2e |http://ns.adobe.| 00000010 63 6f 6d 2f 61 64 65 70 74 |com/adept| 00000019 00000000 00 08 |..| 00000002 00000000 61 63 74 69 76 61 74 65 |activate| 00000008 00000000 05 |.| 00000001 00000000 00 00 |..| 00000002 00000000 00 0b |..| 00000002 00000000 72 65 71 75 65 73 74 54 79 70 65 |requestType| 0000000b 00000000 00 07 |..| 00000002 00000000 69 6e 69 74 69 61 6c |initial| 00000007 00000000 02 |.| 00000001 00000000 01 |.| 00000001 00000000 00 19 |..| 00000002 00000000 68 74 74 70 3a 2f 2f 6e 73 2e 61 64 6f 62 65 2e |http://ns.adobe.| 00000010 63 6f 6d 2f 61 64 65 70 74 |com/adept| 00000019 00000000 00 0b |..| 00000002 00000000 66 69 6e 67 65 72 70 72 69 6e 74 |fingerprint| 0000000b 00000000 02 |.| 00000001 00000000 04 |.| 00000001 00000000 00 1c |..| 00000002 00000000 44 45 55 4c 53 44 48 5a 35 39 6b 67 79 6b 49 4d |DEULSDHZ59kgykIM| 00000010 34 32 4e 74 78 75 55 73 76 2b 73 3d |42NtxuUsv+s=| 0000001c 00000000 03 |.| 00000001 00000000 01 |.| 00000001 00000000 00 19 |..| 00000002 00000000 68 74 74 70 3a 2f 2f 6e 73 2e 61 64 6f 62 65 2e |http://ns.adobe.| 00000010 63 6f 6d 2f 61 64 65 70 74 |com/adept| 00000019 00000000 00 0a |..| 00000002 00000000 64 65 76 69 63 65 54 79 70 65 |deviceType| 0000000a 00000000 02 |.| 00000001 00000000 04 |.| 00000001 00000000 00 0a |..| 00000002 00000000 73 74 61 6e 64 61 6c 6f 6e 65 |standalone| 0000000a 00000000 03 |.| 00000001 00000000 01 |.| 00000001 00000000 00 19 |..| 00000002 00000000 68 74 74 70 3a 2f 2f 6e 73 2e 61 64 6f 62 65 2e |http://ns.adobe.| 00000010 63 6f 6d 2f 61 64 65 70 74 |com/adept| 00000019 00000000 00 08 |..| 00000002 00000000 63 6c 69 65 6e 74 4f 53 |clientOS| 00000008 00000000 02 |.| 00000001 00000000 04 |.| 00000001 00000000 00 0d |..| 00000002 00000000 57 69 6e 64 6f 77 73 20 56 69 73 74 61 |Windows Vista| 0000000d 00000000 03 |.| 00000001 00000000 01 |.| 00000001 00000000 00 19 |..| 00000002 00000000 68 74 74 70 3a 2f 2f 6e 73 2e 61 64 6f 62 65 2e |http://ns.adobe.| 00000010 63 6f 6d 2f 61 64 65 70 74 |com/adept| 00000019 00000000 00 0c |..| 00000002 00000000 63 6c 69 65 6e 74 4c 6f 63 61 6c 65 |clientLocale| 0000000c 00000000 02 |.| 00000001 00000000 04 |.| 00000001 00000000 00 02 |..| 00000002 00000000 65 6e |en| 00000002 00000000 03 |.| 00000001 00000000 01 |.| 00000001 00000000 00 19 |..| 00000002 00000000 68 74 74 70 3a 2f 2f 6e 73 2e 61 64 6f 62 65 2e |http://ns.adobe.| 00000010 63 6f 6d 2f 61 64 65 70 74 |com/adept| 00000019 00000000 00 0d |..| 00000002 00000000 63 6c 69 65 6e 74 56 65 72 73 69 6f 6e |clientVersion| 0000000d 00000000 02 |.| 00000001 00000000 04 |.| 00000001 00000000 00 0b |..| 00000002 00000000 32 2e 30 2e 31 2e 37 38 37 36 35 |2.0.1.78765| 0000000b 00000000 03 |.| 00000001 00000000 01 |.| 00000001 00000000 00 19 |..| 00000002 00000000 68 74 74 70 3a 2f 2f 6e 73 2e 61 64 6f 62 65 2e |http://ns.adobe.| 00000010 63 6f 6d 2f 61 64 65 70 74 |com/adept| 00000019 00000000 00 0c |..| 00000002 00000000 74 61 72 67 65 74 44 65 76 69 63 65 |targetDevice| 0000000c 00000000 02 |.| 00000001 00000000 01 |.| 00000001 00000000 00 19 |..| 00000002 00000000 68 74 74 70 3a 2f 2f 6e 73 2e 61 64 6f 62 65 2e |http://ns.adobe.| 00000010 63 6f 6d 2f 61 64 65 70 74 |com/adept| 00000019 00000000 00 0f |..| 00000002 00000000 73 6f 66 74 77 61 72 65 56 65 72 73 69 6f 6e |softwareVersion| 0000000f 00000000 02 |.| 00000001 00000000 04 |.| 00000001 00000000 00 09 |..| 00000002 00000000 39 2e 33 2e 35 38 30 34 36 |9.3.58046| 00000009 00000000 03 |.| 00000001 00000000 01 |.| 00000001 00000000 00 19 |..| 00000002 00000000 68 74 74 70 3a 2f 2f 6e 73 2e 61 64 6f 62 65 2e |http://ns.adobe.| 00000010 63 6f 6d 2f 61 64 65 70 74 |com/adept| 00000019 00000000 00 08 |..| 00000002 00000000 63 6c 69 65 6e 74 4f 53 |clientOS| 00000008 00000000 02 |.| 00000001 00000000 04 |.| 00000001 00000000 00 0d |..| 00000002 00000000 57 69 6e 64 6f 77 73 20 56 69 73 74 61 |Windows Vista| 0000000d 00000000 03 |.| 00000001 00000000 01 |.| 00000001 00000000 00 19 |..| 00000002 00000000 68 74 74 70 3a 2f 2f 6e 73 2e 61 64 6f 62 65 2e |http://ns.adobe.| 00000010 63 6f 6d 2f 61 64 65 70 74 |com/adept| 00000019 00000000 00 0c |..| 00000002 00000000 63 6c 69 65 6e 74 4c 6f 63 61 6c 65 |clientLocale| 0000000c 00000000 02 |.| 00000001 00000000 04 |.| 00000001 00000000 00 02 |..| 00000002 00000000 65 6e |en| 00000002 00000000 03 |.| 00000001 00000000 01 |.| 00000001 00000000 00 19 |..| 00000002 00000000 68 74 74 70 3a 2f 2f 6e 73 2e 61 64 6f 62 65 2e |http://ns.adobe.| 00000010 63 6f 6d 2f 61 64 65 70 74 |com/adept| 00000019 00000000 00 0d |..| 00000002 00000000 63 6c 69 65 6e 74 56 65 72 73 69 6f 6e |clientVersion| 0000000d 00000000 02 |.| 00000001 00000000 04 |.| 00000001 00000000 00 0b |..| 00000002 00000000 32 2e 30 2e 31 2e 37 38 37 36 35 |2.0.1.78765| 0000000b 00000000 03 |.| 00000001 00000000 01 |.| 00000001 00000000 00 19 |..| 00000002 00000000 68 74 74 70 3a 2f 2f 6e 73 2e 61 64 6f 62 65 2e |http://ns.adobe.| 00000010 63 6f 6d 2f 61 64 65 70 74 |com/adept| 00000019 00000000 00 0a |..| 00000002 00000000 64 65 76 69 63 65 54 79 70 65 |deviceType| 0000000a 00000000 02 |.| 00000001 00000000 04 |.| 00000001 00000000 00 0a |..| 00000002 00000000 73 74 61 6e 64 61 6c 6f 6e 65 |standalone| 0000000a 00000000 03 |.| 00000001 00000000 01 |.| 00000001 00000000 00 19 |..| 00000002 00000000 68 74 74 70 3a 2f 2f 6e 73 2e 61 64 6f 62 65 2e |http://ns.adobe.| 00000010 63 6f 6d 2f 61 64 65 70 74 |com/adept| 00000019 00000000 00 0b |..| 00000002 00000000 70 72 6f 64 75 63 74 4e 61 6d 65 |productName| 0000000b 00000000 02 |.| 00000001 00000000 04 |.| 00000001 00000000 00 17 |..| 00000002 00000000 41 44 4f 42 45 20 44 69 67 69 74 69 61 6c 20 45 |ADOBE Digitial E| 00000010 64 69 74 69 6f 6e 73 |ditions| 00000017 00000000 03 |.| 00000001 00000000 01 |.| 00000001 00000000 00 19 |..| 00000002 00000000 68 74 74 70 3a 2f 2f 6e 73 2e 61 64 6f 62 65 2e |http://ns.adobe.| 00000010 63 6f 6d 2f 61 64 65 70 74 |com/adept| 00000019 00000000 00 0b |..| 00000002 00000000 66 69 6e 67 65 72 70 72 69 6e 74 |fingerprint| 0000000b 00000000 02 |.| 00000001 00000000 04 |.| 00000001 00000000 00 1c |..| 00000002 00000000 44 45 55 4c 53 44 48 5a 35 39 6b 67 79 6b 49 4d |DEULSDHZ59kgykIM| 00000010 34 32 4e 74 78 75 55 73 76 2b 73 3d |42NtxuUsv+s=| 0000001c 00000000 03 |.| 00000001 00000000 03 |.| 00000001 00000000 01 |.| 00000001 00000000 00 19 |..| 00000002 00000000 68 74 74 70 3a 2f 2f 6e 73 2e 61 64 6f 62 65 2e |http://ns.adobe.| 00000010 63 6f 6d 2f 61 64 65 70 74 |com/adept| 00000019 00000000 00 05 |..| 00000002 00000000 6e 6f 6e 63 65 |nonce| 00000005 00000000 02 |.| 00000001 00000000 04 |.| 00000001 00000000 00 10 |..| 00000002 00000000 7a 67 57 75 58 67 77 36 41 41 41 41 41 41 41 41 |zgWuXgw6AAAAAAAA| 00000010 00000000 03 |.| 00000001 00000000 01 |.| 00000001 00000000 00 19 |..| 00000002 00000000 68 74 74 70 3a 2f 2f 6e 73 2e 61 64 6f 62 65 2e |http://ns.adobe.| 00000010 63 6f 6d 2f 61 64 65 70 74 |com/adept| 00000019 00000000 00 0a |..| 00000002 00000000 65 78 70 69 72 61 74 69 6f 6e |expiration| 0000000a 00000000 02 |.| 00000001 00000000 04 |.| 00000001 00000000 00 14 |..| 00000002 00000000 32 30 32 32 2d 30 37 2d 31 31 54 32 33 3a 35 38 |2022-07-11T23:58| 00000010 3a 30 31 5a |:01Z| 00000014 00000000 03 |.| 00000001 00000000 01 |.| 00000001 00000000 00 19 |..| 00000002 00000000 68 74 74 70 3a 2f 2f 6e 73 2e 61 64 6f 62 65 2e |http://ns.adobe.| 00000010 63 6f 6d 2f 61 64 65 70 74 |com/adept| 00000019 00000000 00 04 |..| 00000002 00000000 75 73 65 72 |user| 00000004 00000000 02 |.| 00000001 00000000 04 |.| 00000001 00000000 00 2d |.-| 00000002 00000000 75 72 6e 3a 75 75 69 64 3a 39 39 32 38 31 38 34 |urn:uuid:9928184| 00000010 64 2d 65 61 63 33 2d 34 34 36 35 2d 61 64 64 39 |d-eac3-4465-add9| 00000020 2d 62 37 38 65 35 34 62 39 39 64 61 38 |-b78e54b99da8| 0000002d 00000000 03 |.| 00000001 00000000 03 |.| ```

Not sure what all the special values that aren't characters are? This left me more confused than before.

[JJTech0130]

Ah, I see, it's the lengths It's starting to be a little bit clearer...

[Leseratte10]

With key sorting you're refering to the attribute keys?

    attrKeys = node.keys()

    # Attributes need to be sorted
    attrKeys.sort()
    # TODO Implement UTF-8 bytewise sorting:
    # "Attributes are sorted first by their namespaces and
    # then by their names; sorting is done bytewise on UTF-8
    # representations."

    for attribute in attrKeys: 
        ....

I don't have any code to sort the actual attributes in the XML itself, so I don't think that that's necessary. Adobe probably sorts the XML themselves before comparing it to the hashed and signed value.

The bytes that aren't text are either the string length, or the element type:

ASN_NONE = 0
ASN_NS_TAG = 1      # aka "BEGIN_ELEMENT"
ASN_CHILD = 2       # aka "END_ATTRIBUTES"
ASN_END_TAG = 3     # aka "END_ELEMENT"
ASN_TEXT = 4        # aka "TEXT_NODE"
ASN_ATTRIBUTE = 5   # aka "ATTRIBUTE"

[JJTech0130]

I think I understand it now, but I don’t get how the elements are sorted. They must be sorted, right? Otherwise the hashes would not match.

[JJTech0130]

Specifically, I'm confused on how child elements are sorted. In your code, it appears that it is sorted like this: fingerprint, deviceType, clientOS, ... targetDevice? Which is basically not sorted at all? So how do you determine the order they should be in?

[JJTech0130]

I implemented basic alphabetical sorting, but it doesn't seem to match the output of your plugin: (strings passed to grep -v ns.adobe.com then hand-formatted)

activate(requestType: Initial):
    clientLocale(): en
    clientOS(): Windows 8
    clientVersion(): 2.0.1.78765
    deviceType(): standalone
    expiration(): 2022-07-12T13:42:45Z
    fingerprint(): iJYuMUeN9R8vr2wJT762Wo+ayxo=
    nonce(): EZLPlo7XpgPCqERP
    targetDevice():
        clientLocale(): en
        clientOS(): Windows 8
        clientVersion(): 2.0.1.78765
        deviceType(): standalone
        fingerprint(): iJYuMUeN9R8vr2wJT762Wo+ayxo=
        productName(): ADOBE Digitial Editions
        softwareVersion(): 9.3.58046
    user(): -urn:uuid:9ff48d98-40d5-46e3-a50c-ebe57a5aa8c7

Base64

``` AQAZaHR0cDovL25zLmFkb2JlLmNvbS9hZGVwdAAIYWN0aXZhdGUFAAAAC3JlcXVlc3RUeXBlAAdJbml0aWFsAgEAGWh0dHA6Ly9ucy5hZG9iZS5jb20vYWRlcHQADGNsaWVudExvY2FsZQIEAAJlbgMBABlodHRwOi8vbnMuYWRvYmUuY29tL2FkZXB0AAhjbGllbnRPUwIEAAlXaW5kb3dzIDgDAQAZaHR0cDovL25zLmFkb2JlLmNvbS9hZGVwdAANY2xpZW50VmVyc2lvbgIEAAsyLjAuMS43ODc2NQMBABlodHRwOi8vbnMuYWRvYmUuY29tL2FkZXB0AApkZXZpY2VUeXBlAgQACnN0YW5kYWxvbmUDAQAZaHR0cDovL25zLmFkb2JlLmNvbS9hZGVwdAAKZXhwaXJhdGlvbgIEABQyMDIyLTA3LTEyVDEzOjQ2OjQ1WgMBABlodHRwOi8vbnMuYWRvYmUuY29tL2FkZXB0AAtmaW5nZXJwcmludAIEABwvVFhNYkZoZXZCaXlYWkxCNncyU2NERnd1Ym89AwEAGWh0dHA6Ly9ucy5hZG9iZS5jb20vYWRlcHQABW5vbmNlAgQAEEtCUjdkSG5HVkdLQWxrL1oDAQAZaHR0cDovL25zLmFkb2JlLmNvbS9hZGVwdAAMdGFyZ2V0RGV2aWNlAgEAGWh0dHA6Ly9ucy5hZG9iZS5jb20vYWRlcHQADGNsaWVudExvY2FsZQIEAAJlbgMBABlodHRwOi8vbnMuYWRvYmUuY29tL2FkZXB0AAhjbGllbnRPUwIEAAlXaW5kb3dzIDgDAQAZaHR0cDovL25zLmFkb2JlLmNvbS9hZGVwdAANY2xpZW50VmVyc2lvbgIEAAsyLjAuMS43ODc2NQMBABlodHRwOi8vbnMuYWRvYmUuY29tL2FkZXB0AApkZXZpY2VUeXBlAgQACnN0YW5kYWxvbmUDAQAZaHR0cDovL25zLmFkb2JlLmNvbS9hZGVwdAALZmluZ2VycHJpbnQCBAAcL1RYTWJGaGV2Qml5WFpMQjZ3MlNjREZ3dWJvPQMBABlodHRwOi8vbnMuYWRvYmUuY29tL2FkZXB0AAtwcm9kdWN0TmFtZQIEABdBRE9CRSBEaWdpdGlhbCBFZGl0aW9ucwMBABlodHRwOi8vbnMuYWRvYmUuY29tL2FkZXB0AA9zb2Z0d2FyZVZlcnNpb24CBAAJOS4zLjU4MDQ2AwMBABlodHRwOi8vbnMuYWRvYmUuY29tL2FkZXB0AAR1c2VyAgQALXVybjp1dWlkOjlmZjQ4ZDk4LTQwZDUtNDZlMy1hNTBjLWViZTU3YTVhYThjNwMD ```

Here is the implementation I have so far: https://github.com/JJTech0130/kodobe/blob/master/adobe/util/asn1.lua

[JJTech0130]

I'm thinking now that they're just in the order that you added them to the XML, and that it just has to match the XML? I'll have to do some minor rewriting/wrapping, as the XML library expects it to be unsorted, so I have to fix that.

[Leseratte10]

The comment about things being sorted only applies to attributes, not to tags / elements. These indeed just have to be hashed in the same order they appear in the XML.

[JJTech0130]

If they just have to be the same, but not any particular order, I might be able to get away with just slightly modifying the XML builder to output the elements alphabetically. The way the tables are structured now, all order metadata is lost and they are simply in a random order, so I can't just use the order I added them in.

[JJTech0130]

So, I think I got it all working, but when I send it to adobe I get:

<error xmlns="http://ns.adobe.com/adept" data="E_AUTH_USER_AUTH http://adeactivate.adobe.com/adept/Activate urn:uuid:80194bf2-87a1-4098-9df2-a408b43e46d4"/>

Do you know what causes this error?

[Leseratte10]

Nope. Didn't even know that error existed and it's not in my error list.

If you think your signing code might be wrong, maybe take the XML you've sent and run it through my Python code and see if that generates the same hash.

[JJTech0130]

Well, I just checked, and they do generate the same hash! I guess it must be my pkcs12 signing code that's buggy? That or the way the request is constructed...

[JJTech0130]

Here's the XML, just in case you can spot any glaring errors:

<?xml version="1.0"?>
<adept:activate requestType="initial" xmlns:adept="http://ns.adobe.com/adept">
  <adept:clientLocale>en</adept:clientLocale>
  <adept:clientOS>Windows 8</adept:clientOS>
  <adept:clientVersion>2.0.1.78765</adept:clientVersion>
  <adept:deviceType>standalone</adept:deviceType>
  <adept:expiration>2022-07-12T17:53:36Z</adept:expiration>
  <adept:fingerprint>Agx6h6Y2cWEwI2RkAJe47ZvQu2g=</adept:fingerprint>
  <adept:nonce>o6Csc7ZmOyn19saV</adept:nonce>
  <adept:signature>AK61NX2z4U0Si9wpCrIEy7CzVYnWnnNe5Wk4JkqEG/QGuDespS2yXQ+LZrBHN50Cd7T8MK0jx9xCxFiurXkHvKOkp0RcnAieUJngneeygpZP0snv8OswstgkkhcPzZ2vFmzQ+0Dwu5McFM8CeHHqVZ8ZzgwjYJxa7sXcC7B6DBFY</adept:signature>
  <adept:targetDevice>
    <adept:clientLocale>en</adept:clientLocale>
    <adept:clientOS>Windows 8</adept:clientOS>
    <adept:clientVersion>2.0.1.78765</adept:clientVersion>
    <adept:deviceType>standalone</adept:deviceType>
    <adept:fingerprint>Agx6h6Y2cWEwI2RkAJe47ZvQu2g=</adept:fingerprint>
    <adept:productName>ADOBE Digitial Editions</adept:productName>
    <adept:softwareVersion>9.3.58046</adept:softwareVersion>
  </adept:targetDevice>
  <adept:user>urn:uuid:ec034af5-f793-408b-b5cc-11207a149557</adept:user>
</adept:activate>

[Leseratte10]

I just checked my logs from when I started developing this plugin and I did indeed run into E_AUTH_USER_AUTH, too, after I finished implementing the hashing code.

In my case this issue was caused by buggy signing code - this really needs to be a raw signature of just the hash, without any additional hashing or algorithm identifiers. Usual signing code (I tried OpenSSL's RSA_private_encrypt and Python's PKCS1_v1_5.sign()) doesn't do that, which means I had to use a special, low-level RSA python library and later re-wrote the complete native RSA algorithm which you can see in the customRSA.py file.

For your testing, you can see a payload and its correct signature inside the function test_sign_node_new() in tests/main.py. When encrypting that payload (34 52 e3 ...) with the mock key that's included there ("MIICdAI..."), your code needs to generate this exact signature ("RO/JmWr..."). If it doesn't, then you're probably not perfoming raw RSA.

[JJTech0130]

Is your test key a PEM encoded private key? Or is it PKCS12? Does it have a password? I'm getting parsing errors trying to use it.

[Leseratte10]

Also, unrelated, but I noticed you're emulating Windows 8 and ADE 2.0.1, which I believe is not something a legit ADE will ever send. As far as I know, ADE 2.0.X and lower only register as up to Windows Vista, only ADE 3+ use Windows 8 as OS.

[JJTech0130]

Is your test key a PEM encoded private key? Or is it PKCS12? Does it have a password? I'm getting parsing errors trying to use it.

Ah, nvm, I got it to work. It's just a raw key, was going through the extra PKCS12 step by accident lol

[JJTech0130]

Looks like the signing is the issue. I'm getting PiW/monqj0mzTvyRbGORQ4UaK58WdusYTRbQxOb9V4yMpOD4JEbGvEcmGrxavi7NP7RtJg2q8IJrF13B5imWChNPDk2ozkDeWZrA4Vr9myHkbHyGZIclHEkNlmWF4ImnJwKthaxYLoQa6idTxhpOUE0rASm6H1cxIUbKkbft/3c= as the sig...

[Leseratte10]

Yeah, I took a look at your code and you're using openssl's evp_pkey:sign() for the actual signature. That's going to be the exact same issue I had with OpenSSL - if the signature function you're using is asking you for an algorithm (like "sha1" in your case) then it's going to be the wrong encryption / signing code. Raw RSA doesn't need to know the signing algorithm.

You might need to do what I did and basically translate the CustomRSA.py into LUA.

[JJTech0130]

I'm trying to use sign_raw now, but I'm getting an error:

pkey:asymmetric_routine EVP_PKEY_sign: rsa/rsa_none.c:23:error:0406B07A:rsa routines:RSA_padding_add_none:data too small for key size

[JJTech0130]

Here's my code

    -- calculate SHA1 hash
    local sha1 = digest.new("SHA1")
    sha1:update(data)
    local hash = sha1:final()
    print("HASH: " .. util.base64.encode(hash))
    -- sign hash with no padding
    local sig, err = key:sign_raw(hash, pkey.PADDINGS.RSA_NO_PADDING)
    -- catch errors & return
    if err ~= nil then error(err) end
    return util.base64.encode(sig)

[Leseratte10]

Hm, looking at some docs, sign_raw might actually do what you need. Though the message (= the hash) will need to be padded for encryption as RSA only works on messages that are the same length as the key (that's why you're getting the error)

I don't know what other padding modes your library supports, but the one you need is implemented in pad_message in customRSA.py. Maybe you can just try all available ones. Or, if necessary, pre-pad the message yourself using my code. Unfortunately I have no idea if the padding algo in my code has a particular name, and I can't find definitions for all the different algorithms.

[JJTech0130]

Well, I tried some of the methods in the list it said it supported, but apparently the version of OpenSSL I'm using doesn't support them? Because it's returning errors for some of them. I tried all the ones that worked, and none returned the correct sig...

[Leseratte10]

According to this dude at Stackexchange it should be PKCS1 v1.5 signature padding. At least the graphic looks identical to the byte representation of my padding. Which is interesting, because that padding didn't work for me when I tried using it. If that doesn't work for whatever reason, you'll have to try to implement it yourself. Shouldn't be too hard, it's just like 5 lines of Python code.

[JJTech0130]

Yeah, perhaps I'll implement the padding myself. It has PKCS1 padding, but it's not coming out the same...

[JJTech0130]

Well, I implemented it, and now I'm getting ZJ4G6KdxOcPq8hJrQ2QAP8sAIAwijC+XqfRkzPfb3nGvx/AnODScUUSdtNECS34OrDVihtTMfw2qVl0iWOxnpT1bZDD1BB04i81K0qJvf/EQbUlBaRmMGW//EnFWyIQYRdKACcLWC9UGddCL28r4UtDXZwkd9a6CpcDnWVn5rX4=...

[JJTech0130]

I pushed my code in case you want to see it...

[JJTech0130]

Here's the hexdump of the padding:

00000000  00 01 ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |..??????????????|
00000010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |????????????????|
*
00000060  ff ff ff ff ff ff ff ff  ff ff ff 40 6c 4c 22 72  |???????????@lL"r|
00000070  5b d7 2f 80 3b bb 21 92  27 28 d8 cb d5 60 9d 00  |[?/.;?!.'(???`..|
00000080

[Leseratte10]

Okay, I see two mistakes in that padding: A) You implemented "00 01 PADDING DATA 00", but it needs to be "00 01 PADDING 00 DATA". B) Why is the data 40 6c 4c ... and so on? Assuming you're using the data from my test code it should be 34 52 e3 ... and so on.

[JJTech0130]

1) Just noticed and fixed that, thanks! 2) 'Cuz it's the SHA1 hash? Was it not supposed to be 🤦‍♂️

[JJTech0130]

Ok, so the regular OpenSSL PKCS1 padding does work then! I was just SHA1 hashing it first, 'cuz I didn't realize I wasn't supposed to lol

[Leseratte10]

No, the payload_bytes array in the test code already is the SHA1 hash of the XML. See test_hash_node(), that's the test code that takes an XML as input and returns that 34 52 e3 ... SHA1 hash.

[Leseratte10]

So, are you now getting the correct signature with my test key and test payload, or is there still an issue? Do you still get the E_AUTH_USER_AUTH error with the new code?

[JJTech0130]

I get the correct sig with the test key + payload, but same error

[Leseratte10]

Interesting, so there must be something else that's wrong ...

[JJTech0130]

OK, so I took a break for a bit, and tried checking the hashes again, and they were different?! But then I had them output the ASN data and it was the same... so my SHA1 hashing function is broken?!

[JJTech0130]

Uhhhhh... I made have made a bit of a mistake lol: I was hashing the wrong variable lol

[JJTech0130]

IT WORKS!!! I have successfully activated it with Adobe!

[JJTech0130]

Forgot to close the issue. It works now! I'll open another issue if I run into more problems later...