Tribute to HIEW
Inspired by ancient memories ... Years and decades pass by, the names of operating systems replace each other, but something still remains unchanged. Among the variety of near-hacker software, HIEW has always surprised me; in an incomprehensible way, this console program manages to fight against time and be popular even today. HIEW has occupied its niche and has become the main tool for industrial viral analytics. It may seem strange and inconvenient to you, but using HIEW for virus analysis is very effective.
So, let's start with, perhaps.
Objective: identify and classify malware among a mountain of executable files.
Solution: using dynamic analysis is inconvenient, IDA is long (and expensive), the conclusion is that we use HIEW.
We describe an example algorithm for express analysis of the executable file for malware. The first thing to do is to identify a possible infection of the analyzed object with a file virus.
Download the executable file in HIEW and see which section the entry point points to (Enter, F8, F6). Several cases are possible here.
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 a file infection. Let's look at a few examples.
The entry point is as follows:
The trained eye cuts the application of the call +5 instruction, which is not very characteristic of the usual compiler. The line 0x0048с030 is also interesting, where, probably, manual work with the header of the PE file occurs. Let's look at the attributes of the section:
The obvious conclusion is that the analyzed object is infected with a file virus. In this case, it is a type of Virut virus.
In general, infecting the last section of a file is a very popular technique that does not require much effort. The infection can easily be identified by the presence of meaningful or encrypted code in the last section, which is absolutely not intended for this. For example, in the section of resources, data, roaming elements, etc.
Sometimes you can meet 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, not only meaningful code follows, but also the entry point itself.
Let's make a small lyrical digression from the express analysis. The question arises: is it possible to explore dynamically decrypting objects with HIEW? Surprisingly, this is often done. Consider the previous Virut example. The virus code is small, encrypted in some places and located at the end of the file. After a little flipping through the disassembled listing, we come across this:
Here it is not difficult to see the simplest decryption cycle. However, in the case of a static analysis, we cannot determine what is decrypted with which key. But! Recall that HIEW supports the search for cross-references, point the cursor to the beginning of the decryption cycle, press F6 and look for the calls to the code section we are interested in:
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 one-byte key is located at 0x0048c154 ([EAX-1]). The block size is 0x12b2 bytes.
To decrypt, IDA users would run to write a script in idc or python. In the debugger, in general, nothing would have to be done. HIEW users use built-in data block processing. We describe the required encryption algorithm, select the block boundaries in the hexadecimal editor mode and run the script.
The built-in block processing tool has an Intel-like syntax and allows for simple conversions of 8, 16, 32 and 64 bits. As a result of the decryption, we obtain data that are quite suitable for analysis:
Let us return to express analysis. Option Three. The entry point indicates where it is supposed to be - in the code section. To detect infection requires little experience. Let's look at a few examples.
Instructions call +5 are evident; pop reg. This technique is very characteristic when writing base-independent code. It should be noted that instead of directly switching to the virus body, instructions such as push reg are often used; retn or mov reg, addr; call reg and other variations on this subject. Normal compilers usually don’t do this, at least not at the entry point, but in some virtual class. From all this we can conclude that this instance is also infected with a file virus. In this case, it is the notorious Sality.
We move on. Let's say we come across 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 more likely an exception. Usually, when a code section is infected, malicious code is added either to its end (if there is enough space), or jmp is done on the malicious code directly from the entry point. Compilers usually start the execution of a program by calling a standard function that has a standard prolog:
Here we see the beginning of a program compiled using the Visual Studio C ++ 6.0 compiler. The entry point indicates a standard prolog, followed by the installation of its own exception handler.
Consider the following code:
Here, the entry point points to the push addr sequence we already know; retn. Before us is Rustock.
After analyzing the entry point, it’s nice to just look at the file sections and overlays. Sometimes the following instances are found:
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, a “virus” infects files as follows: it completely encrypts the original executable file, moves the data to its overlay and overwrites the original program with the resulting file. At startup, the program decrypts the original file, writes it to disk in a temporary directory, and launches with the original command line parameters.
This is where the viral analysis ends. It is difficult to detect more complex infections in a short time in the industrial analyst mode (personal opinion). Next is the work to determine the malicious functionality of the analyzed file itself.
Various ransomware, fake antiviruses, etc. they are detected simply by a fluent viewing of the file in text mode:
Since it is no secret to anyone that a sufficient amount of malware is produced in Russia, it is possible for HIEW to work with Russian encodings out of the box greatly making life easier for virus analysts.
HIEW also allows you to identify encrypted areas of a file by eye. The specifics of the code and data are such that there is a lot of redundancy in them, and especially zero bytes. Therefore, upon detection, for example, of the next data block ...
... we can conclude that this data is encrypted. Can they be statically decrypted? In this case, we were lucky, and again we will limit ourselves to one HIEW. Let's move on to the beginning of the encrypted data and look for cross-references:
Immediately find the required decryption cycle. That’s almost done. We select the encrypted block, write the script:
And decrypt the malicious code:
If it is impossible to quickly decrypt, the file is sent for deeper analysis, but this is another story.
Next in the plan is the definition of standard Trojan programs like Zeus, SpyEye, Carberp and others. According to him, an experienced viral analyst identifies them at a glance (the author is unable to verify this statement).
As a result, we can analyze and classify specimens with an almost unrealistic 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 with, perhaps.
Objective: identify and classify malware among a mountain of executable files.
Solution: using dynamic analysis is inconvenient, IDA is long (and expensive), the conclusion is that we use HIEW.
We describe an example algorithm for express analysis of the executable file for malware. The first thing to do is to identify a possible infection of the analyzed object with a file virus.
Download the executable file in HIEW and see which section the entry point points to (Enter, F8, F6). Several cases are possible here.
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 a file infection. Let's look at a few examples.
The entry point is as follows:
The trained eye cuts the application of the call +5 instruction, which is not very characteristic of the usual compiler. The line 0x0048с030 is also interesting, where, probably, manual work with the header of the PE file occurs. Let's look at the attributes of the section:
The obvious conclusion is that the analyzed object is infected with a file virus. In this case, it is a type of Virut virus.
In general, infecting the last section of a file is a very popular technique that does not require much effort. The infection can easily be identified by the presence of meaningful or encrypted code in the last section, which is absolutely not intended for this. For example, in the section of resources, data, roaming elements, etc.
Sometimes you can meet 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, not only meaningful code follows, but also the entry point itself.
Let's make a small lyrical digression from the express analysis. The question arises: is it possible to explore dynamically decrypting objects with HIEW? Surprisingly, this is often done. Consider the previous Virut example. The virus code is small, encrypted in some places and located at the end of the file. After a little flipping through the disassembled listing, we come across this:
Here it is not difficult to see the simplest decryption cycle. However, in the case of a static analysis, we cannot determine what is decrypted with which key. But! Recall that HIEW supports the search for cross-references, point the cursor to the beginning of the decryption cycle, press F6 and look for the calls to the code section we are interested in:
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 one-byte key is located at 0x0048c154 ([EAX-1]). The block size is 0x12b2 bytes.
To decrypt, IDA users would run to write a script in idc or python. In the debugger, in general, nothing would have to be done. HIEW users use built-in data block processing. We describe the required encryption algorithm, select the block boundaries in the hexadecimal editor mode and run the script.
The built-in block processing tool has an Intel-like syntax and allows for simple conversions of 8, 16, 32 and 64 bits. As a result of the decryption, we obtain data that are quite suitable for analysis:
Let us return to express analysis. Option Three. The entry point indicates where it is supposed to be - in the code section. To detect infection requires little experience. Let's look at a few examples.
Instructions call +5 are evident; pop reg. This technique is very characteristic when writing base-independent code. It should be noted that instead of directly switching to the virus body, instructions such as push reg are often used; retn or mov reg, addr; call reg and other variations on this subject. Normal compilers usually don’t do this, at least not at the entry point, but in some virtual class. From all this we can conclude that this instance is also infected with a file virus. In this case, it is the notorious Sality.
We move on. Let's say we come across 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 more likely an exception. Usually, when a code section is infected, malicious code is added either to its end (if there is enough space), or jmp is done on the malicious code directly from the entry point. Compilers usually start the execution of a program by calling a standard function that has a standard prolog:
Here we see the beginning of a program compiled using the Visual Studio C ++ 6.0 compiler. The entry point indicates a standard prolog, followed by the installation of its own exception handler.
Consider the following code:
Here, the entry point points to the push addr sequence we already know; retn. Before us is Rustock.
After analyzing the entry point, it’s nice to just look at the file sections and overlays. Sometimes the following instances are found:
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, a “virus” infects files as follows: it completely encrypts the original executable file, moves the data to its overlay and overwrites the original program with the resulting file. At startup, the program decrypts the original file, writes it to disk in a temporary directory, and launches with the original command line parameters.
This is where the viral analysis ends. It is difficult to detect more complex infections in a short time in the industrial analyst mode (personal opinion). Next is the work to determine the malicious functionality of the analyzed file itself.
Various ransomware, fake antiviruses, etc. they are detected simply by a fluent viewing of the file in text mode:
Since it is no secret to anyone that a sufficient amount of malware is produced in Russia, it is possible for HIEW to work with Russian encodings out of the box greatly making life easier for virus analysts.
HIEW also allows you to identify encrypted areas of a file by eye. The specifics of the code and data are such that there is a lot of redundancy in them, and especially zero bytes. Therefore, upon detection, for example, of the next data block ...
... we can conclude that this data is encrypted. Can they be statically decrypted? In this case, we were lucky, and again we will limit ourselves to one HIEW. Let's move on to the beginning of the encrypted data and look for cross-references:
Immediately find the required decryption cycle. That’s almost done. We select the encrypted block, write the script:
And decrypt the malicious code:
If it is impossible to quickly decrypt, the file is sent for deeper analysis, but this is another story.
Next in the plan is the definition of standard Trojan programs like Zeus, SpyEye, Carberp and others. According to him, an experienced viral analyst identifies them at a glance (the author is unable to verify this statement).
As a result, we can analyze and classify specimens with an almost unrealistic 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
