Issue getting activation bytes from auth server

[csandman]

Hey @mkb79, this isn't a problem with your package necessarily, but as I've mentioned before, I have my own project that uses a similar process as your fetch_activation, except written in TypeScript. More specifically, I almost directly translated the code from audible-activator for use in my project.

Recently, I noticed that the activation bytes that are being extracted from the activation blob returned from the /license/licenseForCustomerToken endpoint were incorrect so I had a look around the file. It appears that the bytes are still in there but their position has changed, and the extract_activation_bytes function from that package no longer works. I believe this was a pretty recent change, as it had been working fine for me a few months ago.

However, I noticed your function for extracting the activation bytes from the file are slightly different, so I was curious if yours still worked? I could get this set up myself and try it out, but my computer has been really struggling with Python lately, and I'd have to put in some effort to get it set up.

My other question is, if yours does still work, do you mind if I translate your extract_activation_bytes into TypeScript in order to get my project working again?

[mkb79]

I‘m short on time today. As first off I can verify that my code works. Tested it out with 2 accounts today.

You must take care about the activation blob length. Audible returns activation that contains metadata wich can vary. So read the last 568 bytes from the blob and take the first 4 bytes from them. In Python the code equivalent is data = activation_blob[-568:-564].

The 4 bytes must then be converted as little-endian unsigned int and convert them to hex. In Python the code equivalent is activation_bytes = "{:x}".format(*struct.unpack("<I", data)). That’s is. I’ll can rewrite this in TS but not today.

Best regards

[csandman]

Awesome, thanks for the info! I had actually already been trying to convert your extract_activation_bytes function to TS, because it looked different enough that I assumed it might still work. However, I was getting held up at the struct.unpack part because there is no direct equivalent for that in Node. But it turns out, all I really needed was the negative indexing! By replacing the code I had for finding the proper location of the activation bytes with that, it works like a charm! It's also much simpler, as the other function was trying to find the proper bytes by forward indexing based on the last (group_id=NNNNNN) section, which I believe is the part that broke.

[mkb79]

Great to hear that!

To be more precisely to my posting above. In the metadata of the activation blob you‘ll find these lines

…
(filled_slot_count=8)
(signature_size=70)
…

This mean you have 8 slots with a size of 70 bytes + 1 pad byte (a '\n' at the slot end)! In sum these are 568 bytes. I doesn’t have seen activation blobs with different slot counts or signature sizes. But if you want to take care about that you have to check these values.

[csandman]

But if you want to take care about that you have to check these values.

I'm confused what you mean by "take care about that", if you're indexing from the end of the whole blob, why would you need to pay attention to the sizes of these?

[mkb79]

The activation bytes are the first 4 bytes (in little endian byte order) of the 1st slot. But if you have 6 slots (I don’t see these yet) Then the offset is -426 (6*71 bytes) and not -568. Do you know what I mean?

[csandman]

Oh interesting, so the activation bytes are coming from the top part with plain text? Or is the top part replicated below in a different format?

As in, an example of what one of these blobs looks like in plain text for me is this:

(promo_url=http://www.audible.com)
(version=1)
(filled_slot_count=8)
(signature_size=70)
(slot=1)
(group_id=188326413)
(slot=2)
(group_id=848155291)
(slot=3)
(group_id=648399475)
(slot=4)
(group_id=55068575)
(slot=5)
(group_id=53292282)
(slot=6)
(group_id=73800193)
(slot=7)
(group_id=113670302)
(slot=8)
(group_id=74728381)
�9�
�������9��^kK
2U��`�����		�9o�0��ƢN+Rn���Z�� ]ZkpBT��2X�*FL{��"9
2�қ�������9��^kK
2U��`�����		�9o�0��ƢN+Rn���Z��K�P���������/�dq&ni�
&��s�������9��^kK
2U��`�����		�9o�0��ƢN+Rn���Z����__̥��&z��&�שׁ��
�HG��������9��^kK
2U��`�����		�9o�0��ƢN+Rn���Z��H9��� oA�:�٥�g��=:3
�-,��������9��^kK
2U��`�����		�9o�0��ƢN+Rn���Z��	K,��2���he�/Bêe���
�f���������9��^kK
2U��`�����		�9o�0��ƢN+Rn���Z���tY�
Hَ�
�0��_4��<�
��x��������9��^kK
2U��`�����		�9o�0��ƢN+Rn���Z��h=����R��o�����]�
�tC��������9��^kK
2U��`�����		�9o�0��ƢN+Rn���Z�� T�ħ�a��������4]�J�

My previous strategy for grabbing the activation bytes worked by pulling them out of the unreadable portion of the blob that's below the text at the top. Does your strategy still do that, or is actually coming from the top part?

But if you have 6 slots (I don’t see these yet) Then the offset is -426 (6*71 bytes) and not -568. Do you know what I mean?

And for this part, are you saying some accounts only have 6 slots available instead of 8? And would it be enough to just check if the UTF8 version of the file includes slot=8 to know if there is 8 vs 6 slots?

Sorry if I'm being confusing, I originally implemented this function without fully understanding how it works haha.

[mkb79]

The following are the activation blob metadata:

(promo_url=http://www.audible.com)
(version=1)
(filled_slot_count=8)
(signature_size=70)
(slot=1)
(group_id=188326413)
(slot=2)
(group_id=848155291)
(slot=3)
(group_id=648399475)
(slot=4)
(group_id=55068575)
(slot=5)
(group_id=53292282)
(slot=6)
(group_id=73800193)
(slot=7)
(group_id=113670302)
(slot=8)
(group_id=74728381)

Below this lines are the activation data. The metadata can vary but. But all activation blobs I've saw had 8 slots with 70 bytes signature size and 1 pad byte per slot.
So activation data are, until now, the last 568 bytes of the blob. So yeah you are currently safe by using the last 568 bytes.

[csandman]

Ok awesome, thanks for the info! This is definitely very helpful!

By the way, there was one other issue I've been dealing with that I was curious if you've had any experience with. One of the users of my app has a much bigger Audible library than I do and is having issues when downloading books because of what I believe is rate limiting. Have you ever experienced and rate limiting when downloading books with this tool? And if so, are there any safeguards in place to avoid it? I recently changed my app to download books sequentially instead of simultaneously, which may fix the issue but I wasn't sure if you had any experience with this.

[mkb79]

@csandman
As you can read here there seams to be a rate limit with AYCL titles. With titles I bought I does not have any issues.