4 ms·

Looks like firefox: https://searchfox.org/mozilla-central/source/toolkit/xre/dllservices/mozglue/WindowsDllBlocklist.cpp#526 https://searchfox.org/mozilla-centr

Looks like firefox: https://searchfox.org/mozilla-central/source/toolkit/xre/dllservices/mozglue/WindowsDllBlocklist.cpp#526 https://searchfox.org/mozilla-central/source/toolkit/xre/dll... (via https://searchfox.org/mozilla-central/source/toolkit/xre/dllservices/mozglue/WindowsDllBlocklist.cpp#559 https://searchfox.org/mozilla-central/source/toolkit/xre/dll... ) I'd assumed it would be Edge since the author was crawling through decompiled output and worrying about litigiousness, but the above code in a BaseThreadInitThunk() interceptor matches what the author is describing.

Randor 2y ago
Some horrible code in there too: https://searchfox.org/mozilla-central/source/toolkit/xre/dllservices/mozglue/WindowsDllBlocklist.cpp#452 https://searchfox.org/mozilla-central/source/toolkit/xre/dll... Indiscriminate blocking of any DLL in the world with 12/6 hex digit filenames.
- kimixa 2y ago
  Reading the bug report https://bugzilla.mozilla.org/show_bug.cgi?id=973138 https://bugzilla.mozilla.org/show_bug.cgi?id=973138 feels reasonable. It must be hard to be in a position to be blamed for someone else's bad code - or even malware - one comment said it was 1/3 of the total crashes on Vista at the time. As a GPU driver dev I 100% understand this position - no user cares that gamedevs are hacking things left and right, they care if it runs.
  - ack_complete 2y ago
    There's plenty of blame to go around, really. My current project has a workaround for a user-mode graphics driver that sets the thread name without checking if D3D11_CREATE_DEVICE_SINGLETHREADED is set -- so there's code to detect this and call SetThreadDescription() to change it back so the main thread can be found in the debugger again. There also used to be a problem with a release DLL in Windows 10 that would output to OutputDebugString() with an encoding mismatch, thus spamming the debug output window with random kanji. I've heard that the Office team has resorted to detouring SetUnhandledExceptionFilter() since even they had problems with third party DLLs unhooking their in-process crash handler.
    - kimixa 2y ago
      > There's plenty of blame to go around, really. My current project has a workaround for a user-mode graphics driver that sets the thread name without checking if D3D11_CREATE_DEVICE_SINGLETHREADED is set -- so there's code to detect this and call SetThreadDescription() to change it back so the main thread can be found in the debugger again. I hope that wasn't the one I worked on :P Though I'm surprised that changed much there - the flag just means we can avoid wrapping some state in mutexes (and in many paths is a NOP as the driver still uses multiple threads internally, not worth the gain for the few things they won't touch), I'm surprised that makes it rename the user thread.
      - ack_complete 2y ago
        From what I can tell, the driver author simply assumed that the user-mode graphics driver was running on a dedicated worker thread, and unconditionally set the thread name. However, when single-threaded mode is in use, it gets invoked on the application's thread -- and thus changes the name of the main thread instead. CEF had this issue as well, and the result was that initializing the WebBrowser plugin in Unreal would rename the main thread there too.
        kimixa 2y ago
        That's why I'm surprised - that flag doesn't mean we don't spawn worker threads for the driver, just that user API calls only come from a single thread. I suspect this is someone assuming the flag actually mean "the driver should only use one thread" - or more likely a popular app assumed that and relied on that behavior, and the driver ended up having to emulate that behavior and you app just happened to hit whatever heuristics enabled that option. It feels like half the driver size is due to nonsense "workarounds" like that - like the recent Fallout3/New Vegas issue was due to the app trying to autodetect the driver and versions and doing something slightly different (which hasn't really been "valid" since soon after release) - so when a version number or driver ID changes a little too much for it to cope with it completely fails - so we added an entire new "fake" driver that just lies about it's name and version. It's honestly a PITA and something I've hit on different vendor's driver in my own projects - you can rename the executable and get completely different behavior. It's probably not surprising that GPU drivers are hundreds of megabytes in size, even compressed :P
- pjc50 2y ago
  Anyone naming their DLL with random hex digits is definitely up to no good.
  - Randor 2y ago
    It's a very common security technique to avoid being targeted by malware. I believe even the Microsoft KSLDriver drops randomly named DLL and device drivers along with creating a randomly named system service. Uses 8 hex characters. Several third-party vendors use the same technique, mostly security vendors.
    - dblohm7 2y ago
      I'm the engineer who spearheaded adding the blocking technique outlined by OP. Security vendors are some of the worst offenders when it comes to injecting buggy DLLs into processes.
      - Randor 2y ago
        A brilliant idea, maybe all software should block DLL without English names. Could even incorporate the new technique into the operating system.

Randor 2y ago

Some horrible code in there too: https://searchfox.org/mozilla-central/source/toolkit/xre/dllservices/mozglue/WindowsDllBlocklist.cpp#452 https://searchfox.org/mozilla-central/source/toolkit/xre/dll... Indiscriminate blocking of any DLL in the world with 12/6 hex digit filenames.

kimixa 2y ago
Reading the bug report https://bugzilla.mozilla.org/show_bug.cgi?id=973138 https://bugzilla.mozilla.org/show_bug.cgi?id=973138 feels reasonable. It must be hard to be in a position to be blamed for someone else's bad code - or even malware - one comment said it was 1/3 of the total crashes on Vista at the time. As a GPU driver dev I 100% understand this position - no user cares that gamedevs are hacking things left and right, they care if it runs.
- ack_complete 2y ago
  There's plenty of blame to go around, really. My current project has a workaround for a user-mode graphics driver that sets the thread name without checking if D3D11_CREATE_DEVICE_SINGLETHREADED is set -- so there's code to detect this and call SetThreadDescription() to change it back so the main thread can be found in the debugger again. There also used to be a problem with a release DLL in Windows 10 that would output to OutputDebugString() with an encoding mismatch, thus spamming the debug output window with random kanji. I've heard that the Office team has resorted to detouring SetUnhandledExceptionFilter() since even they had problems with third party DLLs unhooking their in-process crash handler.
  - kimixa 2y ago
    > There's plenty of blame to go around, really. My current project has a workaround for a user-mode graphics driver that sets the thread name without checking if D3D11_CREATE_DEVICE_SINGLETHREADED is set -- so there's code to detect this and call SetThreadDescription() to change it back so the main thread can be found in the debugger again. I hope that wasn't the one I worked on :P Though I'm surprised that changed much there - the flag just means we can avoid wrapping some state in mutexes (and in many paths is a NOP as the driver still uses multiple threads internally, not worth the gain for the few things they won't touch), I'm surprised that makes it rename the user thread.
    - ack_complete 2y ago
      From what I can tell, the driver author simply assumed that the user-mode graphics driver was running on a dedicated worker thread, and unconditionally set the thread name. However, when single-threaded mode is in use, it gets invoked on the application's thread -- and thus changes the name of the main thread instead. CEF had this issue as well, and the result was that initializing the WebBrowser plugin in Unreal would rename the main thread there too.
      - kimixa 2y ago
        That's why I'm surprised - that flag doesn't mean we don't spawn worker threads for the driver, just that user API calls only come from a single thread. I suspect this is someone assuming the flag actually mean "the driver should only use one thread" - or more likely a popular app assumed that and relied on that behavior, and the driver ended up having to emulate that behavior and you app just happened to hit whatever heuristics enabled that option. It feels like half the driver size is due to nonsense "workarounds" like that - like the recent Fallout3/New Vegas issue was due to the app trying to autodetect the driver and versions and doing something slightly different (which hasn't really been "valid" since soon after release) - so when a version number or driver ID changes a little too much for it to cope with it completely fails - so we added an entire new "fake" driver that just lies about it's name and version. It's honestly a PITA and something I've hit on different vendor's driver in my own projects - you can rename the executable and get completely different behavior. It's probably not surprising that GPU drivers are hundreds of megabytes in size, even compressed :P
pjc50 2y ago
Anyone naming their DLL with random hex digits is definitely up to no good.
- Randor 2y ago
  It's a very common security technique to avoid being targeted by malware. I believe even the Microsoft KSLDriver drops randomly named DLL and device drivers along with creating a randomly named system service. Uses 8 hex characters. Several third-party vendors use the same technique, mostly security vendors.
  - dblohm7 2y ago
    I'm the engineer who spearheaded adding the blocking technique outlined by OP. Security vendors are some of the worst offenders when it comes to injecting buggy DLLs into processes.
    - Randor 2y ago
      A brilliant idea, maybe all software should block DLL without English names. Could even incorporate the new technique into the operating system.