fix: update allanime key and ct_len

[justchokingaround]

Pull Request Template

Type of change

• Bug fix
• Feature
• Documentation update

Description

ramble here

Checklist

• any anime playing
• bumped version

---

• next, prev and replay work
• -c history and continue work
• -d downloads work
• -s syncplay works
• -q quality works
• -v vlc works
• -e (select episode) aka -r (range selection) works
• -S select index works
• --skip ani-skip works
• --skip-title ani-skip title argument works
• --no-detach no detach works
• --exit-after-play auto exit after playing works
• --nextep-countdown countdown to next ep works
• --dub and regular (sub) mode both work
• all providers return links (not necessarily on a single anime, use debug mode to confirm)

---

• -h help info is up to date
• Readme is up to date
• Man page is up to date

Additional Testcases

• The safe bet: One Piece
• Episode 0: Saenai Heroine no Sodatekata ♭
• Unicode: Saenai Heroine no Sodatekata ♭
• Non-whole episodes: Tensei shitara slime datta ken (ep. 24.5, ep. 24.9)
• All Providers: Youkoso Jitsuryoku Shijou Shugi no Kyoushitsu e (TV) (3 m3u8, 3 mp4, 1 fast4speed, 1 sharepoint)
• The examples of the help text

[Derisis13]

Three questions:

1. why is calculating ct_len necessary (I want to understand why)
2. is wc -c correct all the time (eg. How do UTF-8 combinations get counted?) The first thing that came to my mind for the task was du, but I'm not sure it can work for our case.
3. Shouldn't we automate the key extraction from the complementary JS? IIRC we did it for V2 as well

[sahil-k-george]

These are some of the observations I had after cloning into the fix (Do let me know if I made any errors anywhere)

• From fix: allanime openssl aes-256-ctr decryption #1650 / ani-cli not working #1651 I decided to use the following commands mentioned there to download the 'fix' repo as it hasn't been currently merged.

git clone -b allanime-fix https://github.com/justchokingaround/ani-cli.git ani-cli-fix
sudo install -m 755 ./ani-cli-fix/ani-cli "$(which ani-cli)"
hash -r
ani-cli --version

Note, sudo was omitted in my case as I'm currently using termux without root.

• The output for ani-cli --version is as given below
  

• Searching for an anime that I am sure used to work gives the following result
  

[saimahendra282]

@sahil-k-george bro you did in correct way, now with just small change in code it will run here refer to this

#1665 (comment)

[sahil-k-george]

@sahil-k-george bro you did in correct way, now with just small change in code it will run here refer to this

#1665 (comment)

Ok, since I'm on Android right now, I'll also do an equivalent fix for termux and let you know in #1665

[sahil-k-george]

@sahil-k-george bro you did in correct way, now with just small change in code it will run here refer to this

#1665 (comment)

Ok, since I'm on Android right now, I'll also do an equivalent fix for termux and let you know in #1665

Update:-
The fix mentioned did not work in Termux. The output is still the same. Here's a screenshot of the code

[justchokingaround]

Three questions:

1. why is calculating ct_len necessary (I want to understand why)
2. is wc -c correct all the time (eg. How do UTF-8 combinations get counted?) The first thing that came to my mind for the task was du, but I'm not sure it can work for our case.
3. Shouldn't we automate the key extraction from the complementary JS? IIRC we did it for V2 as well

1. basically the blob size can vary if the ciphertext size is different, so it's safer to compute it (tldr; blob = [1][12][ciphertext][16] = [29 + ciphertext] and we need to exclude 16-byte GCM tag)
2. du returns block count (4KB chunks), not byte count. and yes wc -c is correct all the time, there's no UTF-8 issues
3. we can but it's not gonna be consistent, and it will break just as often. it's just more convenient and robust to have it be manual

[justchokingaround]

(and yes i had to look up du docs and references online for this, i didn't actually have that in mind)

[saimahendra282]

well @justchokingaround , @sahil-k-george i dunno about this stuff that much just shared what i did : ), hope it get fixes soon but it really works with windows after my change , so i shared it ...

[nethriondev]

where this key comefrom i cant find it on https://cdn.allanime.day/all/manga/a10191a.js

[justchokingaround]

in the file https://cdn.allanime.day/all/manga/83d4166.js you will find this function m at around line 7791 if u prettify the js. that's the first string array. the key is constructed by then rotating the array, then using it as a lookup into another array and converting the charcodes. it's just js deobf that i'm too lazy to explain in more details

[BishopWolf]

https://cdn.allanime.day/all/manga/83d4166.js

Isn't it better then to just parse the file and recover some keys

$ curl -s https://cdn.allanime.day/all/manga/83d4166.js | npx prettier --parser babel --stdin-filepath temp.js | awk '/importKey/{p=1} p; /\];/{p=0}'
            "importKey",
            "WUMcT",
            "hXKMM",
            "MJbkd",
            "NEPNI",
            "iqdXa",
            "oWlug",
            "cdjBR",
            "map",
            "OvVQp",
            "Unsupporte",
            "FNMqB",
            "nqvob",
            "izUlL",
            "set",
            "xDxPr",
            "9587304pPDucs",
            "uIqtx",
            "690336osMA",
            "jkDlP",
            "hJvPG",

[justchokingaround]

no

[manorit2001]

@justchokingaround I think you should plan for the updated keys instead of just saying "no"

You told key is not likely to change (#1650 (comment)) and it seems like the change still happened, it's better to future proof if there is any way and seems like @BishopWolf was suggesting something on similar lines ( am not sure if that can just work or not but i feel it's better to think on the lines of key changing more frequently than expected imo to avoid such PRs )

we can but it's not gonna be consistent, and it will break just as often. it's just more convenient and robust to have it be manual

I know you said this but as per me I feel it's worth a try atleast to go about that instead of just thinking that it's gonna break just as often.. but yeah, I would let @Derisis13 see as to how to keep ani-cli functional incase things like this happens.

[justchokingaround]

@justchokingaround I think you should plan for the updated keys instead of just saying "no"

You told key is not likely to change (#1650 (comment)) and it seems like the change still happened, it's better to future proof if there is any way and seems like @BishopWolf was suggesting something on similar lines ( am not sure if that can just work or not but i feel it's better to think on the lines of key changing more frequently than expected imo to avoid such PRs )

we can but it's not gonna be consistent, and it will break just as often. it's just more convenient and robust to have it be manual

I know you said this but as per me I feel it's worth a try atleast to go about that instead of just thinking that it's gonna break just as often.. but yeah, I would let @Derisis13 see as to how to keep ani-cli functional incase things like this happens.

they didn't change just the key, they also changed the offset, so even if there was a key extractor, it would still fail, so it would just be a big waste of time to spend hours writing a key extractor just for it to break over night. if u wanna do that but my guest, but I'm not gonna keep elaborating further on why that's a bad idea

[manorit2001]

So you'd keep updating keys overnight for it to be functional? ( Just trying to see how you envision it working as well.. )

[sahil-k-george]

Huh, I feel like both @justchokingaround and @manorit2001 are right.

• Yes it is useless to create a key extractor if it is gonna break at the next key change (if the offset changes, like this time.).
• At the same time, it might be tiresome to change the key at every change (given that the offset remains the same every time).

Also unrelated to this comment, (i.e., this is related to my previous comments), @saimahendra282 's fix did work for me on windows, now that I got around to check it out on the same. It still does not work on Termux. Now I have to check it on Linux too (hopefully within 3-4 hours of the time I've posted this comment.)

[sahil-k-george]

Also, how is the offset calculated in the first place, from

https://cdn.allanime.day/all/manga/83d4166.js
I'm not well versed in this, so help is much appreciated.

[manorit2001]

2 cents..

For dynamic flows where things are changing, there are llms around and maybe that can be incorporated in this repo

If it's a no go ( not sure what's the take on project with llm assisted workflows )

I'd say document how the key should be found and make it a user argument, but I feel this is where llms would come very handy when you can't solve things programmatically due to their dynamic nature.

[sahil-k-george]

2 cents..

For dynamic flows where things are changing, there are llms around and maybe that can be incorporated in this repo

If it's a no go ( not sure what's the take on project with llm assisted workflows )

(Correct me if I am wrong) I think this repo follows a strict No-AI/No-LLM policy. So, that might be a no-go.

Also regarding this:

I'd say document how the key should be found and make it a user argument, but I feel this is where llms would come very handy when you can't solve things programmatically due to their dynamic nature.

I was thinking of something else, once I know how the offset is calculated, I'll share my idea here. (Because it might be a waste of time discussing it, if the idea can't be implemented in the first place.)

[justchokingaround]

...

[port19x]

@sahil-k-george @manorit2001

Listen. The extraction does not change frequently.
Prior to this month, things went fine for well over a year.
If this becomes an actual issue to the point where they evade scraping by daily updates, we'd rather move providers.

Regarding LLMs, I do welcome LLM assisted contributions.
If you find ChatGPT or Grok better than Search Engines for remembering syntax or getting implementation hints be my guest.
Where I draw the line is fully AI generated code or PRs, as well as anything "agentic".
My stance is the most benevolent towards AI among the maintainers, so if you want to be on the safe side, eschew even LLM assistance, they suck for shell anyway.

I appreciate your eagerness to contribute.
Please have a look at #1575, which is an easy, low-stakes PR waiting to be implemented.

[sahil-k-george]

@sahil-k-george @manorit2001

Listen. The extraction does not change frequently.
...

(Rest contents removed for reducing the side of this message)

If it is not a frequent change then yeah, having a dedicated extraction mechanism is just bloatware atp.

Regarding LLMs, I do welcome LLM assisted contributions.
If you find ChatGPT or Grok better than Search Engines for remembering syntax or getting implementation hints be my guest.
...

(Rest contents removed for reducing the side of this message)

That is a great insight which I didn't know. I was a bit skeptical on where the line was drawn regarding the situation. So, now it's more clear on what is okay and what is not.

[CoolnsX]

So you'd keep updating keys overnight for it to be functional? ( Just trying to see how you envision it working as well.. )

It's not the keys they change, it's encrypted text padding, algorithm anything the possibility is infinite and we should not write a parser for something that's uncertain.

[manorit2001]

Regarding LLMs, I do welcome LLM assisted contributions.
If you find ChatGPT or Grok better than Search Engines for remembering syntax or getting implementation hints be my guest.
Where I draw the line is fully AI generated code or PRs, as well as anything "agentic".
My stance is the most benevolent towards AI among the maintainers, so if you want to be on the safe side, eschew even LLM assistance, they suck for shell anyway.

I think we differ on what I was suggesting actually, it wasn't on the lines of llm assisted contributions but it was more on the lines of llm going and finding this padding structure in code itself ( llm sdk being part of ani-cli repo ) to avoid the dynamic nature that we can't programatically solve today. But I understand at that point it's much better to move providers. It was just a suggestion as I mentioned.

The reason i came to this PR was as it was somewhat troublesome that it hadn't been working and I had updated to the last commit as well, but I again saw it not working so just came here instead of opening another issue and what not, and seeing the potential that it still can potentially fail even after this PR within few days, I would be happiest if that doesn't happen and really thankful for contribution of @justchokingaround and you all. But I just err'ed on the side that it does fail again with them changing things frequently and suggested things based on that.

[port19x]

Didn't test, just approved 😎

[port19x]

Several users are reporting it as working. Merge timing up to your discretion

[Derisis13]

Merged as it works right now