Lately I have been getting very very frustrated by files containing a rar, which contains a password protected rar and a URL to visit to "get" the password. You really don't need to waste your time trying the URL. It has warning written all over it!
Is there a way for sabnzbd to check for that before downloading all the files? Or perhaps after downloading enough to determine that there is a password protected rar inside an unprotected one?
I can send you a sample if need be.
Could checking also check for a password rar inside a rar?
Re: Could checking also check for a password rar inside a ra
The are several detection methods already in SABnzbd, but scammers come up with
new ideas all the time.
You do need to enable the appropriate option in Config->Switches first.
If that doesn't help, email an example to [email protected]
new ideas all the time.
You do need to enable the appropriate option in Config->Switches first.
If that doesn't help, email an example to [email protected]
Re: Could checking also check for a password rar inside a ra
I would also like to chime in on this request. What Ive been seeing is a a group of RARs that NOT password protected, but the RARs inside ARE password protected. The Switch in Sabnzbd seems like it only checks the "outer" RAR file. Would be possible to add another Switch to check if there are RARs within a RAR?
Re: Could checking also check for a password rar inside a ra
There's a limit to what you test on the fly.
SABnzbd detects certain patterns, but it's always possible to come up with a different way of hiding encryption.
Typically I never get an answer when I ask for examples.
SABnzbd detects certain patterns, but it's always possible to come up with a different way of hiding encryption.
Typically I never get an answer when I ask for examples.
Re: Could checking also check for a password rar inside a ra
Current detection works for most things. I just need to manually put the last rar part at the start of the queue so it can check the beginning and end for password files. Maybe there could be an option to automatically put the last rar part at the start of the queue?
Re: Could checking also check for a password rar inside a ra
Encryption can be detected in all RAR segment files, so order doesn't matter.
Do you have an example that behaves different?
Do you have an example that behaves different?
-
yukichigai
- Newbie
- Posts: 8
- Joined: May 5th, 2013, 10:27 pm
Re: Could checking also check for a password rar inside a ra
This collection here does it:shypike wrote:Encryption can be detected in all RAR segment files, so order doesn't matter.
Do you have an example that behaves different?
http://binsearch.info/?b=game.of.throne ... 3E&max=250
Place the last segment of the rar file first and it'll detect it right off the bat. Leave the default order and it'll download 90% of it before it finds it.
Re: Could checking also check for a password rar inside a ra
seeing how scammers will always try to confuse the software can you just add really basic check for nested rars and give us the option of what to do with them if found?shypike wrote:The are several detection methods already in SABnzbd, but scammers come up with new ideas all the time.
ie exactly like the existing option for dealing with encrypted rars?
off - for those that dont care and want them all downloaded
pause - for those that may need them (in which case perhaps a list of files within the rar be displayed)
abort - for those that just dont want to deal with them
you can continue to update the smart auto processing but the above "sledgehammer" options would be very helpful in the mean time
Re: Could checking also check for a password rar inside a ra
How is this different from what is already in SABnzbd?
Your new idea is "really basic check for nested rars".
My experience is that such a basic test will generate lots of false positives,
without it being clear to the user what to decide.
Your new idea is "really basic check for nested rars".
My experience is that such a basic test will generate lots of false positives,
without it being clear to the user what to decide.
Re: Could checking also check for a password rar inside a ra
the detection of nested rars may be in the code already but its not user accessible, we cant determine what happens when thats encountered (as far as i am aware)shypike wrote:How is this different from what is already in SABnzbd?
yes, its a simple top level check, one i presume should be fairly simple to code in considering the existing checks already being done. and the user can then determine what happens.shypike wrote:Your new idea is "really basic check for nested rars".
sure, understandable for people that download certain stuff, it might cause too many issues, but thats the point of making it an option - default it to offshypike wrote:My experience is that such a basic test will generate lots of false positives,
without it being clear to the user what to decide.
if the majority of a users downloads end up being scams then theyll lower it to abort, if there are too many false positives then theyll turn it off.
you could even consider adding extra functionality like the encrypted rar handling where you can set the password via the job name, you could add a {{ALLOWNESTED}} override capability for those that only use it every now and then