Hello
I'm focusing (again) on malware analysis and this is an introduction's thread to study malware, trying to understand Its structure and encryption techniques.
A simple read for those interested in Malware Analysis and for everyone.
Reverse the code is the process through which it's possible to study a malware sample, of which we know only binary code, going to investigate not only the mode but on the original structure. The purpose of this technique is the need of the understanding about the mechanisms of the functioning of closed systems to find points of weakness and possible solutions ... because the malcoder doesn't release the source code.
Also, it is useful to have important information on the used technology .
Of course who releases a malcode, without releasing the source code, does this for obvious reasons and because it is not conceivable to avoid that someone try to perform actions of reversing, it's necessary to adopt measures that make difficult operations of this type.
As cybercriminals avoid the reversing
As said, it is not possible to avoid our reversing attack, but it's possible to make It ineffective or very difficult. A possible way is to modify the binary code, encrypting it, so that only at runtime level it's available the clear code. A solution of this type involves substantial modifications to the binary not easily feasible and, above all, not easily interpretable by a tester who wants to discover the structure and functioning of the malware.
Encrypt malware, means to apply an encryption algorithm with a key, which produces a new file, different from the original one and seemingly incomprehensible. Depending on the algorithm, each key produces a different result, then it's evident that It's necessary to have knowledge of the algorithm and the key. In addition, an operation of this kind creates a file that is totally different at execution time, shall be restored to the original state in order to be executed; to do this it isn't thinkable that every time we have to run a encrypted malware to avoid the operations of reversing, we have to perform an operation of decrypting before running it.
Executing a protected binary
In fact, when we launch a malware, they are triggered complex mechanisms but completely transparent to the tester. The malware is loaded in memory by the loader, and then the individual instructions are executed sequentially.
Then during the execution, the instructions of the executable must be the original one; the loader should be able to load in memory the encrypted code, decrypt it and run it. In this way, the original code is load in memory only at the time of the execution and NOT on the disk. A process of this type makes more difficult the reversing steps, as it is necessary to go to make a memory dump to retrieve the executable code in clear.
An effective technique to protect the malware that operates according to the just described mode, is the file packing and crypting: pack and/or encrypt the executable file.
The operation of a packer and a crypter
We consider a Windows system.The format of the executable file is Portable Executable (PE) and its structure is known. An executable file show itself with a series of headers, which contain the information necessary for the execution, by the instructions to be executed to the debug information.
The PE structure:
A packer removes the SYMBOL TABLE and the DEBUGGING CODE, then compact the strings in the TEXT SEGMENT, and finally encrypts the HEADER and/or the RELOCATION TABLE.
In this header, the packer adds its own code, a PACKER HEADER to the beginning of everything; this code must be executed before any other instruction to be able to restore the original information to the runtime.
When the modified file ( in this manner ) is executed, the loader first reads the header of the packer and performs a procedure of decryption. This routine will restore the original code, in the clear, by loading it in memory; the header of the packer brings the control of this code so obtained by executing the original instructions.
It is obvious, the file, after a similar process, present Itself as a set of bytes that are seemingly insignificant to any debugger, so that any attempt to reverse the file will just produce useless codes.
Well, I stop here but I do hope I'll post other threads in this direction
I'm focusing (again) on malware analysis and this is an introduction's thread to study malware, trying to understand Its structure and encryption techniques.
A simple read for those interested in Malware Analysis and for everyone.
Reverse the code is the process through which it's possible to study a malware sample, of which we know only binary code, going to investigate not only the mode but on the original structure. The purpose of this technique is the need of the understanding about the mechanisms of the functioning of closed systems to find points of weakness and possible solutions ... because the malcoder doesn't release the source code.
Also, it is useful to have important information on the used technology .
Of course who releases a malcode, without releasing the source code, does this for obvious reasons and because it is not conceivable to avoid that someone try to perform actions of reversing, it's necessary to adopt measures that make difficult operations of this type.
As cybercriminals avoid the reversing
As said, it is not possible to avoid our reversing attack, but it's possible to make It ineffective or very difficult. A possible way is to modify the binary code, encrypting it, so that only at runtime level it's available the clear code. A solution of this type involves substantial modifications to the binary not easily feasible and, above all, not easily interpretable by a tester who wants to discover the structure and functioning of the malware.
Encrypt malware, means to apply an encryption algorithm with a key, which produces a new file, different from the original one and seemingly incomprehensible. Depending on the algorithm, each key produces a different result, then it's evident that It's necessary to have knowledge of the algorithm and the key. In addition, an operation of this kind creates a file that is totally different at execution time, shall be restored to the original state in order to be executed; to do this it isn't thinkable that every time we have to run a encrypted malware to avoid the operations of reversing, we have to perform an operation of decrypting before running it.
Executing a protected binary
In fact, when we launch a malware, they are triggered complex mechanisms but completely transparent to the tester. The malware is loaded in memory by the loader, and then the individual instructions are executed sequentially.
Then during the execution, the instructions of the executable must be the original one; the loader should be able to load in memory the encrypted code, decrypt it and run it. In this way, the original code is load in memory only at the time of the execution and NOT on the disk. A process of this type makes more difficult the reversing steps, as it is necessary to go to make a memory dump to retrieve the executable code in clear.
An effective technique to protect the malware that operates according to the just described mode, is the file packing and crypting: pack and/or encrypt the executable file.
The operation of a packer and a crypter
We consider a Windows system.The format of the executable file is Portable Executable (PE) and its structure is known. An executable file show itself with a series of headers, which contain the information necessary for the execution, by the instructions to be executed to the debug information.
The PE structure:
- HEADER
- TEXT SEGMENT
- DATA SEGMENT
- RELOCATION TABLE
- SYMBOL TABLE
- DEBUG CODE
A packer removes the SYMBOL TABLE and the DEBUGGING CODE, then compact the strings in the TEXT SEGMENT, and finally encrypts the HEADER and/or the RELOCATION TABLE.
In this header, the packer adds its own code, a PACKER HEADER to the beginning of everything; this code must be executed before any other instruction to be able to restore the original information to the runtime.
When the modified file ( in this manner ) is executed, the loader first reads the header of the packer and performs a procedure of decryption. This routine will restore the original code, in the clear, by loading it in memory; the header of the packer brings the control of this code so obtained by executing the original instructions.
It is obvious, the file, after a similar process, present Itself as a set of bytes that are seemingly insignificant to any debugger, so that any attempt to reverse the file will just produce useless codes.
Well, I stop here but I do hope I'll post other threads in this direction
