locked
"xxx is not a valid executable" (screenshots) EMET 3 / 4.1 / 5.0 RRS feed

  • Question

  • Can anyone tell me what these messages mean?

    Sunday, April 13, 2014 4:50 PM

All replies

  • Svchost and audiodg (csrss and services will act the same way as well as a handful of others) are core system processes and thus cannot be protected by EMET as they are not actually executable files. Only things that end an '.exe' are executables and can therefore be added and protected by EMET.

    Svchost, audiodg, csrss and services do correspond to .exes in System32, but in my experience protecting them does not cause the EMET shim to be applied to the host process, but some processes that are spawned from the host may be protected.


    Sunday, April 13, 2014 10:48 PM
  • Svchost and audiodg (csrss and services will act the same way as well as a handful of others) are core system processes and thus cannot be protected by EMET as they are not actually executable files. Only things that end an '.exe' are executables and can therefore be added and protected by EMET.

    Svchost, audiodg, csrss and services do correspond to .exes in System32, but in my experience protecting them does not cause the EMET shim to be applied to the host process, but some processes that are spawned from the host may be protected.


    Thanks for the response, but is it not strange that svchost can be added and protected as below only for one new svchost to trigger the error message? Doesn't that suggest I have two svchost files? (there only appears to be one in System32 but isn't it strange that it behaves differently from the others?)



    Tuesday, April 15, 2014 4:21 AM
  • I did some digging on my computer and when you compare the process IDs, it looks like most of the ones that EMET is reporting to not have a .exe are actually running in a state where it does not have any DLLs, and looks like it rejects any that are given to it. The logical answer is that they are core services that should not be messed with, and are therefore protected from potential changing and attacks by being set to ignore anything that is done to them. But that doesn't really explain why EMET treats them as a file without any extension.

    My guess is that if EMET detects that the process is ignoring probes about DLL handles then it just restricts you from configuring for that specific process. But really the specifics of why EMET deals with it that way would be best answered by their developers if they ever poke their head in here.

    Wednesday, April 16, 2014 12:14 PM