Disabling kernel functions in your process (2009)

https://chadaustin.me/2009/03/disabling-functions/

by rolph • 1 year ago

47 16 1 year ago

unilynx• 1 year ago

Cool solution, but I'd assume/hope Windows currently has sufficient memory protections to not allow applications to rewrite their own memory - especially if the function was already in a DLL to begin with and not JIT-generated code?

TonyTrapp• 1 year ago

Code segments are not writeble by default on Windows, like on any modern OS, but you can make any memory segment in your own process writable using VirtualProtect. That is not unique to Windows as well, on Linux you could achieve the same with mprotect.

dwattttt• 1 year ago

As sibling notes, executable memory is not by default writable. If desired, you can also further disallow any executable memory to me allocated or modified by your process, even via the normal APIs, by calling SetProcessMitigationPolicy with ProcessDynamicCodePolicy.

https://learn.microsoft.com/en-us/windows/win32/api/processt...

p_ing2• 1 year ago

The exception to this is if you're leveraging large-page support. Large pages are always read/write (and nonpageable).

But that's a rare edge case.

timewizard• 1 year ago

Which is why the code in the article changes memory protections from read+execute to read+write and then back again after modifying the code.

c-linkage• 1 year ago

The most insidious version of this I experienced was when a library changed the FPU settings.

Fortunately, it was sufficient to reset the FPU settings after initializing the library. But it sure took a long time to figure out what happened!

DavidVoid• 1 year ago

There's a great Random ASCII blog post about an obscure FPU issue like this [1].

  - The crash was in a FPU that Chrome barely uses  
  - The instruction that crashed Chrome was thousands of instructions away from the one that triggered the exception  
  - The instruction that triggered the exception was not at fault  
  - The crash only happened because of third-party code running inside of Chrome  
  - The crash was ultimately found to be caused by a code-gen bug in Visual Studio 2015

I've run into this kind of thing once myself (sharing a process with other companies is fun!). It was real confusing to get a stack trace showing our code suddenly crashing on a line of code that was doing the exact same thing with the exact same values as it had always done before.

[1] https://randomascii.wordpress.com/2016/09/16/everything-old-...

minetest2048• 1 year ago

This also happened in python ecosystem where gevent were messing with numpy because gevent was compiled with -ffast-math, which disables subnormal numbers

Blog post: https://moyix.blogspot.com/2022/09/someones-been-messing-wit... HN discussion: https://news.ycombinator.com/item?id=41212072

Const-me• 1 year ago

Cool trick, but I wouldn’t do that for the use case.

The use case they had is saving minidumps when the app crashes. Windows error reporting OS component is flexible enough to support the feature without hacks, they just need to write couple values to registry in the installer of their software. See details on per-application settings in that article: https://learn.microsoft.com/en-us/windows/win32/wer/collecti...

If they want better UX and/or compress & uploads the dump as soon as the app crashes (as opposed to the next launch of the app) – I would solve by making a simple supervisor app which launches the main binary with CreateProcess, waits for it to exit, then looks for the MainApp.exe.{ProcessID}.dmp file created by that WER OS component.

chadaustin2• 1 year ago

Hello, author here (16 years ago). I don't think that component existed then. In hindsight, we would have either used WER or initiated crash dumps from outside of the process via a watchdog. It is quite problematic to attempt to capture your process state from within a failed process.

That said, we did have a bunch of hand-rolled state capturing (including Python thread stacks) so maybe WER wouldn't have been as useful anyway.

muststopmyths• 1 year ago

WER has been in the OS for about 20 years. Vista for sure, maybe even before that.

Writing your own minidump uploader in the unhandled exception filter is/was a very common practice in games, while obviously not ideal.

I think Unreal Engine might still do that. So I think that the claim that Direct3D captures exceptions is suspect.

It may trap them and return EXCEPTION_CONTINUE_SEARCH to pass it on to the next handler, but I have a hard time coming up with a reason why it would trap them in the first place. I have personally never seen Direct3D trap an exception in my long career.

Maybe you were expecting C++ exceptions to be caught, but these APIs are only for SEH.

Now Flash, I have no experience with.

Yes, I know it's a 16year old post. But I must stop myths.

ack_complete3• 1 year ago

The Registry keys for WER, even the per-application ones, are all under HKEY_LOCAL_MACHINE. They cannot be set without elevation. WER is also useless if you want to capture contextual in-process data about the crash.

This problem is so rampant that even Office hooks SetUnhandledExceptionFilter.

p_ing2• 1 year ago

Requiring elevation wasn't uncommon for games or most applications back then. Installing to local app data is somewhat new, though platforms like Steam smartly modified the NTFS permissions in their own app dir to prevent elevation specifically for binary deployment; other components like C runtime, etc. during game install would require elevation.

Office is a poor example of 'what to do'. The title bar is a hack. It only supports ~214 character path length even though Win32 API has been lifted to 32k, etc.

Disabling kernel functions in your process (2009)

Related Stories