detach / temporary disable / uninstall by editing rk's config about r77-rootkit

[bytecode77]

There is currently no injection exclusion list. It seems plausible to implement one, either as a registry key or hard-coded or both.

An exclusion list can generally only be a processes' filename, and not the PID. Because by the time the PID is determined, the process is already injected. Therefore, an exclusion list would only work on process names.

I have noted that as a feature request and it's really a good suggestion as it fits in the whole concept and I'm aware that some processes tend to crash, such as MSBuild.exe. Not sure, though, when exactly I'm going to implement it (anywhere from a week to 2 months).

What you can also consider is to apply the R77_HELPER_SIGNATURE at compile time. This is done for TestConsole.exe and it prevents r77 from ever injecting the process, as the executable file itself carries this flag upon creation. Not sure, if that fits your scenario.

I've added your suggestion to the list for the next release and I'll let you know when it's there.

[bytecode77]

r77 version 1.3.0 is released.

The new Control Pipe feature allows any process to communicate with the rootkit and trigger certain actions. That way, you can disable / enable injection, etc. (see Documentation section 2.9 Control Pipe)

Another feature is a hardcoded list of processes that will not be injected. The advantage over the configuration system is that these processes will never be injected. If you use the configuration system, these processes might be injected before you have written the value to the registry key.

You need to modify the code here and compile r77:

/// <summary>
/// Specifies a list of processes that will not be injected.
/// By default, this list includes processes that are known to cause problems.
/// To customize this list, add custom entries and recompile.
/// </summary>
#define PROCESS_EXCLUSIONS						{ L"MSBuild.exe" }
// Example: { L"MSBuild.exe", L"your_app.exe", L"another_app.exe" }

[APT-ZERO]

then if users found a process crashing, they can add it in config and solve the problem.

[APT-ZERO]

will you add temporary disable and self uninstall features too or only exclude feature?

also some questions!
will the exclude feature also detach process if it's running, or user should restart the excluded process to detach? what about temp disable feature? will it also detach injected processes?
will temp disable feature completely shut down rk process, or prevent injecting new processes only?

i think it's better that temp disable feature only prevent injecting new processes
and exclude feature only prevent the process to be injected
then to detach an specified process or all processes, user should make a value in another key, and when rk found the specified key, detach all or the specified process, and then rk should remove the value after detach is done

also if you add uninstall feature, it can't work when install is custom
instead, you can specify another key / value for rk to detach all and self close!
then user can uninstall the rk by

1. deleting the task (to prevent re run when user is shutting rk down)
2. adding self shutdown key and wait for it to be removed (if the created value removed, it means self shutdown is done)
3. registry keys/values

Also with this features, upgrading rk will be possible without using uninstall.exe

[bytecode77]

I think some of your suggestions are very useful. I'm currently sorting through your thoughts to add features to the ToDo list for the next release.

What's on my ToDo list so far:

• Add an exclusion list of filenames, so processes with those file names will not be injected by hard coding this string list in code. This has the advantage that anyone can simply re-compile the solution with their own fixed set of filenames. Using a registry key is problematic: The $77config registry key is created after installation and injection of all processes already happened.

Meanwhile, what's worth pointing out is that a lot of unskilled users use my rootkit and have a lot of trouble understanding how it works, even if it's straight out-of-the-box simple. I've seen r77 being in use by skilled hackers, who didn't ask any questions on how to use it - they simply know how (like you). On the other hand, when GitHub users open issues, because they lack the proper understanding, it creates work on my part - and I'm already short on time that I can spend on projects.

I was thinking about a solution to communicate with r77 through a named pipe, supporting e.g. following commands:

• Send an EXE file through a named pipe to let r77 execute it using RunPE
• Terminate a specified PID
• Uninstall r77
• etc...

The trouble could be to document it and provide enough examples so that I don't receive a lot of GitHub issues asking how it works, or better yet, users requesting me to code it in another language.

I'll be working on r77 next month or so, then at least some of your suggestions are already on the ToDo list. I'll let you know ;)

[bytecode77]

As of now, there is a new feature to exclude processes from being injected. It's only on the dev branch, so you have do download the code from there and compile. To add a process name to the exclusion list, modify the contents of PROCESS_EXCLUSIONS and recompile.

This is the dev branch. Downloadable binaries and documentation will follow with the next release, as well as other features on the ToDo list.

[APT-ZERO]

what about exclude process name using registry? please add this ability too

[bytecode77]

what about exclude process name using registry? please add this ability too

What would be the benefit of a dynamic exclusion list? Right now, I have implemented it to exclude problematic processes, such as MSBuild.exe (which crashes) and user defined processes for individual needs. But what's the purpose behind a dynamic list? It's especially tricky, because by the time the $77config key is created and read by r77, those processes are already injected.

Could you elaborate on that a little further, or maybe provide some examples? I'm usually implementing features that are requestet frequently or those that are generally useful.