SABnzbd Forums

version:
0.7.16

error message:
xx_xxxxxxxx_{{31edaSPRTF}Rvsvg4tgS}RGT$£T}} - Unpacking failed, archive requires a password

the password is:
31edaSPRTF}Rvsvg4tgS}RGT$£T

How did the job enter the queue?

nzb built with binsearch.info, and saved to sabnzbd watch folder as xx_xxxxxxxx_{{31edaSPRTF}Rvsvg4tgS}RGT$£T}}.nzb

p.s. sabnzbd running on os x 10.8.5
files were manually unrared using the password

$ python
Python 2.7.2 (default, Oct 11 2012, 20:14:37)
[GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] on darwin

p.s.II
I also have trouble with passwords that begin or end with a space or a tab, the tabbed passwords are saved to passwords.txt

There's an additional } in the password. Currently that's not supported.
That could maybe improved with a change in the software/
Embedding spaces and tabs is a bit of a challenge as many file systems don't support those.
I'll see what I can do.

I also noticed the testing of keys in the password.txt file is way too slow
using `unrar lb` instead of `unrar e`, will return the test results in a msec
$ unrar lb -p"pass word" "The Best Video Ever Made.rar"
using quotes around the password lets you embed any characters in the password, and using the password.txt file instead of adding {{foobar}} to the end of a filename, bypasses any filesystem limitation.

Nice idea. How much faster is that for you though? I've tested it with a script (below) and it's not noticeably faster than trying to unpack. I've tried with 15 passwords and even echoed 3 to drop_caches before, with a 300mb file. Maybe that was only in an old version of unrar?

while true; do read password || break
unrar lb -inul -p"$password" "$1" && echo "$password is good" && \
unrar x -o+ -inul -p"$password" "$1" && exit 0
echo -n .
done < passwords.txt