Sign In
Register
Help
I have reached the stage where I am crypting all PE section apart from .idata, which is yielding 100% antidetection on all malware tested so far.
So now I reach the next stage, how to ensure that a signature cannot be found to identify files encrypted with codeCrypter.
Initally, I worked on inserting random "junk nops" into the stub code that does the decrypting, i.e.
push EAX; mov EAX, 0; pop EAX;
could be used as a junk nop.
as could:
add EAX, 5; sub EAX, 5;
etc etc...
This might work, although a paper on the CodeBreaker-Journal implies that some AV can detect junk nops, and exclude them when checking against a signature...
So I decided to take this to the next level.
Instead of just adding junk nops, I will create an engine that modifies the code with equivalent operations.
For instance,
mov EAX, 5;
is equivalent to:
push 5; pop EAX;
so I will develop a library of equivalent operations for every x86 instruction commonly used. The engine will then:
1) disassemble each instruction in a section of code;
2) select a random equivalent operation;
3) calculate extra space required to fit new equivalent operations and insert space in code;
4) assemble the equivalent operations.
Once this is complete, the engine will then insert random junk nops for good measure.
Now, this actually has been done before. Zombie wrote code pervertor which could achieve this but only for instructions that have an equivalent instruction of equal size in bytes when assembled. I will be taking this to the next level.
What then occured to me, is why purely crypt the code section of the PE File. I can use this perverting engine to alter both the malware's code section before crypting it and my stub. This will mean that even when AV move to scanning process memory (as opposed to scanning the disk image of a process), it will still remain undetected.
Before I begin this long project, are there any comments on my plans or suggestions of things I may be forgetting?
If all goes to plan, we will be seeing the next era in AV technologies being forced into play.
It will no longer be sufficient to scan for signatures, and the actual behaviour of an application will need to be analysed in a sandbox, before it can be classified "clean".
Some might see this project as potentially dangerous, since it will enable anyone to create unique versions of existing malware at the press of a button.
However, I reached the view that the extreme ease with which malware can be made undetected from current AV is unacceptable from a security standpoint.
Any non-public packer will beat all AV on the market today, and a packer is very easy to write, for any seasoned programmer.
The only reason AV firms are able to continue with their current practice, is that once a packer goes public, they can put a signature on the packer.
Once complete, this project will make it impossible to recognise that a file has been packed, and hence AV will be forced to reconsider the methods they use.
The long term benefit of this will be that private packers will no longer be able to hide malware from AV and we should therefore enjoy safer systems.
MultiQuote
