Tribute to HIEW
It is inspired by ancient memories ... Years and decades pass, the names of operating systems replace each other, but something still remains the same. Among all the variety of okolohakerskogo software I was always surprised HIEW; incomprehensibly, this console program manages to struggle with time and be popular even today. HIEW has found its niche and has become the main tool for industrial virus analyst. You may find this odd and inconvenient, but using HIEW for virus analysis is very effective.
So let's start, perhaps.
Task: to identify and classify malware among a mountain of executable files.
Solution: using dynamic analysis is inconvenient, IDA is long (and expensive), conclusion - we use HIEW.
')
We describe an approximate algorithm for express analysis of an executable file for maliciousness. The first thing to do is to detect possible infection of the object being analyzed with a file virus.
Load the executable file into HIEW and see which section the entry point points to (Enter, F8, F6). There may be several cases.
Option one. The entry point points somewhere in the header area of the PE file. The variant is trivial and is detected by visual viewing of the file in text mode.
Option two. The entry point points to the last section of the executable file. This is also very suspicious and most likely indicates that the file has been infected. Consider a few examples.
The entry point is as follows:
A trained eye cuts the use of the instruction call +5, which is not very typical for a regular compiler. The line 0x0048c030 is also interesting, where, probably, there is a manual work with the header of the PE file. Let's look at the attributes of the section:
The obvious conclusion suggests itself: the object being analyzed is infected with a file virus. In this case, it is a type of Virut virus.
In general, the infection of the last section of the file is a very popular technique that does not require much effort. Infection is easily identified by the presence of a meaningful or encrypted code in the last section, which was not intended for this purpose at all. For example, in the resource section, data, relocatable items, etc.
Sometimes you can find the following picture:
The verdict is obvious - the file is infected. After the bytes left at the end of the file for alignment by the compiler, there follows not only a meaningful code, but also the entry point itself.
Let's make a small lyrical digression from express analysis. This begs the question: is it possible to investigate dynamically deciphering objects with HIEW? Surprisingly, this is often done. Consider the previous example with the virus Virut. The virus code is small, encrypted in places and located at the end of the file. Having a little look through the disassembled listing, we come across it:
It is not difficult to see the simplest decoding cycle. However, in the case of static analysis, we cannot determine what and with what key is decrypted here. But! Recall that HIEW supports the search for cross-references, hovers the cursor at the beginning of the decryption cycle, presses F6, and looks for calls to a piece of code of interest to us:
It is very likely that this is the code that calls the decryption procedure. In this case, the encrypted section is located at 0x0048c155 ([EAX]), and the single-byte key is located at 0x0048c154 ([EAX-1]). The block size is 0x12b2 bytes.
To decrypt, IDA users would run to write a script on idc or python. In the debugger, in general, would not have to do anything. HIEW users use built-in data block processing. We describe the required encryption algorithm, select the block boundaries in the hex editor mode and run the script.
The built-in block processing tool has an Intel-like syntax and allows simple conversions of 8, 16, 32, and 64 bits. As a result of decoding, we obtain quite suitable for analysis data:
Let's return again to the rapid analysis. Option three. The entry point points where it is supposed to be - in the code section. Detection of infection requires little experience. Consider a few examples.
The instructions call +5; pop reg. This technique is very characteristic when writing a base-independent code. It should be noted that instead of a direct transition to the virus body, instructions such as push reg; retn or mov reg, addr; call reg and other variations on this topic. Normal compilers usually do not do this, at least not at the entry point, but in some virtual classroom. From all this we can conclude that this instance is also infected with a file virus. In this case, this is the notorious Sality.
Moving on. Suppose we met the following code:
Despite the fact that the entry point immediately points to call and jmp, the file is not infected, and this is the standard beginning of the C / C ++ program compiled by Microsoft Visual Studio 2010. This example is rather an exception. Usually, when a code section is infected, the malicious code is added either to its end (if there is enough space), or jmp is made to the malicious code directly from the entry point. Compilers usually begin program execution by calling a standard function that has a standard prolog:
Here we see the beginning of the program compiled with the Visual Studio C ++ 6.0 compiler. The entry point indicates the standard prologue, followed by the installation of its own exception handler.
Consider the following code:
Here the entry point points to the sequence already known to us push addr; retn. Before us is Rustock.
After analyzing the entry point, it is a good idea to simply browse the sections and file overlays. Sometimes there are the following instances:
In this example, the encrypted body of the original program is probably written in the overlay. The essence of the "infection" mechanism can be understood from the following code:
In fact, the “virus” infects files as follows: it completely encrypts the original executable file, transfers the data to itself in the overlay and overwrites the original program with the resulting file. When launched, the program decrypts the original file, writes it to a disk in a temporary directory and launches it with the original command line parameters.
This completes the virus analysis itself. Finding more complex infections in a short time in the industrial analyst mode is difficult (personal opinion). Next comes the work to determine the malicious functionality of the file being analyzed.
Various extortionists, fake antiviruses, etc. are detected simply by skimming the file in text mode:
Since it is no secret to anyone that a sufficient amount of malicious software is being produced in Russia, the possibility of HIEW working with Russian encodings out of the box makes life easier for virus analytics.
HIEW also allows you to identify the encrypted parts of the file. The specificity of the code and data is such that they contain a lot of redundancy, and especially zero bytes. Therefore, when detecting, for example, the next data block ...
... it can be concluded that this data is encrypted. Is it possible to statically decipher them? In this case, we are lucky, and again we confine ourselves to one HIEW. Let's go to the beginning of the encrypted data and look for cross-references:
Immediately we find the required decryption cycle. Everything is almost done. Select the encrypted block, write the script:
And deciphering malicious code:
If fast decryption is not possible, the file is sent to a deeper analysis, but this is another story.
Next, according to the plan, there is a definition of standard Trojan programs like Zeus, SpyEye, Carberp and others. According to the words, an experienced virus analyst identifies them at a glance (the author does not have the opportunity to verify this application).
As a result, we can analyze and classify instances with almost unreal speed: 1 object in less than 10 minutes. Apparently this was the key to the success of such a legendary program as HIEW.
PS Detailed description of HIEW unicornix.spb.ru/docs/prog/heap/hiew.htm
So let's start, perhaps.
Task: to identify and classify malware among a mountain of executable files.
Solution: using dynamic analysis is inconvenient, IDA is long (and expensive), conclusion - we use HIEW.
')
We describe an approximate algorithm for express analysis of an executable file for maliciousness. The first thing to do is to detect possible infection of the object being analyzed with a file virus.
Load the executable file into HIEW and see which section the entry point points to (Enter, F8, F6). There may be several cases.
Option one. The entry point points somewhere in the header area of the PE file. The variant is trivial and is detected by visual viewing of the file in text mode.
Option two. The entry point points to the last section of the executable file. This is also very suspicious and most likely indicates that the file has been infected. Consider a few examples.
The entry point is as follows:
A trained eye cuts the use of the instruction call +5, which is not very typical for a regular compiler. The line 0x0048c030 is also interesting, where, probably, there is a manual work with the header of the PE file. Let's look at the attributes of the section:
The obvious conclusion suggests itself: the object being analyzed is infected with a file virus. In this case, it is a type of Virut virus.
In general, the infection of the last section of the file is a very popular technique that does not require much effort. Infection is easily identified by the presence of a meaningful or encrypted code in the last section, which was not intended for this purpose at all. For example, in the resource section, data, relocatable items, etc.
Sometimes you can find the following picture:
The verdict is obvious - the file is infected. After the bytes left at the end of the file for alignment by the compiler, there follows not only a meaningful code, but also the entry point itself.
Let's make a small lyrical digression from express analysis. This begs the question: is it possible to investigate dynamically deciphering objects with HIEW? Surprisingly, this is often done. Consider the previous example with the virus Virut. The virus code is small, encrypted in places and located at the end of the file. Having a little look through the disassembled listing, we come across it:
It is not difficult to see the simplest decoding cycle. However, in the case of static analysis, we cannot determine what and with what key is decrypted here. But! Recall that HIEW supports the search for cross-references, hovers the cursor at the beginning of the decryption cycle, presses F6, and looks for calls to a piece of code of interest to us:
It is very likely that this is the code that calls the decryption procedure. In this case, the encrypted section is located at 0x0048c155 ([EAX]), and the single-byte key is located at 0x0048c154 ([EAX-1]). The block size is 0x12b2 bytes.
To decrypt, IDA users would run to write a script on idc or python. In the debugger, in general, would not have to do anything. HIEW users use built-in data block processing. We describe the required encryption algorithm, select the block boundaries in the hex editor mode and run the script.
The built-in block processing tool has an Intel-like syntax and allows simple conversions of 8, 16, 32, and 64 bits. As a result of decoding, we obtain quite suitable for analysis data:
Let's return again to the rapid analysis. Option three. The entry point points where it is supposed to be - in the code section. Detection of infection requires little experience. Consider a few examples.
The instructions call +5; pop reg. This technique is very characteristic when writing a base-independent code. It should be noted that instead of a direct transition to the virus body, instructions such as push reg; retn or mov reg, addr; call reg and other variations on this topic. Normal compilers usually do not do this, at least not at the entry point, but in some virtual classroom. From all this we can conclude that this instance is also infected with a file virus. In this case, this is the notorious Sality.
Moving on. Suppose we met the following code:
Despite the fact that the entry point immediately points to call and jmp, the file is not infected, and this is the standard beginning of the C / C ++ program compiled by Microsoft Visual Studio 2010. This example is rather an exception. Usually, when a code section is infected, the malicious code is added either to its end (if there is enough space), or jmp is made to the malicious code directly from the entry point. Compilers usually begin program execution by calling a standard function that has a standard prolog:
Here we see the beginning of the program compiled with the Visual Studio C ++ 6.0 compiler. The entry point indicates the standard prologue, followed by the installation of its own exception handler.
Consider the following code:
Here the entry point points to the sequence already known to us push addr; retn. Before us is Rustock.
After analyzing the entry point, it is a good idea to simply browse the sections and file overlays. Sometimes there are the following instances:
In this example, the encrypted body of the original program is probably written in the overlay. The essence of the "infection" mechanism can be understood from the following code:
In fact, the “virus” infects files as follows: it completely encrypts the original executable file, transfers the data to itself in the overlay and overwrites the original program with the resulting file. When launched, the program decrypts the original file, writes it to a disk in a temporary directory and launches it with the original command line parameters.
This completes the virus analysis itself. Finding more complex infections in a short time in the industrial analyst mode is difficult (personal opinion). Next comes the work to determine the malicious functionality of the file being analyzed.
Various extortionists, fake antiviruses, etc. are detected simply by skimming the file in text mode:
Since it is no secret to anyone that a sufficient amount of malicious software is being produced in Russia, the possibility of HIEW working with Russian encodings out of the box makes life easier for virus analytics.
HIEW also allows you to identify the encrypted parts of the file. The specificity of the code and data is such that they contain a lot of redundancy, and especially zero bytes. Therefore, when detecting, for example, the next data block ...
... it can be concluded that this data is encrypted. Is it possible to statically decipher them? In this case, we are lucky, and again we confine ourselves to one HIEW. Let's go to the beginning of the encrypted data and look for cross-references:
Immediately we find the required decryption cycle. Everything is almost done. Select the encrypted block, write the script:
And deciphering malicious code:
If fast decryption is not possible, the file is sent to a deeper analysis, but this is another story.
Next, according to the plan, there is a definition of standard Trojan programs like Zeus, SpyEye, Carberp and others. According to the words, an experienced virus analyst identifies them at a glance (the author does not have the opportunity to verify this application).
As a result, we can analyze and classify instances with almost unreal speed: 1 object in less than 10 minutes. Apparently this was the key to the success of such a legendary program as HIEW.
PS Detailed description of HIEW unicornix.spb.ru/docs/prog/heap/hiew.htm
Source: https://habr.com/ru/post/208176/
All Articles