I’m probably missing something but why is an uninstaller allowed to inject code into explorer.exe? That seems like a massive security flaw?
It's never a security flaw that a program running with administrator privileges is allowed to do something.
Any sufficiently advanced uninstaller is indistinguishable from malware
61–70 of 556 posts
Re: Any sufficiently advanced uninstaller is indistinguishable from malware
#62Earlier quoted context omitted.
I can't speak for whether Apple gets it right, but my experiences with the various package managers on Linux have not been any better than my experiences with installers on Windows. I've settled for avoiding system packages for anything I can build from source since system packages are always outdated and often Strange, and I try to avoid third party package sources and weird stuff like Snap or Flatpak since it's als…
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.
YMMV. I just bricked a Debian install last month by using the package manager to install display drivers then trying to uninstall it to try a different driver. Had to go editing files in the console on a 4k display and just cross my fingers.
Re: Any sufficiently advanced uninstaller is indistinguishable from malware
#63Here'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 for the remote_thread routine. Here's what you've got to do:
The whole article has the vibes of some questionable DIY blog along the lines of "Your house is infested by vermin? Here is an easy way to get rid of them using a small, homebuilt neutron bomb!"
Re: Any sufficiently advanced uninstaller is indistinguishable from malware
#64Earlier quoted context omitted.
I thought I'll be the guy to point out that once again mandatory file locking is to blame, but you beat me to it. I never digged into the question, but why is it used, what benefits did it provide over the UNIX unlink behaviour?
> I never digged into the question, but why is it used, what benefits did it provide over the UNIX unlink behaviour? How do you defragment/move files that are unreachable on the file system? How do you shrink volumes when you can't move files that need to be moved? Edit: Actually, hmm... as I type this, I suddenly recall you can also open a file by its ID on NTFS. And you can enumerate its streams as well. So presuma…
You don't? Those are either free space, or held by handle by a running process, so you just leave them be and assume they will be released sooner or later. Worst case you defragment on boot.
https://unix.stackexchange.com/questions/68523/find-and-remo...
This is how it works on UNIX. Generally better then apps randomly failing because a file(name) is held open somewhere by something.
Re: Any sufficiently advanced uninstaller is indistinguishable from malware
#65I can only imagine the Win32 API team meeting prior to this... A: So, people are resorting to injecting code in Explorer to delete in-use files in such numbers that it shows up in our top-100 crash report reasons B: Well, maybe we should add a public API to Windows to support this incredibly common functionality that apparently has been missing so far? A: Nah, let's just write a mildly condescending blog post that re…
Well, they kinda had to rush that meeting because they spent too much time on the previous meeting listing all the reasons why the microsoft store is a functioning package system and not at all a din of inequity.
Re: Any sufficiently advanced uninstaller is indistinguishable from malware
#66Earlier quoted context omitted.
> I never digged into the question, but why is it used, what benefits did it provide over the UNIX unlink behaviour? How do you defragment/move files that are unreachable on the file system? How do you shrink volumes when you can't move files that need to be moved? Edit: Actually, hmm... as I type this, I suddenly recall you can also open a file by its ID on NTFS. And you can enumerate its streams as well. So presuma…
You don't? Those are either free space, or held by handle by a running process, so you just leave them be and assume they will be released sooner or later. Worst case you defragment on boot. https://unix.stackexchange.com/questions/68523/find-and-remo... This is how it works on UNIX. Generally better then apps randomly failing because a file(name) is held open somewhere by something.
> You don't? Those are either free space, or held by handle by a running process, so you just leave them be and assume they will be released sooner or later.
Well that's what I was getting at, it would suck to not be able to move around file blocks just because a process is using the file. That "sooner or later" might well be "until the next reboot". The current strategy makes it possible to live-shrink and live-defragment volumes on Windows - ironically, saving you a reboot in those cases compared to Linux.
But actually, maybe not - see the edit in my original comment.
Re: Any sufficiently advanced uninstaller is indistinguishable from malware
#67I can only imagine the Win32 API team meeting prior to this... A: So, people are resorting to injecting code in Explorer to delete in-use files in such numbers that it shows up in our top-100 crash report reasons B: Well, maybe we should add a public API to Windows to support this incredibly common functionality that apparently has been missing so far? A: Nah, let's just write a mildly condescending blog post that re…
There are already many services and APIs for doing this. It’s more like:
A: There are a dozen ways to do this correctly. Which right way should we pick?
B: I don’t know, I found this code on the internet. Should I just use it?
A: Sure, if it’s on the internet it must be the right way.
Re: Any sufficiently advanced uninstaller is indistinguishable from malware
#68Earlier 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.
With enough conditional evals() with dynamic inputs you can make the search space unsearchable big.
Re: Any sufficiently advanced uninstaller is indistinguishable from malware
#69...or maybe Windows should just offer an API for marking a file for deletion once it's not in use anymore (I understand unlink semantics may not be possible, but that's not what my suggestion above is saying)
Windows do have this API, NtDeleteFile, AND it could be used to delete current running exe.
https://twitter.com/jonaslyk/status/1345167613643661312
but it is undocumented...
Re: Any sufficiently advanced uninstaller is indistinguishable from malware
#70I can only imagine the Win32 API team meeting prior to this... A: So, people are resorting to injecting code in Explorer to delete in-use files in such numbers that it shows up in our top-100 crash report reasons B: Well, maybe we should add a public API to Windows to support this incredibly common functionality that apparently has been missing so far? A: Nah, let's just write a mildly condescending blog post that re…
Schedule a cronjob / win equiv