Any sufficiently advanced uninstaller is indistinguishable from malware • Hacker News Board

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#191

Post by alexvitkov » Wed, Sep 13, 2023, 9:10 AM UTC

The idiomatic way write an uninstaller

1. Clean up whatever you can in the uninstaller. If you're a decent human being this includes the registry, appdata, temp, and a toggle to delete wherever your app spews its config.

The only thing left should be the uninstaller .exe and the directories leading up to it, since Windows doesn't allow you to unlink a exe/dll that's loaded in memory. Your uninstaller should be static linked so it doesn't need to clean up its own .dlls.

2. Figure out how to delete the uninstaller. This can either be some stack smashing butt clenching fuckery, like the guys from the article did or you can be a normal fucking person and just atexit() a batch script in that does

    SLEEP 5
    RMDIR program_dir /whatever /flags /needed

The SLEEP is to ensure the uninstaller is closed

You can put the batch script in %TEMP% and hope something will clean it up, or if you're feeling extra nice you can set up an action to get it cleaned up at next boot.

After that you're also equipped to write self-deleting malware, which is a far more applicable skill.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#192

Post by goodpoint » Wed, Sep 13, 2023, 9:13 AM UTC

yankput wrote: post #172

tetris11 wrote: post #153

Earlier quoted context omitted.

One thing I like about Linux package managers is that you can query any file to see which package owns it. How does Windows not track this?

Except they all leave files everywhere in ~, ~/.cache, ~/.config, ~/.whatevertheyfeellike

That's a feature so that users can keep configuration files and even move them across systems.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#193

Post by daemin » Wed, Sep 13, 2023, 9:13 AM UTC

parchley wrote: post #188

yankput wrote: post #172

Earlier quoted context omitted.

Except they all leave files everywhere in ~, ~/.cache, ~/.config, ~/.whatevertheyfeellike

Those files are user data, not part of the software package.

I would disagree, files that the user cannot edit or should not edit should not be going into their home directory. Things like cache files should go into a system wide cache directory instead.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#194

Post by sim7c00 » Wed, Sep 13, 2023, 9:14 AM UTC

yjftsjthsd-h wrote: post #60

Roark66 wrote: post #20

Earlier quoted context omitted.

It is very common for malware to contain java script payloads that try to obfuscate themselves like like this: Seemingly_random_code(seemingly_random_string) The seemingly_random_code decompresses/decodes whatever is in the seemingly_random_string and hands over control to it. Interestingly the decoded code is another version of the same with different code and string. This goes on for ~100 layers deep then at the en…

> This goes on for ~100 layers deep then at the end it just downloads and executes some file from the net. I understand doing one layer. I guess I could maybe see two layers. But why would it bother with 100 layers? Either the antivirus or reverse-engineering tool can grab the final product or it can't.

Because of potential false positives, and the speed at which files need to be analyzed at runtime (suspend process executing it and then analyze it), having files which take a long time to unpack and identify can cause these to be allowed to run. They get offloaded to a sandbox or other systems to be analyzed while the file is already being executed. The sandboxes are too slow to return a verdict before the main logic of the file will be executed. IF those dynamic systems cannot identify a file, an engineer will manually need to look at it.

In very strict environments or certain systems it might be practical to block all unknown files, but this is uncommon for user systems for example where users are actively using javascript or macro documents etc. (developers, HR, finance etc.) The FP rates are too high and productivity can take a big hit. If all users do 20% less work that's a big loss in revenue (the productivity hit can be much more severe even!). perhaps this impact / loss of revenue ends up being bigger than a malware being executed depending on the rest of the security posture/measures.

technically its possible to identify (nearly?) all malware by tracking p-states/symbolic execution/very clever sanboxing etc.. but this simply takes much too long. Especially if the malware authors are aware of sandboxing techniques and symbolic execution and such things as they can make those processes also take extra long or sometimes even evade them totally with further techniques.

I wish it _was_ possible to do all of the cleverness that malware researchers have invented to detect things, but unfortunately, in practice this cannot happen on like 90+% of environments.

If you run like a DNS server or such things, it's possible to do it as such a system would not be expected (ever?) to have unknown files. (gotta test each update and analyze new versions before deploying to prod). As you can imagine, this is also kind of a bummer process but imho for such 'static' systems its worth it.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#195

Post by elaus » Wed, Sep 13, 2023, 9:17 AM UTC

alexvitkov wrote: post #191

The idiomatic way write an uninstaller 1. Clean up whatever you can in the uninstaller. If you're a decent human being this includes the registry, appdata, temp, and a toggle to delete wherever your app spews its config. The only thing left should be the uninstaller .exe and the directories leading up to it, since Windows doesn't allow you to unlink a exe/dll that's loaded in memory. Your uninstaller should be static…

That is pretty much the suggested solution at the end of the article. There, the author also removes the temporary script.

The solution really isn't that hard, it might just feel a bit "dirty" (using a scripting language to do some work). But all that "stack smashing butt clenching fuckery" surely is much worse and less stable, so I'm not sure why one would even go that way...

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#196

Post by quietbritishjim » Wed, Sep 13, 2023, 9:18 AM UTC

alexvitkov wrote: post #191

The idiomatic way write an uninstaller 1. Clean up whatever you can in the uninstaller. If you're a decent human being this includes the registry, appdata, temp, and a toggle to delete wherever your app spews its config. The only thing left should be the uninstaller .exe and the directories leading up to it, since Windows doesn't allow you to unlink a exe/dll that's loaded in memory. Your uninstaller should be static…

> You can put the batch script in %TEMP% and hope something will clean it up, or if you're feeling extra nice you can set up an action to get it cleaned up at next boot.

If you can set an action to get something deleted at next boot why not use that to delete your uninstaller itself, rather than adding an extra layer of indirection?

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#197

Post by amenghra » Wed, Sep 13, 2023, 9:18 AM UTC

daemin wrote: post #193

parchley wrote: post #188

Earlier quoted context omitted.

Those files are user data, not part of the software package.

I would disagree, files that the user cannot edit or should not edit should not be going into their home directory. Things like cache files should go into a system wide cache directory instead.

Cache files might contain user's sensitive data. Makes sense to keep in them in the user's home directory in those cases.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#198

Post by mananaysiempre » Wed, Sep 13, 2023, 9:20 AM UTC

xxs wrote: post #178

spatulon wrote: post #171

Earlier quoted context omitted.

> Any open file Any file that was opened without specifying FILE_SHARE_DELETE in the call to CreateFile[1] (the Win32 equivalent of open(2)). Unfortunately, most language runtimes that wrap CreateFile tend not to pass that flag. [1] https://learn.microsoft.com/en-us/windows/win32/api/fileapi/...

indeed - also reminds me that languages like go[0] and java[1] did disagree to even attempt using it [0]: https://github.com/golang/go/issues/32088#issuecomment-53759... [1]: https://bugs.openjdk.org/browse/JDK-6607535 So to me it's just not there...

Apparently some parts of this are quite recent, huh[1]:

> jstarks commented on Jun 18, 2019:

> [I]n the most recent version of Windows, we updated DeleteFile (on NTFS) to perform a "POSIX" delete, where the file is removed from the namespace immediately instead of waiting for all open handles to the file to be closed.

[1] https://github.com/golang/go/issues/32088#issuecomment-50285...

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#199

Post by pbhjpbhj » Wed, Sep 13, 2023, 9:21 AM UTC

FirmwareBurner wrote: post #92

omgmajk wrote: post #37

Earlier quoted context omitted.

I don't quite get this, I've been using Debian-esque Linux since like 1997 in various forms and have had problems with apt-get/apt maybe five times since then in total and it's always fixable with a little work. I've seen this a lot and I've haven't really understood the problems. I saw Linus from LTT brick his installation (in Pop_OS! I think?) but that was a clear user error.

>but that was a clear user error A user error that can happen to any user who isn't Linux savvy and just wants to paly games, and not learn how a package manager works, and that it can uninstall your desktop environment if you aren't proficient with Linux, is no user error but OS error. How many MacOS or Windows users expect that going through the installation steps of Steam, it can uninstall your desktop environment…

There was a Steam package error, the error warned it might be temporary, the installer said it wouldn't continue because that would remove "popos-desktop" amongst other things.

So, he opened a console (like any user?), then used apt-get ... which had a WARNING ... "This should NOT be done unless you know exactly what you are doing!". He then had to type "Yes, do as I say!" in order to "do something potentially harmful" ... and then, what a surprise it did something harmful!

That's a user error that will only happen to people who are cocky, people who are idiots, or people trying to firm up their long held stance that 'Linux isn't for gaming'.

I saw the LTT video the following day to release, loaded a VM up, installed Pop_OS (my first time) and installed Steam, no issues. Very simple. All button clicking.

>going through the installation steps of Steam //

That's mis-characterisation, he went through the Steam install steps (click install by the Steam icon), the OS told him there was an error and refused to do it. End.

Then he went sudo-ing and ignoring warnings. "You can delete System32 this OS isn't ready for users!".

You'll tell me now installs never fail on Windows, presumably, despite having experienced them myself.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#200

Post by alexvitkov » Wed, Sep 13, 2023, 9:21 AM UTC

quietbritishjim wrote: post #196

alexvitkov wrote: post #191

The idiomatic way write an uninstaller 1. Clean up whatever you can in the uninstaller. If you're a decent human being this includes the registry, appdata, temp, and a toggle to delete wherever your app spews its config. The only thing left should be the uninstaller .exe and the directories leading up to it, since Windows doesn't allow you to unlink a exe/dll that's loaded in memory. Your uninstaller should be static…

> You can put the batch script in %TEMP% and hope something will clean it up, or if you're feeling extra nice you can set up an action to get it cleaned up at next boot. If you can set an action to get something deleted at next boot why not use that to delete your uninstaller itself, rather than adding an extra layer of indirection?

As far as I remember the thing you use to delete the file on next boot does not run arbitrary code, but is a special "rename-like" action that you can't use to recursively delete the folder of your program.

edit: https://learn.microsoft.com/en-us/windows/win32/api/winbase/...

It's the MOVEFILE_DELAY_UNTIL_REBOOT flag. Honestly maybe you can call MoveFileA on the entire directory tree you want to delete starting from the .exe and spare yourself the script, I don't see an obvious reason why it wouldn't work.