OSINT-SPY – Search using OSINT (Open Source Intelligence)

Performs OSINT scan on email/domain/ip_address/organization using OSINT-SPY. It can be used by Data Miners, Infosec Researchers, Penetration Testers and cyber crime investigator in order to find deep information about their target.OSINT-SPY Documentation (beta)File Name : READMEAuthor : @sk_securityVersion : 0.0.1Website : osint-spy.comOverview of this tool:Perform scan on IP Address / domain / email address / BTC(bitcoin) address / deviceFind out latest bitcoin block informationList out all the ciphers supported by particular website and serverCheck whether a particular website is vulnerable to heartbleed or not ?Dump all the contacts and messages from skype databaseAnalyze malware or malicous file remotelyLicenses informationOSINT-SPY and its documents are covered with GPL-3.0 (General Public License v3.0)Using OSINT-SPY @@@@@@@@@ @@@@@@@@@ | @@ @ 88888|88888 @@@@@@@@@ 8@@@@@@@@ 8 @ 88888888888 | | @ @ @ | | 8 @ 8 @ @@@@@@@@@@@ | | @ @ @ | | 8 @ 8 @ 88888888888 |@@@@@@@@ | @ @ @ | —- |@@@@@@@@ 8@@@@@@@@ 8 @ @@@@@@@@@@@ | | @ @ @ | | 8 @ @@@@@@@@@@@ | | @ @ @ | | 8 @ 888888888 @@@@@@@@| | @ @@ | @@@@@@@@| 8 @ Search using OSINT Website: www.osint-spy.com Usage: osint-spy.py [options] Options: -h, –help show this help message and exit. –btc_block Find latest Bitcoin blockchain info. –btc_date Find Bitcoin blockchain information from given date. –btc_address Find out balance and transaction information of given bitcoin address. –ssl_cipher List out all the ciphers used by given server. –ssl_bleed Check whether server is vulnerable to heart bleed flaw or not. –domain Get bunch of detail of given website or organization. –email Gather information of a given email address. –device Find out devices which are connected to internet. –ip Enumerate information from given IP Addresss. –skype_db Give the location of skype database in order to fetch all the information from that including chats and contacts. –malware Find out whether a given file is infected by malware or not. –carrier Give path of carrier file behind which you want to add text. –setgo_text Enter text to hide behind carrier file. –stego_find Give a stego file and it will try to find hidden text.Required setupPython 2.7Use install_linux.py (for installing all dependencies and libraries on linux)Use install_windows.py (for installing all dependencies and libraries on windows)Contributors1. Sharad Kumar – @sk_security DocumentationSetting up the enviornmentInstalling and using OSINT-SPY is very easy.Installation process is very simple and is of 4 steps.1.Downloading or cloning OSINT-SPY github repository.2.Downloading and installing all dependencies.3.Generating API Keys4.Adding API Keys in config fileLet’s Begin !!Step 1 – Download OSINT-PSY on your system.In order to install OSINT-SPY simply clone the github repository.Below is the command which you can use in order to clone OSINT-SPY repository.git clone https://github.com/SharadKumar97/OSINT-SPY.gitStep 2 – Downloading and Installing dependencies.Once you clone OSINT-SPY, you will find one directory name as OSINT-SPY. Just go that directory and install dependencies. If you are using OSINT-SPY on windows then run install_linux.py file and if you are using linux then run install_linux.pypython install_linux.pyORpython install_windows.pyGenerating API KeysWe need some API Keys before using this tool.Following are the API’s which we are using in this tool for a time being.1.Clearbit API2.Shodan API3.Fullcontact API4.Virus_Total API5.EmailHunter APIClearbit API Register yourself at Clearbitand activate your account. Once you login, you will find one section of API. Go there and copy your secret API Key and paste inside config.py file. Config.py file can be find in modules directory of OSINT-SPY.Shodan API Register yourself at Shodan and activate your account. Once you activated your account then login to Shodan. Once you login, you will find an API key in overview tab. Copy that key and paste inside config.py file.FullContact API Register yourself at Full Contact. You can sign up by using your email or you can Sign Up with Google. Once you login, you will find your API Key on front of your dashboard. Just copy that key and paste it inside config.py file.VirusTotal API Register yourself at VirusTotal. Once you login, you will find My Api Key section in your profile menu. Just go there and copy your public API Key and paste in config.py file.EmailHunter API Register yourself at Email Hunter . Once you login, go to API tab and click on EYE icon to view your API Key. Copy your API Key in config.py file.UsageOSINT-SPY is very handy tool and easy to use.All you have to do is just have to pass values to parameter.In order to start OSINT-SPY just write — python osint-spy.com–btc_block –btc_block parameter gives you the information of latest bitcoin block chain.Usage:python osint-spy.py –btc_block–btc_date –btc_date parameter will give you an information of bitcoin block chain from given date.Usage:python osint-spy.py –btc_date 20170620–btc_address –btc_address will give you an information about particular bitcoin owner.python osint-spy.py –btc_address 1DST3gm6JthxhuoNKFqXrdpzPFfz1WgHpW–ssl_cipher –ssl_cipher will show you all the ciphers supported by given website.python osint-spy.py –ssl_cipher google.com–ssl_bleed –ssl_bleed will find out whether given website is vulnerable to heartbleed or not ? .python osint-spy.py –ssl_bleed google.com–domain –domain will give you in depth-information about particular domain including whois,dns,ciphers,location and so more.python osint-spy.py –domain google.com–email –email will gather information about given email address from various public sources.python osint-spy.py –email david@toorcon.org–device –device will search for a given device from shodan and will list out all the available devices on public IP.python osint-spy.py –device webcam–ip –ip will gather all the information of given IP Address from public sources.python osint-spy.py –ip 127.0.0.1–skype_db –skype_db will find out all the contacts and message history from given skype database.This can be useful for forensics investigator.In Windows,Skype database can be found in AppData\Roaming\Skype\(Your username)\main.db and in Mac OSX , database can be found in /Users/(Your mac user anme)/Library/Support/Skype/(your skyoe username)/main.dbpython osint-spy.py –skype_db main.db–malware –malware will send a given piece of file to virustotal and will give you a result whether given file is malware or not? .python osint-spy.py –malware abc.exe–carrier and –stego_text –carrier and –stego_text are used to hide text behind any image. –carrier will specify the image behind which you want to hide the text. –stego_text will specify the text you want to add.python osint-spy.py –carrier image.jpg –stego_text This_is_secre_text–stego_find –stego_find will find out hidden text behind any image.python osint-spy.py –stego_find hidden.jpgDownload OSINT-SPY

Link: http://feedproxy.google.com/~r/PentestTools/~3/-x63Tn8Ij2w/osint-spy-search-using-osint-open.html

Ponce – IDA Plugin For Symbolic Execution Just One-Click Away!

Ponce (pronounced [ ‘poN θe ] pon-they ) is an IDA Pro plugin that provides users the ability to perform taint analysis and symbolic execution over binaries in an easy and intuitive fashion. With Ponce you are one click away from getting all the power from cutting edge symbolic execution. Entirely written in C/C++.Why?Symbolic execution is not a new concept in the security community. It has been around for years but it is not until the last couple of years that open source projects like Triton and Angr have been created to address this need. Despite the availability of these projects, end users are often left to implement specific use cases themselves.We addressed these needs by creating Ponce, an IDA plugin that implements symbolic execution and taint analysis within the most used disassembler/debugger for reverse engineers.InstallationPonce works with both x86 and x64 binaries in IDA 6.8 and IDA 6.9x. Installing the plugin is as simple as copying the appropiate files from the latest builds to the plugins\ folder in your IDA installation directory.IDA 7.0.Ponce has initial support of IDA 7.0 for both x86 and x64 binaries in Windows. The plugin named Ponce64.dll should be copied from the latest_builds to the plugins\ folder in your IDA installation directory. Starting from version 7.0, IDA64 should be used to work with both x86 and x64 binaries.Don’t forget to register Ponce in plugins.cfg located in the same folder by adding the following line:Ponce Ponce Ctrl+Shift+Z 0 WINOS SupportPonce works on Windows, Linux and OSX natively!Use casesExploit development: Ponce can help you create an exploit in a far more efficient manner as the exploit developer may easily see what parts of memory and which registers you control, as well as possible addresses which can be leveraged as ROP gadgets.Malware Analysis: Another use of Ponce is related to malware code. Analyzing the commands a particular family of malware supports is easily determined by symbolizing a simple known command and negating all the conditions where the command is being checked.Protocol Reversing: One of the most interesting Ponce uses is the possibility of recognizing required magic numbers, headers or even entire protocols for controlled user input. For instance, Ponce can help you to list all the accepted arguments for a given command line binary or extract the file format required for a specific file parser.CTF: Ponce speeds up the process of reverse engineer binaries during CTFs. As Ponce is totally integrated into IDA you don’t need to worry about setup timing. It’s ready to be used!The plugin will automatically run, guiding you through the initial configuration the first time it is run. The configuration will be saved to a configuration file so you won’t have to worry about the config window again.Use modesTainting engine: This engine is used to determine at every step of the binary’s execution which parts of memory and registers are controllable by the user input.Symbolic engine: This engine maintains a symbolic state of registers and part of memory at each step in a binary’s execution path.ExamplesUse symbolic execution to solve a crackMeHere we can see the use of the symbolic engine and how we can solve constrains:Passing simple aaaaa as argument.We first select the symbolic engine.We convert to symbolic the memory pointed by argv[1] (aaaaa)Identify the symbolic condition that make us win and solve it.Test the solution. The crackme source code can be found hereNegate and inject a conditionIn the next gif we can see the use of automatic tainting and how we can negate a condition and inject it in memory while debugging:We select the symbolic engine and set the option to symbolize argv.We identify the condition that needs to be satisfied to win the crackMe.We negate an inject the solution everytime a byte of our input is checked against the key.Finally we get the key elite that has been injected in memory and therefore reach the Win code. The crackme source code can be found hereUsing the tainting engine to track user controlled inputIn this example we can see the use of the tainting engine with cmake. We are:Passing a file as argument to cmake to have him parsing it.We select we want to use the tainting engineWe taint the buffer that “`fread()““ reads from the file.We resume the execution under the debugger control to see where the taint input is moved to.Ponce will rename the tainted functions. These are the functions that somehow the user has influence on, not the simply executed functions.Use Negate, Inject & RestoreIn the next example we are using the snapshot engine:Passing a file as argument.We select we want to use the symbolic engine.We taint the buffer that “`fread()““ reads from the file.We create a snapshot in the function that parses the buffer read from the file.When a condition is evaluated we negate it, inject the solution in memory and restore the snapshot with it.The solution will be “valid" so we will satisfy the existent conditions. The example source code can be found hereUsageIn this section we will list the different Ponce options as well as keyboard shortcuts:Access the configuration and taint/symbolic windows: Edit > Ponce > Show Config (Ctl+Shift+P and Ctl+Alt+T)Enable/Disable Ponce tracing (Ctl+Shift+E)Symbolize/taint a register (Ctl+Shift+R)Symbolize/taint memory. Can be done from the IDA View or the Hex View (Ctl+Shift+M)Solve formula (Ctl+Shift+S)Negate & Inject (Ctl+Shift+N)Negate, Inject & Restore Snaphot (Ctl+Shift+I)Create Execution Snapshot (Ctl+Shift+C)Restore Execution Snapshot (Ctl+Shift+S)Delete Execution Snapshot (Ctl+Shift+D)Execute Native (Ctl+Shift+F9)##Triton Ponce relies on the Triton framework to provide semantics, taint analysis and symbolic execution. Triton is an awesome Open Source project sponsored by Quarkslab and maintained mainly by Jonathan Salwan with a rich library. We would like to thank and endorse Jonathan’s work with Triton. You rock! :)BuildingWe provide compiled binaries for Ponce, but if you want to build your own plugin you can do so using Visual Studio 2013. We tried to make the building process as easy as possible:Clone the project with submodules: git clone –recursive https://github.com/illera88/PonceProject.gitOpen Build\PonceBuild\Ponce.sln: The project configuration is ready to use the includes and libraries shipped with the project that reside in external-libs\.The VS project has a Post-Build Event that will move the created binary plugin to the IDA plugin folder for you. copy /Y $(TargetPath) "C:\Program Files (x86)\IDA 6.9\plugins". NOTE: use your IDA installation path.The project has 4 build configurations:x86ReleaseStatic: will create the 32 bits version statically linking every third party library into a whole large plugin file.x86ReleaseZ3dyn: will create the 32 bits version statically linking every third party library but z3.lib.x64ReleaseStatic: will create the 64 bits version statically linking every third party library into a whole large plugin file.x64ReleaseZ3dyn: will create the 64 bits version statically linking every third party library but z3.lib.The static version of z3.lib is ~ 1.1Gb and the linking time is considerable. That’s the main reason why we have a building version that uses z3 dynamically (as a dll). If you are using z3 dynamically don’t forget to copy the libz3.dll file into the IDA’s directory.If you want to build Triton for linux or MacOsX check this file: https://github.com/illera88/Ponce/tree/master/builds/PonceBuild/nix/README.mdFAQWhy the name of Ponce?Juan Ponce de León (1474 – July 1521) was a Spanish explorer and conquistador. He discovered Florida in the United States. The IDA plugin will help you discover, explore and hopefully conquer the different paths in a binary.Can Ponce be used to analyze Windows, OS X and Linux binaries?Yes, you can natively use Ponce in IDA for Windows or remotely attach to a Linux or OS X box and use it. In the next Ponce version we will natively support Ponce for Linux and OS X IDA versions.How many instructions per second can handle Ponce?In our tests we reach to process 3000 instructions per second. We plan to use the PIN tracer IDA offers to increase the speed.Something is not working!Open an issue, we will solve it ASAP ;)I love your project! Can I collaborate?Sure! Please do pull requests and work in the opened issues. We will pay you in beers for help ;)LimitationsConcolic execution and Ponce have some problems:Symbolic memory load/write: When the index used to read a memory value is symbolic like in x = aray[symbolic_index] some problems arise that could lead on the loose of track of the tainted/symbolized user controled input.Triton doesn’t work very well with floating point instructions.AuthorsAlberto Garcia Illera (@algillera) alberto.garcia@salesforce.comFrancisco Oca (@francisco_oca) foca@salesforce.comDownload Ponce

Link: http://feedproxy.google.com/~r/PentestTools/~3/rD4UX2khHlQ/ponce-ida-plugin-for-symbolic-execution.html

Demystifying the crypter used in Emotet, Qbot, and Dridex

A crypter is software that can encrypt, obfuscate, and manipulate malware to make it harder to detect by security programs. The Zscaler ThreatLabZ research team recently spotted a common crypter being used in the recent Emotet, Qbot, and Dridex campaigns. This same crypter was observed in some of the Ursnif and BitPaymer campaigns as well. One of the reasons that Emotet and Dridex were able to survive for so long can be attributed to their ability to evade detection through the use of a volatile and polymorphic crypter, which wraps its original binary inside to complicate its detection and analysis. Emotet is modular malware that primarily functions as a downloader or dropper for other banking Trojans. Emotet has been active for the past four years and it was one of the most prevalent malware families of 2018. In previous blogs, we analyzed Emotet and one of its delivery campaigns. Dridex is a banking Trojan that evolved from the Zeus Trojan family. Dridex remains active in the wild even after the FBI’s takedown attempt in 2015. Qbot can allow remote access to a victim’s system, steal information, and upload this stolen information to the attacker’s remote server. Recently, Emotet’s payload URLs were found to be serving Qbot and were using the same crypter we’re examining in this report. This crypter provides multiple layers of protection on its core malware binary. In this research, we will describe the properties of crypted binaries that hold true across various mutations. These properties can be validated statically (without executing the binary) and used to write a decrypter. Below is a pictorial view of how Emotet’s core binary is digested inside the crypter’s layers of obfuscation and encryption wrappers. 0. Core binary 1. Code is obfuscated by shuffling instructions and substituting jump instruction 2. Obfuscated binary is encrypted and appended at the end of the custom loader binary 3. File alignment of custom loader binary is jumbled 4. Custom loader binary is encrypted 5. Final binary encapsulating scattered chunks of encrypted custom loader binary   Image 1: Stages occur in crypter Our goal is to reverse each of above stages to get the core malware binary. Furthermore, the core binary is supposed to be independently loadable/executable, and IOCs should be easily extractable. So, starting with stage 5, we will describe certain heuristics properties of the binary and using these properties we will decrypt the stage and continue to track down till stage 0. In our analysis, we found that these heuristics properties hold true across all mutations of the binaries.   Stage 5: The 5th stage binary is the Emotet executable file that is downloaded via malicious links in MalSpams or malicious macros in MS Office documents. Our goal in stage 5 is to reach stage 4 to obtain the encrypted custom loader binary. As we can see in image 1, the binary at this stage contains scattered chunks of encrypted custom loader binary. We need to spot these chunks and assemble them in the proper order. Before discussing how we are going to do this, what follows are few examples of how these chunks can be spread across the binary. The chunks are outlined in red. Image 2. Examples of chunk patterns From the above examples, we can see that these chunks are not found in fixed locations, as their sizes are inconsistent, and the order of chunks varies, too. Therefore, our first challenge is to locate these chunks and arrange them in the proper order. The good news is that we know the crypter will also need to arrange the chunks and will do so by storing the chunk addresses and sizes in a table. Let’s call this table “Chunk Descriptor Table.” The bad news is that this table cannot be found in a predictable location in the binary nor is the structure of the table is constant across mutations of the binary. Below are some of the variants of this table structure. Chunk Descriptor Table is basically an array of the Chunk Descriptor Entry. struct ChunkDescriptorEntry[n] ChunkDescriptorTable; // n == number of chunks Image 3: Examples of Chunk Descriptor Table structures   In above structure, “chunkAddressDword” contains the virtual address of chunk. The size of chunk can be obtained by one of following operations on “firstDword” and “secondDword”. This operation is constant across all chunk descriptor entries. unsigned int chunkSize = firstDword + secondDword unsigned int chunkSize = firstDword ^ secondDword unsigned int chunkSize = secondDword – firstDword Heuristics properties of Chunk Descriptor Table: 0 <=x <=?,      0 <=y <=?,      0 <=z <=? offset(firstDword) < offset(secondDword) < offset(chunkAddressDword) offset(firstDword) < offset(chunkAddressDword) < offset(secondDword) offset(chunkAddressDword) < offset(firstDword) < offset(secondDword) entropy(chunk) > 5 out of 8. Chunks do not contain consecutive 4 zeros. The following is the pseudo code for finding the chunk pattern. The function “FindChunkEntry” return offset of chunk and the distance of firstDword, chunkAddressDword from the beginning of the chunk offset. If the return value of three consecutive calls to function and length between three returned offsets are equal, then the whole array can be parsed to generate an associative array of chunk addresses and chunk sizes. (offset1, m1, n1) = FindChunkEntry(filedata, fileSize) (offset2, m2, n2) = FindChunkEntry(filedata + offset1, fileSize) (offset3, m3, n3) = FindChunkEntry(filedata + offset2, fileSize) If (offset2 – offset1) == (offset3 – offset2)     // found the FindChunkEntry array FindChunkEntry(filedata, fileSize)         p = 0         while p > fileSize                 firstDword = filedata[p]                 q = p                 while q < p + T                 secondDword = filedata[p]                         chunkSize = firstDword (+) secondDword                         r = p – T                         while r < q + T                                 chunkAddress = filedata[r]                                 if ValidateChunk(chunkAddress, chunkSize) == TRUE // Heuristics 5, 6                                         if p < q < r                                                 x = q – p                                                 y = r – q                                                 z = ?                                                 return (p, x, y)                                         elif p < r < q                                                 x = r – p                                                 y = q – r                                                 z = ?                                                 return (p, x, y)                                         elif r < p < q                                                 x = p – r                                                 y = q – p                                                 z = ?                                                 return (r, x, y)                                 r += 4                         q += 4                 p += 4 Now that we have an associative array of chunk address and chunk sizes, we can combine these chunks to get the encrypted custom loader binary. Here we are at stage 4.   Stage 4: ​ In our analysis, we observed that the custom loader binary (PE exe) is encrypted with a simple byte-to-byte addition in the loop with a key array. It is not necessary for the binary to be present at zero offset in this encrypted data. In stage four, our objective is to find the offset of the PE file in the encrypted data and the decryption key. First, we will find the decryption key, which can be brute forced over encrypted data to find the starting offset of the PE file. Decryption is present in the 5th stage binary but not at a predictable location. We will derive the decryption key from the encrypted data itself. The heuristics property to be noted about the encrypted data is a pattern of a repeating consecutive sequence of bytes. This pattern of the repeating sequence is induced by nature of the encryption and the properties of the PE file. In the encrypted data, this pattern will appear at locations that should have filled with zeros when non-encrypted. The following are possible locations. At beginning of the encrypted data because the PE file will not necessarily begin at zero offset. Caves between two sections and between the PE header and the first section. Image 4: Encrypted data showing an example of the repeating sequence of bytes   Image 5: Decrypted data showing the appearance of the corresponding PE file   The repeating sequence is our key and the length of the sequence is the key length. The next thing we need to do is to find the beginning of the key in this consecutively repeating sequence and offset of the PE file. This can be done by simply applying the inverse of the encryption on this sequence and the encrypted data from its starting point while checking against the MZ header. Here is the pseudo code: FindPeFileAndKeyStart (keySequence, keySequenceLen, encryptedData, encryptedDataLen)         k = 0         while (k < keySequenceLen)                 i = 0                 while (i < encryptedDataLen)                         if (    // inverse encryption                             encryptedData[i + 0] – keySequence[k + 0] == 0x4D &&                             encryptedData[i + 1] – keySequence[k + 2] == 0x5A &&                             encryptedData[i + 3] = keySequence[k + 3]                             )                                 peFileOffset = i                                 keyStart = k                                 return (peFileOffset, keyStart)   Now that we have the PE file offset and key, we can decrypt the data with byte-to-byte subtraction with the key in the loop. At this point, we have the custom loader binary, but this custom loader binary has a strange file alignment that we need to normalize. Thus, we are at stage 3. But before proceeding with stage 3, here are few more methods that could also have given us the key in this stage. Search for instruction in the binary of the 5th stage, which accesses the key. Here are the examples that we found in our analysis. 8A 0C 1D FF 31 40 00                          MOV CL, BYTE PTR DS : [EBX + 4031FF] 2A 0C 1D 30 42 40 00                         SUB CL, BYTE PTR DS:[EBX+404230] 8D 84 01 0B 32 36 01                          LEA EAX,DWORD PTR DS:[ECX+EAX+136320B] 8B 1D E4 DD 46 00                              MOV EBX,DWORD PTR DS : [46DDE4] 8D 0D 81 A1 3D 01                              LEA ECX,DWORD PTR DS:[13DA181] 8A 86 77 41 E8 00                                MOV AL, BYTE PTR DS : [ESI + E84177] 8A 98 77 51 C0 00                               MOV BL, BYTE PTR DS : [EAX + C05177] A1 3C FB 46 00                                     MOV EAX,DWORD PTR DS : [46FB3C] DWORD points to a key array; of course it will give a false address. So, we need to validate the key by applying it on encrypted data for each such instruction. 2. In most cases, the key is found just above the pdb path.   Stage 3: At this stage, we have a custom loader binary whose file alignment is messed up. We are going to assign a new file alignment to this PE image which is 0x200. Changing the file alignment is trivial, only requiring us to carefully shift sections of the new file alignment based calculated addresses and updating section addresses and sizes in the Section Header table. Here is the pseudo code. dwNewFileAllignment = 0x200 dwCurrentRawAddress = GetAllignedDwrod(PEHeader.OptionalHeader.SizeOfHeaders, dwNewFileAllignment);         while (i < NumberOfSections)                 NewSecionHeaders[i].PointerToRawData = dwCurrentRawAddress;                 NewSecionHeaders[i].SizeOfRawData = GetAllignedDwrod(OldSecionHeaders[i].SizeOfRawData, dwNewFileAllignment);                 Memcpy(pbyNewFileBuffer + dwCurrentRawAddress,                                 pbyOldFileData + OldSecionHeaders[i].PointerToRawData,                                 OldSecionHeaders[i].SizeOfRawData);                 dwCurrentRawAddress += GetAllignedDwrod(OldSecionHeaders[i].SizeOfRawData, dwNewFileAllignment);                 dwCurrentRawAddress = GetAllignedDwrod(dwCurrentRawAddress, dwNewFileAllignment);                 i = i + 1 This is it, we have plain and loadable binary of custom loader. That moved us to stage 2.   Stage 2: In the appended data of the custom loader, there is encrypted data which is nothing but an obfuscated version of the core malware binary. The encryption method is the same as that of stage 4. All we need to do here is calculate the offset of the appended data and apply the decryption technique mentioned in the 4th stage. As a result, we got the core PE file, but it needed some fixes in the code as some instructions were missing in the binary.   Stage 1: At this stage, we have a PE file which is somewhat incomplete because the loader binary had already eaten up some instructions from the code section. These eaten instructions will be put in memory and a JUMP instruction will be inserted in the code of the core binary, which points to the corresponding eaten instructions. Then the control is passed over to the core binary. The below image is an example of how this obfuscation appears.   Image 6: Obfuscated code with JUMP instruction   The final objective is to de-obfuscate the code of the core binary. That means we need to return the eaten instructions back to their actual location and remove the JUMPs. At this point, the above code will appear as follows.   Image 7: De-obfuscated code It is the loader’s responsibility to smoothly execute the core malware even after instructions are placed in different locations. The loader needs to calculate the JUMP address of the moved instructions and put the JUMP instructions in place of those instructions. For this, the moved instructions and their meta information are stored in the loader’s binary itself. In our analysis, we found that the table containing this information was present in the “.rdata” section. struct DeobfuscationTable {         unsigned int dwOrgInstrVAdddress; // Address of eaten instruction in loader’s binary         unsigned int dwPatchRVAddress;    // Offset where Jump need to insert         unsigned int dwOrgInstrLength;    // length of moved instructions in bytes };   Once we get the de-obfuscation table, we just need to read “dwOrgInstrLength” bytes from the virtual address “dwOrgInstrVAdddress” loader’s binary and write them to a relative virtual address “dwPatchRVAddress” in the core malware binary. Here is the pseudo code for this. while (pDeObfuscationTable-> dwOrgInstrVAdddress !=  0x00) {         patchOffset = GetFileOffsetFromRVA(         pCorePEHeader,         pCoreSectionHeaders,         pDeObfuscationTable-> dwPatchRVAddress);         orgInsOffset = GetFileOffsetFromRVA(         pLoaderPEHeader,         pLoaderSectionHeaders,         pDeObfuscationTable-> dwOrgInstrVAdddress – pLoaderPEHeader-OptionalHeader.ImageBase);         memcpy (                 pbyCoreFileData + dwPatchOffset,                 pbyLoaderFileData + orgInstrOffset,                 pDeObfuscationTable->dwOrgInstrLength);         pDeObfuscationTable += 1; }   At this stage, we would have obtained the plain, independently executable core Emotet binary, which can be decompiled by IDA or can be bin-diffed with other binaries extracted by this decoder.  

Link: https://www.zscaler.com/blogs/research/demystifying-crypter-used-emotet-qbot-and-dridex