Live data from Hacker News

Any sufficiently advanced uninstaller is indistinguishable from malware

devblogs.microsoft.com

531–540 of 556 posts

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#531

Earlier quoted context omitted.

I think maybe you should familiarise yourself with how e.g. ext4 works. You can unlink a file and have a process still hold a reference to the inode. This allows you to continue reading (or executing) a file which may not have been fully mapped yet even after its last filesystem reference is gone. There really isn't that much of a good reason to disallow deleting the files (assuming NTFS is capable of supporting a si…

What happens when you run an executable from a FAT formatted partition under Linux, then I would guess Linux also no longer allow deleting the file while it is running, right? In the end this is a feature of the file system, can you delete open files?

On Linux you can unlink open files even on a FAT formatted partition (I just tried it with busybox).

It's actually quite intriguing how this works.

When you delete a file on FAT it seems to remove the directory entry, but does not update the free space information and doesn't free the clusters. If you run a fsck.fat on a filesystem in this state, it frees up the space (likewise, if you just let the process exit and unmount the disk normally, this space is also freed).

Presumably the information about where the file exists is only kept in RAM once you delete the directory entry. This should be sufficient to let anyone with an open file handle etc to keep reading it (including the kernel reading additional pages of the executable).

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#532

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

It's hardly specific to Windows. All the major Linux distros have excellent package management systems, and yet many, many packages and applications choose to ignore these in favour of party solutions, scripts, or even curl https://not-malware.trustme.lol | sudo bash style hodgepodge.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#533

Earlier quoted context omitted.

I think maybe you should familiarise yourself with how e.g. ext4 works. You can unlink a file and have a process still hold a reference to the inode. This allows you to continue reading (or executing) a file which may not have been fully mapped yet even after its last filesystem reference is gone. There really isn't that much of a good reason to disallow deleting the files (assuming NTFS is capable of supporting a si…

1. I know how Ext4 works in this case, and I don't care. 2. I already explained how I would like the system to respond. Ext4 or any other filesystem have nothing to do with it. 3. Processes don't hold references to inodes. That's nonsense (simply because there's no such thing as a "reference to inode" in any system interface). Process doesn't get a reference to the file from which its executable code is loaded at all…

I wasn't replying to you.

Also, #3 is just unnecessary nitpicking.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#534
post #193

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.

Persistent user-specific state needs to live in a persistent user-specific location. You could choose not to use the concept of a home directory, but you would be doomed to reinvent it.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#535
post #516

Imagine if Windows just allowed DeleteFile() even if the file was open, like unlink() on almost any other OS...

It does. But this issue arises because of file locks. Running an executable holds a lock that prevents deletions (but not renames).

Many OSes have file locks, though they often don't use them as liberally as Windows.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#536

Earlier quoted context omitted.

It more or less doesn't in MacOS, and has NEVER really been a thing. While there ARE some tools that require a more invasive "installation" process (e.g., VMWare Fusion), the overwhelming majority of Mac software is installed by just dragging the application bundle into /Applications. (App bundles are just special directories, more or less, so you're moving more than just the file, but it presents as a single thing.)…

It's a bit weird to act as if macOS didn't have installers and uninstallers. For one thing, there's the App store. And then, probably most developers use something like homebrew. What you describe works for a specific kind of app, the ones that can be easily sandboxed and don't have shared dependencies.

Sounds like you don't understand that Mac world very well. That's okay.

D/ls from the store do what I describe above. The overwhelming majority of Mac apps going back to the pre-MacOS / OSX days work exactly as I described above.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#537

The guys at MS are smart enough to decompile assembly but still not enough to have a proper inode-based filesystem where you can delete files that are in use.

It has little to do with the filesystem. Windows has OS level locks. In the case of a running executable, the mapped memory holds a lock on the exe file to prevent deleting it. This is intentional. If it didn't hold the lock then it would be possible to delete the exe file on modern versions of Windows. Edit: since there still seems to be confusion I'll try to be clearer. On NTFS you can delete an open file. This is…

I didn't know about the lock. What happens when you delete an open file in NTFS? Is the data still accessible for programs that have the file open? If yes, then why the lock. If not, then that's a problem.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#538
post #125

Earlier quoted context omitted.

> There are already many services and APIs for doing this I... don't think so? The particular problem here, is that an uninstaller executable needs to delete itself from disk after doing its main job. Other than using MoveFileEx with a NULL destination file and the MOVEFILE_DELAY_UNTIL_REBOOT flag, then suggesting/forcing a reboot, I can't think of a straightforward solution. And that solution instantly lights up you…

>Other than using MoveFileEx with a NULL destination file and the MOVEFILE_DELAY_UNTIL_REBOOT flag, then suggesting/forcing a reboot, I can't think of a straightforward solution. And what's the problem with this?

> And what's the problem with this?

That solution instantly lights up your JIRA with 2 tickets: #1: We MUST not suggest/force a reboot! Users hate it! #2: CRITICAL BUG: uninstaller.exe still present after uninstalling product

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#539
post #63

Earlier quoted context omitted.

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

Ah, I'm sorry. That happens when you write messages on the go... seems too late to edit the message though unfortunately.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#540
Well maybe if Windows applications were packaged similar to MacOS (one of the few things I like) with the application data and user data for the application in 2 folders then it wouldn't be such an issue.

Most Windows apps sit under program files, some sit directly on drive root. But all spray configuration/user data files for themselves all over the damn place, requiring unique uninstallers.

MS, build app install/uninstall into Windows directly...

Post reply on HN