Further Design Issues

Aside of what concerns the code itself:

Injecting to the previous stack page top address is a safety move to assure the virus code won't overwrite any program related data on the stack. Testing the virus on the syslogd daemon showed that this make sense, as the syslogd at some point managed to partly overwrite the virus code. A common pitfall is NULLs, as two NULLs overwrite (e.g. \x00\x00) creates a valid assembly instruction ADD %AL,(%EAX) which easily leads to a crash.

Apart from the stack it is possible to inject the code to the .text section itself. As on x86|IA32, pages are 4k aligned and the program code itself might not fill up the entire page. The gap created often is referred to as "cave", and it is an ideal place to park the virus assuming of course the virus is small enough to get into it. But due to nature of the .text section, which is not writable, the virus will require to issue mprotect() on the current page to perform self modifying actions on itself.

An easy way to find a suitable process to infect using an automatic approach, would be to start an attachment loop starting from the pid zero and onward. As the system boots and enters init 3 (e.g. multiuser) a series of daemons are being launched. Due to the timing of these daemons, their pids would be closer to zero, an example for such would be crond, syslogd and inetd.