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

171–180 of 556 posts

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#171

Post by spatulon »

xxs wrote: post #142
tankenmate wrote: post #81

I keep forgetting Windows-isms that won't allow you to delete the executable file of a running process. I guess that's also why the arcane .dll upgrade process / WoW is so necessary.

>won't allow you to delete the executable file Any open file

> 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/...

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#172

Post by yankput »

tetris11 wrote: post #153
blackpill0w wrote: post #149

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

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

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#173

Post by tobias3 »

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…

You are basically describing what Windows has as appx/msix. The decentrialized notarization authorities are the code signing certificate providers.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#174

Post by dataflow »

hardware2win wrote: post #118
dataflow wrote: post #35

You can't rely on JScript being present unfortunately. It can be disabled.

What can you rely on then?

Uhm, for uninstallers? How about Windows Installer?

If you mean in other contexts... I think the point is you're not intended to be able to do this? Outside of uninstallers, running code that only exists in RAM is... the type of thing malware typically wants to do more than anything else.

But in terms of what's physically possible, I suppose there's the command prompt, PowerShell, and scheduled tasks? I'm not sure if all of those can be disabled.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#175

Post by alaxapta7 »

IshKebab wrote: post #128
coldtea wrote: post #54

Earlier quoted context omitted.

Detours is a library for instrumenting arbitrary Win32 functions Windows-compatible processors. Detours intercepts Win32 functions by re-writing the in-memory code for target functions. The Detours package also contains utilities to attach arbitrary DLLs and data segments (called payloads) to any Win32 binary. Detours preserves the un-instrumented target function (callable through a trampoline) as a subroutine for us…

Interesting. Has anyone done the same thing on Linux?

I use and recommend subhook[0].

[0] https://github.com/Zeex/subhook

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#176

Post by mananaysiempre »

vidarh wrote: post #169
jraph wrote: post #124

Earlier quoted context omitted.

> they always built their own binary > Think of it as they had a fork of Firefox Yep indeed, you are right. Notable projects using actual XULRunner included Songbird (a music player) and BlueGriffon, an WYSIWYG HTML editor (a successor of Nvu and KompoZer, themselves succeeding Netscape Composer). Both released after 2006 indeed. I liked XUL, I strongly believe Mozilla could have dominated the market taken by Electro…

There was an experiment back in the hazy past around that time called Entity that did something similar. It was never complete enough to be a competitor to XULRunner, but it was fascinating for two reasons: 1) You could write event handlers in multiple languages, including C. If you wrote them in C, it spawned gcc and compiled it into a library, and dynamically loaded it... The overall idea of a polyglot runtime like…

> The overall idea of a polyglot runtime like that was fun.

Active Scripting, which powers scripts in both WSH and old-school IE including HTAs, is polyglot and extensible. It’s why Active{Perl,Python,Tcl} are called that—the original headline feature (IIUC) was that they integrated with it. It’s also why you could write VBS in IE: IE just passed the text of the script along with the language attribute to AS and let it sort things out.

Nobody did ever a C interprerer, though, I think—perhaps because you basically have to speak COM from Active Scripting, and while speaking COM from C is certainly possible it’s nobody’s idea of fun. (An ObjC-like preprocessor/superset could definitely be made and I’ve heard that Microsoft had even entertained the idea at the dawn of time, but instead they went with C++, and I haven’t been able to find any traces of that project.)

That’s not to say AS is perfect or even good—the impossibility of caching DISPIDs[1], in particular, seems like a design-sinking goof. And the AS boundary was also why DOM manipulation in IE was so slow.

[1] https://ericlippert.com/2003/09/16/why-do-the-script-engines...

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#177

Post by phire »

PreInternet01 wrote: post #53

I 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…

A new API would only work in fully updated versions of windows that include the API.

Programmers would hesitate to use it, because they can't be sure the user of the uninstaller will be on a fully updated windows install.

The JScript workaround might seem like a bit of a hack, but it has an advantage of working on every version of windows all the way back to Windows 98.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#178

Post by xxs »

spatulon wrote: post #171
xxs wrote: post #142

Earlier quoted context omitted.

>won't allow you to delete the executable file Any open file

> 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...

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#179

Post by highwaylights »

tobias3 wrote: post #173
highwaylights wrote: post #159

Earlier quoted context omitted.

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…

You are basically describing what Windows has as appx/msix. The decentrialized notarization authorities are the code signing certificate providers.

I had not seen this, but it absolutely does (on the surface) seem like a solution to this problem. Thanks!

I’d need to educate myself a bit more in terms of whether there are third-party authorities beyond Microsoft for the packages.

Found this introductory video for anyone else interested:

https://www.youtube.com/watch?v=phrD081sMWc

Note: I didn’t intend the Surface pun above, but it happened and we can all be glad that it did.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#180

Post by tsimionescu »

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.

Typically scanning tools have some limit to how much they probe complex formats, to avoid stalling the entire system while they're scanning. It's very much conceivable that a scan tool will try to resolve code like this for 10 layers, and then if the result is not found to be malicious, consider it safe.

This is similar to how compilers will often have recursion limits for things like generics, though in that case it's easier to reject the program if the recursion limit is reached.

Post reply on HN