วีดีโอ

Let's use A, B and C to denote processes of interest. We first have process A (parent) fork process B (child). Process B immediately forks process C (grandchild). B then dies and gets reaped by A's wait() syscall, and then A continues it's own business. The grandchild C is effectively orphand and the init process will take on the responsibility for its cleanup. This is a common technique to daemonize a process. In our case, we just daemonized our virus running in the background allowing it to perform arbitrarily long work. Let me know if this clears things up.

In 2:36 you mentioned about the dead child process appeared as <defunc> in the process list because the parent haven't call wait() to clean it up yet. My concern is, after forking process C (grandchild), B dies but won't get cleanup until A call wait(). So if the analyzer inspect process list at this moment, it will see process A and a dead process B, won't it also "raise some eyebrows"?

Your concern is valid, but process A performs wait() right after fork(). Depending on scheduling activities, there might be a tiny window where process B can be marked as <defunct> before it's cleaned up. I don't think any sampling based process analyzer can reliably pick that up, unless a BPF based monitor sets up process hooks and gets notified about each process state changes. Realistically, showing up as <defunct> is suspicious to humans when they happen to be looking at the process list. This window is small enough that should be insignificant to human eyes. What this trick achieves is hiding long running work from human perception, that is, without slowing down the infected program to a noticeable degree, nor causing other visual artifacts (defunct process).

​@@LinuxVirusEngAndResearch I understand that the double-fork trick is used to hide long running work (by moving it to a completely separated process C) and hide artifacts (by dying and got cleaned up immediately after forking). For demonstration purpose you presented a situation where B got fork'ed, died, but not getting cleaned up yet. I understand that realistically the time from when B got fork'ed and the dead B got cleaned up is short, but I raised the concern because I didn't know how short it is, and is it significant enough to leave any trace. Now I got the answer. One last thing (to confirm): if an analyzer happens to take a snapshot of the process list at the right moment, it can still see the dead process B (that is marked as <defunc>), right?

@@sarahkatherine8458 That is absolutely right. I don't have a quantitive measure of how small that window is but I'd say the possibility to sample at the exact right moment is fairly low on modern multi-core machines. Are you looking to design such an analyzer?

You certainly speak my mind

Avoiding RO data can save you lots of headaches but it's actually not entirely impossible. I have a prototype in the virus framework that allows it, but requires a linker script to arrange text section right next to ro_data so they can be extracted as a whole binary blob. github.com/yundddd/vf/blob/master/common/extract_text_section.py#L35 this tool hooks into the build system here github.com/yundddd/vf/blob/master/nostdlib/nostdlib.bzl#L52

anything interesting there? happy to implement that in the Virus Framework if there is a link

Virus engineering is engineering after all, isn't it? :)

Appreciate the support. I am doing extra write ups and a full course video. Stay tuned.

From the course description it looks like it's mostly educational; know your enemies so we can better defend ourselves.