[iSecure]

Ciphering (i guess you meant encryption) would be too complicating to implement in a way when its integrated with 2 other technologies. And it has a weak point always - it is the encryption key - which you need to save somewhere to be able to de-cipher next block of code. If your code knows where the key is, then the analyst knows that too. That said, i'm not sure if the encryption worth the investment to integrate.

1) Scenario, where researcher can't suspend live system, would be that it is critical infrastructure system, and suspending such system is not an option until the alternative system is created to maintain needed critical functionality. And this will cost a lot of money and time. Of course, this is not everyday's scenario, but it is not impossible either (think of stuxnet).

2) Rootkit mission is to hide unauthorized activity on system. That mean, rootkit's aim is to extend payload lifecycle as much as possible. The longer it's undetected -> the longer it's not dumped/analysed -> the longer it's not removed from system -> the longer it's executing it's payload -> the more chances it's achieved it's goal. It's not always critical to have 'good system control' as long as rootkit performes it's tasks. Some tasks can be performed without callbacks, hooks, threads.

Though, you are right in the point that such tasks will be very limited in what they can do.

[t4L]

I think this is a more likely a coding experience than a practical work.

You can run anywhere on memory, but fact is you will always have to install a static file/binary of your code on the HDD. You can't hide your static binary files. Analysts will have just to fireup a VM, take a full physical mem dump or debugging to locate the static files w/o playing hide and seek with self relocable running code blocks.

My 2 cents.

[Cr4sh]

but fact is you will always have to install a static file/binary of your code on the HDD

Not always: malicious code can get execution at OS startup via vulerability in some OS component during the parsing some data -- in this case rootkit/maware will exist in the system only as shellcode inside some datafile/registry/etc., but _not_ as separated or modified executable module (or bootcode).

[t4L]

Not always: malicious code can get execution at OS startup via vulerability in some OS component during the parsing some data -- in this case rootkit/maware will exist in the system only as shellcode inside some datafile/registry/etc., but _not_ as separated or modified executable module (or bootcode).

Yes, but that shellcode/executed files has to be stored on HDD, right? I meant there's always some trails of binaries on the HDD and at least one loader entry point. In your case, they could be parsing vulnerabilities (WMF, LNK parsing e.g). Not mentioning about 0day vulns, if its known vulns, it will be even easier cos AVs don't have to play hide and seek with rootkits, they just detect the exploit binaries while the rootkits havent been executed yet.

[Cr4sh]

Not mentioning about 0day vulns, if its known vulns, it will be even easier cos AVs don't have to play hide and seek with rootkits, they just detect the exploit binaries while the rootkits havent been executed yet.

AVs? :D I mean 0day vulns-based rootkits in target attacks, mass commertial malwares are totally boring, lame and harmless.

[t4L]

If its 0day, everything is diffrent :D Still don't need constantly change self-relocable rootkit. All depend on OS security design and addon security solutions :D

I totally agree with mass commercial malwares are boring, but the industry still havent found a sufficient solution to solve several problem with those mass commercial malwares such as correct malware classifying, ultimate malware heuristic & behaviors etc,. Those are also reasons why AVs failed to detect Stuxnet and Flame.

[rkhunter]

...but the industry still havent found a sufficient solution to solve several problem with those mass commercial malwares such as correct malware classifying, ultimate malware heuristic...

Probably development such AV-engine even more difficult than finding of "industrial"-0day that used in Stuxnet&Flame.

[EP_X0FF]

Like Magenta from HBGary. IIRC it was constantly moving in memory, reassembling itself.

[rkhunter]

Like Magenta from HBGary.

Saw sources?

[Cr4sh]

Like Magenta from HBGary.

Saw sources?

I saw only description in leaked hbgary e-mails: extremly small memory footprint, self-reallocation and 80k$ (If I remember correctly) price :)