Issue getting activation bytes from auth server about audible HOT 9 CLOSED

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

from audible.

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.

from audible.

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.

from audible.

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?

from audible.

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?

from audible.

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.

from audible.

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.

from audible.

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.

from audible.

@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.

from audible.