Added reading passwords from file

[Holzhaus]

You can now create a password list (default is ~/.unrar_passwords), which is a simple text file containing archive passwords (separated by newlines). If an archive needs a password, then unrarall will read the file in a top down manner and try to use each password until it finds the correct one or reaches EOF.

Please note, that this commit removes the ability to get asked for a password and input it manually. IMHO this is not needed, as this tool is clearly designed for mass extraction and should not wait for user input (this is also why the '-y' option is used in the code). If you need to extract an archive with a password, just put it in the passwords file and remove the file afterwards (or just use plain unrar/7z).

This fixes arfoll/unrarall#13.

[arfoll]

Looks really nice! thanks! I'll try test this tonight and if you don't mind making SIGKILL -> SIGTERM/SIGINT I'll merge this in.

[Holzhaus]

I just found a bug. Some RAR archives also have encrypted headers. In this case, unrar l x.rar will request a password, too. I'll commit a patch soon.

[Holzhaus]

Done.

[nigg]

Nice work Holzhaus. :) I can use this feature a lot! Arfoll can you pls merge his commit to master branch?

[nigg]

I just tested that password feature and I did find a bug. If you are using 2 diffrent archive sets with 2 diffrent passwords the unrar process can use the wrong password and fails with the following error message: "Corrupt file or wrong password."

Short, the algorithm can't decide correctly which password to use, if the password list contains several password. :/

Can you pls fix this?

[Holzhaus]

Actually, this is true, but I don't see a solution for this problem. unrar/7z can't determine the password without trying to extract the archive. There is no other way for this.This is why unrarall performs these steps:

• Check if the archive is encrypted
  • If not: Extract with no password and continue
  • If yes: Try to extract with first password from password list
  • On success, continue
  • On failure, try to extract with next password from password list (repeat if neccessary)

This is the expected behaviour.

There might be some workarounds, e.g.:

• Use a password list that also contains the archive filenames In my opinion, this is a bit too complex. For my purposes, it would take too much effort to add every filename to the password list. You could use RegEx-filenames, but as long as I do not need that feature I won't implement it (and I still think this adds too much complexity).
• In case the file listing is not encrypted, unrarall could look for small files (<1MiB) and - if the archive contains such a file (.nfo, .txt, etc.) and try to extract just that (brute-forcing should be much faster if it doesn't try to extract the complete archive).
• In case the file listing is encrypted, too, unrarall could brute-force the passwords from the password list by trying to display the file listing only (which should be much faster) and then use that password for extraction.

I might implement the latter 2 workarounds at some point, but I'm too busy at the moment.

[Holzhaus]

@arfoll Are any stumbling blocks for merging left?

[arfoll]

Nope. Sorry I was being slow :). Nice work!