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

551–556 of 556 posts

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#551

Post by sim7c00 »

omnicognate wrote: post #487
dmazzoni wrote: post #477

Earlier quoted context omitted.

Is the behavior that a running .js script is fully loaded into memory and the file doesn't need to exist documented, supported behavior? What if, hypothetically, the system was suspended in the middle of script execution, and the resume function was designed to reload the script from disk? It just feels like a different hack to me. Also - trying 20 times and pausing 500 ms seems wasteful. What are the chances that it…

> Is the behavior that a running .js script is fully loaded into memory and the file doesn't need to exist documented, supported behavior? If Raymond Chen says to rely on it then yes.

even though i admot this guy is genious level, its not really good to rely on one persons judgement for anything. thats a bad practice in general. zerotrust and all :)

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#552

Post by sim7c00 »

chrchang523 wrote: post #489
dmazzoni wrote: post #477

Earlier quoted context omitted.

Is the behavior that a running .js script is fully loaded into memory and the file doesn't need to exist documented, supported behavior? What if, hypothetically, the system was suspended in the middle of script execution, and the resume function was designed to reload the script from disk? It just feels like a different hack to me. Also - trying 20 times and pausing 500 ms seems wasteful. What are the chances that it…

Agree, I'm shocked at how ugly the recommended alternative is. This does not make MS look good.

i am not shocked, but its hacky like comments suggested. ultimately done because the lack of a better alternative. id still follow chens advice even though its hacky.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#553

Post by sim7c00 »

monocasa wrote: post #459
sim7c00 wrote: post #436

Earlier quoted context omitted.

The first point is true i admit. There are very complex and good ways to identify stuff but those perform so bad they cannot be used in practice. AV/EDR products do try to prevent a lot of stuff. They can 'generically' block things like injection etc. by 'hooking all the things' and injecting into everything (yes, yuck :D and still kind of heuristic based i admit!) to make certain sections read only or remove executa…

If you're talking about LD_PRELOAD, I used it for an integration test suite of low level system components.

im not sure how the implementation of ld preload works, but this is a linker directive if i am correct. the thing i am on about is the DT_DEBUG dynamic table entry. its an entry meant to allow a debugging dll to be loaded. you can overwrite it and point it to a malicious dll (with a bit of difficulties) to get injection going. its then hardcoded into tue binary by your modification. admittedly maybe ld preload is easier if thats allowed on a system

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#554

Post by sim7c00 »

xp84 wrote: post #475
ChrisSD wrote: post #445

Earlier quoted context omitted.

The fact it injects into another process means they can't know if it'll crash or not. You're just one Explorer update away from things changing enough for the hack to crash it. I guess they could do this more robustly. I.e pause the entire explorer process, save all its state, remotely allocate new memory to inject their code, remotely create a new thread, run only that thread using the injected code, restore all the…

Agree completely. I would have assumed (naively?) that they could just copy their uninstaller into a temp folder and run it from there, and just rely on the OS to nuke it in due time, but as a consumer I appreciate the thoroughness of an uninstaller that leaves no trace.

honestly your idea about the tmp dir i think is better than the no trace option. especially given the hacky nature of self deleting stuff. if you have so many uninstallers around that the disk fills up the tmp.dir cleaning would fix it, which is a common first thing to clean when cleaning the filesystem. i like your idea :)

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#555

Post by sim7c00 »

darkclouds wrote: post #473
sim7c00 wrote: post #432

Earlier quoted context omitted.

They inject something into Explorer. I would assume that to be some DLL that is injected? ---- Neither code injection nor detouring is officially supported. I can’t tell who did the detouring. Maybe somebody added a detour to the uninstaller, unaware that the uninstaller is going to inject a call to the detour into Explorer. Or maybe the detour was injected by anti-malware software. Or maybe the detour was injected b…

>I can’t tell who did the detouring I was thinking hmm and so it continues that game of whack a mole. If a new OS could be designed from scratch, there must be a way to prevent this sort of stuff.

i am making an os from scratch. but admittedly, i am so far from this stuff i will never ever have anything even closely related to such a problem hah. its so much work :'( (fun tho!)

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#556

Post by pests »

sim7c00 wrote: post #553
monocasa wrote: post #459

Earlier quoted context omitted.

If you're talking about LD_PRELOAD, I used it for an integration test suite of low level system components.

im not sure how the implementation of ld preload works, but this is a linker directive if i am correct. the thing i am on about is the DT_DEBUG dynamic table entry. its an entry meant to allow a debugging dll to be loaded. you can overwrite it and point it to a malicious dll (with a bit of difficulties) to get injection going. its then hardcoded into tue binary by your modification. admittedly maybe ld preload is eas…

LD_PRELOAD is handled entirely by ld.so and includeed inside your ELF by the linker. It not only handles that but also all dynamic linking inside your program.

By writing a custom linker you can easily incercept all dynamic linking done at runtime and provide whatever you want to the program.

gcc -Wl,-dynamic-linker,/path/to/my/linker myprogram.c -o myprogram

Post reply on HN