Summary
decode_tobeparsed() in ani-cli is broken. The function always fails to decrypt the tobeparsed blob from the Allanime API, causing the script to silently fall back to the POST endpoint (which often returns NEED_CAPTCHA errors).
Bugs Found
Bug 1: file_size always 0
file_size="$(wc -c /dev/null | od -A n -t x1 | tr -d ' \n')"
wc -c /dev/null returns 0. The intent was wc -c <"$tmp" to get the size of the decoded blob. This makes ct_len = 0 - 13 - 16 = -29, so dd count=-29 reads nothing.
Bug 2: iv variable never defined
The variable iv is never set anywhere in the function. It should be extracted from the first 12 bytes of the decoded blob (after the 1-byte prefix).
Bug 3: Missing IV extraction + wrong offset logic
The current blob format has a 1-byte prefix (0x01) followed by a 12-byte IV, then the ciphertext. The function needs to:
- Extract IV:
dd if="$tmp" bs=1 skip=1 count=12 2>/dev/null | od -A n -t x1 | tr -d ' \n'
- Decrypt from byte 13 onward:
dd if="$tmp" bs=1 skip=13 2>/dev/null | openssl ...
Root Cause
This looks like a regression from a merge/rebase of PR #1650. The PR by @justchokingaround had a correct implementation, but after merging, someone reintroduced these bugs and the variable name change got lost.
Verification
Confirmed with the actual API response (One Piece episode 1):
- Passphrase
Xot36i3lK3:v1 → SHA-256 key is correct
- Blob decodes to 33327 bytes
- IV at offset 1-12 (12 bytes), ciphertext from offset 13
- Decryption with
openssl enc -d -aes-256-ctr produces valid JSON with sourceUrl entries
Proposed Fix
Replace decode_tobeparsed() with:
decode_tobeparsed() {
tmp="$(mktemp)"
printf '%s' "$1" | base64 -d >"$tmp"
iv="$(dd if="$tmp" bs=1 skip=1 count=12 2>/dev/null | od -A n -t x1 | tr -d ' \n')"
ctr="${iv}00000002"
plain="$(dd if="$tmp" bs=1 skip=13 2>/dev/null | openssl enc -d -aes-256-ctr -K "$allanime_key" -iv "$ctr" -nosalt -nopad 2>/dev/null)"
rm -f "$tmp"
printf '%s' "$plain" | tr '{}' '\n' | sed -nE 's|.*"sourceUrl":"--([^\"]*)\".*"sourceName":"([^\"]*)\".*|\2 :\1|p'
}
Key changes:
- Remove the
file_size / ct_len calculation entirely (unnecessary — just pipe dd skip=13 directly)
- Extract
iv from bytes 1-12 (skip the 1-byte prefix)
- Use
skip=13 (1 prefix + 12 IV)
Summary
decode_tobeparsed()inani-cliis broken. The function always fails to decrypt thetobeparsedblob from the Allanime API, causing the script to silently fall back to the POST endpoint (which often returnsNEED_CAPTCHAerrors).Bugs Found
Bug 1:
file_sizealways 0file_size="$(wc -c /dev/null | od -A n -t x1 | tr -d ' \n')"wc -c /dev/nullreturns0. The intent waswc -c <"$tmp"to get the size of the decoded blob. This makesct_len = 0 - 13 - 16 = -29, sodd count=-29reads nothing.Bug 2:
ivvariable never definedctr="${iv}00000002"The variable
ivis never set anywhere in the function. It should be extracted from the first 12 bytes of the decoded blob (after the 1-byte prefix).Bug 3: Missing IV extraction + wrong offset logic
The current blob format has a 1-byte prefix (
0x01) followed by a 12-byte IV, then the ciphertext. The function needs to:dd if="$tmp" bs=1 skip=1 count=12 2>/dev/null | od -A n -t x1 | tr -d ' \n'dd if="$tmp" bs=1 skip=13 2>/dev/null | openssl ...Root Cause
This looks like a regression from a merge/rebase of PR #1650. The PR by @justchokingaround had a correct implementation, but after merging, someone reintroduced these bugs and the variable name change got lost.
Verification
Confirmed with the actual API response (One Piece episode 1):
Xot36i3lK3:v1→ SHA-256 key is correctopenssl enc -d -aes-256-ctrproduces valid JSON withsourceUrlentriesProposed Fix
Replace
decode_tobeparsed()with:Key changes:
file_size/ct_lencalculation entirely (unnecessary — just pipedd skip=13directly)ivfrom bytes 1-12 (skip the 1-byte prefix)skip=13(1 prefix + 12 IV)