Renaming Obfuscated Files With Auto UnRar

[ovalseven]

If Auto UnRar is enabled and you have your unrar directory set to \$(NZBFILE)\, Newsbin will also rename the file. This is the desired behavior.

If you disable Auto unRar, then right-click to unpack from the file list, Newsbin still names the folder properly, but does not rename the file. Is this by design?

[Quade]

The rename is part of autopar. When you disable it or bypass it, you lose that function. That's not to say it can't be added but primarily Newsbin is intended to run with autopar enabled.

I can write a note to consider adding that to manual unrar. One issue with adding it is that once a file gets entered into the files list, it doesn't know about the NZB anymore. It could only work from the download list.

[ovalseven]

It's good the way it is right now. But since turning auto-unrar on/off is a multi-step process, I was looking at ways to deal with it always turned off.

A disadvantage to leaving is "always off" is that your obfuscated files don't get renamed to match the nzb.

Disadvantages to "always on" is that you can't manually scan for viruses before unpacking suspicious archives. Plus, there are occasions when you want to just save the archives for extracting at a later date.

I'll likely still make the switch from NewsLeecher and just deal with opening the settings menu each time I import a nzb.

[Quade]

Yeah, you want the rename after unrar but you don't want the unrar without V scan. It's sort of a chicken or egg problem.

I will say I've never seen a virus that could get triggered just from unraring so, if you let it unrar,rename and then you scan, I suspect you'll still be safe. It's not virus landing that infects you. It's invoking them ( I know it's not 100% since Windows will attempt to scan most media files for content).

[WhatZit]

I will say I've never seen a virus that could get triggered just from unraring ...

There was that recent and surprising/alarming RAR critical vulnerability where an attacker could use archaic ACE encoding to embed absolute paths into archives which then pretended to be RAR.

So, upon an un-RAR operation, files could get extracted/overwritten anywhere on your system that had the user's level of write access (e.g. C:\Users\Default), rather than the specified unpack directory.

Luckily, once discovered, RARLabs quickly removed this vulnerable ACE support, but I've been worried about something similar ever since.