Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Any sufficiently advanced uninstaller is indistinguishable from malware

devblogs.microsoft.com

Post reply on HN
Print view View original

491–500 of 556 posts

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#491

Post by brap »

highwaylights wrote: post #159
blackpill0w wrote: post #149

Why do Windows programs need special installers/uninstallers? Why isn't this handled by Windows itself?

I don't think any major desktop OS handles this well. I suspect the final form for software installation is probably where iOS and Android are going in the EU, where there's a single means of installing software to the device so that everything can be sandboxed properly, but the acquisition/update process can be pointed to a URL/Store that the user has pre-approved. macOS comes pretty close to what I'd ideally want i…

iOS is the gold standard IMO. Apps are sandboxed, can only interact with the outside world via APIs (that the user needs to approve), one click uninstall and it’s all gone without a trace (at least in theory). Love it.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#492

Post by GuB-42 »

blackpill0w wrote: post #149

Why do Windows programs need special installers/uninstallers? Why isn't this handled by Windows itself?

Besides the "special uninstaller" thing. One of the things I hate the most with Windows filesystem management compared to Unix-like OSes.

On Windows, opening a file locks it. So you can't delete a program that is running, you will get an error. It means of course that an executable can't delete itself without resorting to ugly tricks like the one mentioned in the article. That's also why you get all these annoying "in use" popups.

On Unix, files (more precisely: directory entries) are just reference-counted pointers to the actual data (inode on Linux), removing a file is never a problem: remove the pointer, decrement the reference counter. If the file wasn't in use or referenced from elsewhere, the counter will go to zero and the actual data will be deleted. If the file is in use, for example because it is an executable that is running, the file will disappear from the directory, but the data will only be deleted when it stops being in use, in this case, when the executable process terminates. So you can write your uninstaller in the most straightforward way possible and it will do as expected.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#493

Post by ripley12 »

RajT88 wrote: post #414
EvanAnderson wrote: post #292

Earlier quoted context omitted.

Windows has had an installer as an OS component since the late 90s (called Windows Installer). As a sysadmin I'd prefer apps use it. Many application developers do not. It's maddening. (Doubly so when Microsoft themselves don't use it-- newer versions of Office, Teams, etc. Microsoft suffers from too much NIH.) I get unattended installs and uninstalls "for free" when well-behaved applications use Windows Installer. P…

Can confirm. I would be considered by most to have been a Windows Installer expert at one point. Installshield / Wix / Whatever else. It is intentionally obtuse at times (MSIFileHash table uses rearranged MD5 hashes for example), and also many features made sense for the late 90's/Early 2000's era where bandwidth was low and connectivity limited, and lots of stuff was distributed on CD's. The look on people's faces w…

> It was deprecated by the newer AppX/MSIx/AppV format which uses sandboxes, binary chunks/streaming and no executable code to install stuff.

I can offer a little perspective on MSIX, having devoted months of my life to it in a past job.

MSIX is nearly unusable outside the Store. It will work in a tightly controlled environment, but when you try to deploy it to a wide variety of users you will run into 1) unhelpful errors that basically can't be diagnosed, 2) enterprise environments that cannot/will not allow MSIX installs. I get the impression that the MSIX team is uninterested in solving either of those issues.

It's not a coincidence that virtually no first-party teams use MSIX to install their product outside the Store. Office tried for a while and eventually gave up.

Despite all that, there are still a few people at MS who will tell you that MSIX is the future. I don't really understand it and I assume there's a weird political reason for this.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#495

Post by ripley12 »

mastax wrote: post #458
Tuna-Fish wrote: post #256

Earlier quoted context omitted.

The same way any linux distro does? Define a separate directory for program installations, that user processes cannot write to. Only program that can do so is the package manager, which other programs can call to install packages. Uninstall removes everything related to a program from this directory. > In the age of shared runtimes, auto-updaters, extension marketplaces, and JIT compilers, managing installed applicat…

This is exactly how AppX/MSIX packages work, with C:\Program Files\WindowsApps (by default) being pretty substantially locked down. They even use filesystem/registry virtualization by default to isolate packages even further from each other. They also have solutions for framework packages and extensions though I haven't tried those out and suspect they have annoying practical limitations around edge cases. Of course,…

I don't think MSIX is a good choice for most apps. With a decent-sized user base, you will have a lot of people who run into undiagnosable errors with MSIX or can't use it because they're in locked-down enterprise environments.

I think Affinity Photo's experience with MSIX is instructive; hundreds of negative results on their forum, eventually they had to back down and provide a non-MSIX installer (and at that point do ya really want to maintain 2 separate Windows installers?)

https://forum.affinity.serif.com/index.php?/topic/170529-ext... https://forum.affinity.serif.com/index.php?/search/&q=msix&t...

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#496

Post by javajosh »

tgtweak wrote: post #460

Dropping wscripts is a good way to get malware profiled too, and no way to code sign it or verify it's integrity before executing.

If your program creates the script and executes it, is verification necessary? This would be like verifying your 1st party scripts in a webpage that you wrote. It won't really hurt anything, but I'm not sure there's a point.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#498

Post by NoZebra120vClip »

Narishma wrote: post #306
NoZebra120vClip wrote: post #288

Earlier quoted context omitted.

> Yes. But if you stick everything into a single .exe, the user can't interfere. Alright cowboy, so where are you storing preferences and settings?

In the .exe, obviously.

Self-modifying code is the most exciting type of user preference!

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#499

Post by EustassKid »

GuB-42 wrote: post #492
blackpill0w wrote: post #149

Why do Windows programs need special installers/uninstallers? Why isn't this handled by Windows itself?

Besides the "special uninstaller" thing. One of the things I hate the most with Windows filesystem management compared to Unix-like OSes. On Windows, opening a file locks it. So you can't delete a program that is running, you will get an error. It means of course that an executable can't delete itself without resorting to ugly tricks like the one mentioned in the article. That's also why you get all these annoying "i…

I feel like this is some stupid question but aren't exexutables and their libraries loaded to RAM? If yes then why can't it just delete itself (from disk)?

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#500

Post by Arainach »

xg15 wrote: post #63
8organicbits wrote: post #29

Here's the codeproject link the code came from. https://www.codeproject.com/Articles/17052/Self-Deleting-Exe... > Whether they follow the licensing terms for that code I do not know. I'm guessing they didn't ship the binary with a link pointing back to this page? These's also another codeproject example that uses a bat file, which is fairly similar to the recommendation in the post. I guess that's the better example.…

At least the author seems to agree with Raymond Chan on the similarities between his approach and malware... > shellcode is the technical term (in security circles) for binary machine code that is typically used in exploits as the payload. Here's a quick and dirty way of generating the shellcode from the obj file generated when you compile your source files. In our case, we are interested in whipping the shellcode up…

Nit: Raymond Chen, not Chan
Post reply on HN