{"id":2300,"date":"2019-05-03T20:01:30","date_gmt":"2019-05-04T04:01:30","guid":{"rendered":"https:\/\/www.pnfsoftware.com\/blog\/?p=2300"},"modified":"2019-05-06T08:29:21","modified_gmt":"2019-05-06T16:29:21","slug":"siglibgen-native-signatures-generation-for-jeb","status":"publish","type":"post","link":"https:\/\/www.pnfsoftware.com\/blog\/siglibgen-native-signatures-generation-for-jeb\/","title":{"rendered":"Native Signatures Generation"},"content":{"rendered":"\n<p>JEB 3.3 ships with our internal tool <strong>SiglibGen<\/strong> to generate signatures for native routines. Until now, users could sign individual routines only from JEB user interface (menu Native&gt; Create Signature for Procedure), or with the <a rel=\"noreferrer noopener\" aria-label=\"auto-signing mode (opens in a new tab)\" href=\"https:\/\/www.pnfsoftware.com\/blog\/jeb3-auto-signing-mode\/\" target=\"_blank\">auto-signing mode<\/a>. <\/p>\n\n\n\n<p>With the release of SiglibGen, users can now create signatures for whole files in batch mode, notably executables (PE, ELF) libraries (Microsoft COFF and AR files) and JDB2 (JEB project files)<sup class='footnote'><a href='#fn-2300-1' id='fnref-2300-1' onclick='return fdfootnote_show(2300)'>1<\/a><\/sup>.<\/p>\n\n\n\n<p>In this post, we will explain how SiglibGen allows power-users to generate custom signature libraries, in order to quickly identify similar code between different executables. <\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Signature Libraries (siglibs)<\/h2>\n\n\n\n<p>Signature libraries are stored in <code>&lt;JEB install folder&gt;\/siglibs<\/code> folder. Each signature contains a set of <em>features<\/em> identifying a routine (detailed below), and a set of <em>attributes<\/em> representing the knowledge about the routine (name, internal labels, comments&#8230;).<\/p>\n\n\n\n<p>JEB currently ships with signature libraries for x86\/x64 Microsoft Visual Studio libraries (from Visual Studio 2008 to 2017), and for <a rel=\"noreferrer noopener\" aria-label=\" (opens in a new tab)\" href=\"https:\/\/www.pnfsoftware.com\/blog\/android-ndk-libraries-signatures\/\" target=\"_blank\">ARM\/ARM64 Android NDKs<\/a> (from NDKr10 to NDKr19). These signatures will be automatically loaded when a suitable file is opened (see File&gt;Engines&gt;Signature Libraries for the complete list of available signature libraries).<\/p>\n\n\n\n<p>These compiler signatures are intended to be &#8220;false positive free&#8221;, i.e. they should only identify the exact same routine (though it can be mapped at a different location). Therefore, the signatures can be blindly trusted by users, and by JEB automatic analysis<sup class='footnote'><a href='#fn-2300-2' id='fnref-2300-2' onclick='return fdfootnote_show(2300)'>2<\/a><\/sup>.<\/p>\n\n\n\n<p>But users might want to generate their own signature libraries, for example in the following scenarios:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>User analyzed an unknown executable. The resulting JDB2 file can then be signed, such that all routines can be identified in others executables and related information (name, comments, labels) be imported.<\/li><li> User found out that an executable is statically linked with a public library. The library can then be compiled with symbols and signed such that the library routines will be renamed in the analyzed executable<sup class='footnote'><a href='#fn-2300-3' id='fnref-2300-3' onclick='return fdfootnote_show(2300)'>3<\/a><\/sup>.<\/li><\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Use Case: Operation ShadowHammer<\/h2>\n\n\n\n<p>To illustrate the signatures generation process, we are going to use the recent attack dubbed &#8220;Operation ShadowHammer&#8221; as an example. This operation was originally documented by <a href=\"https:\/\/securelist.com\/operation-shadowhammer\/89992\/\">Kaspersky<\/a>. Roughly summarized, malicious code was inserted into a legitimate ASUS&#8217;s automatic update tool named &#8220;ASUS Live Update Utility&#8221; <sup class='footnote'><a href='#fn-2300-4' id='fnref-2300-4' onclick='return fdfootnote_show(2300)'>4<\/a><\/sup> . <\/p>\n\n\n\n<p>In this use case, we are going to put ourselves in the shoes of an analyst willing to understand the trojanized ASUS installers. <strong>We do not intend to analyze them in-depth &#8211; it has been done several times already -,  but rather show how SiglibGen can accelerate the analysis.<\/strong> <\/p>\n\n\n\n<p>At first, we got our hands on three samples, originally mentioned in <a href=\"https:\/\/www.countercept.com\/blog\/analysis-shadowhammer-asus-attack-first-stage-payload\/\">CounterCept&#8217;s analysis<\/a> with their date of use:<\/p>\n\n\n\n<table class=\"wp-block-table\"><tbody><tr><td>SHA-256<\/td><td>Date Of Use<\/td><\/tr><tr><td><code>6aedfef62e7a8ab7b8ab3ff57708a55afa1a2a6765f86d581bc99c738a68fc74<\/code><\/td><td>June<\/td><\/tr><tr><td><code>736bda643291c6d2785ebd0c7be1c31568e7fa2cfcabff3bd76e67039b71d0a8<\/code><\/td><td>September<\/td><\/tr><tr><td><code>9a72f971944fcb7a143017bc5c6c2db913bbb59f923110198ebd5a78809ea5fc<\/code><\/td><td>October<\/td><\/tr><\/tbody><\/table>\n\n\n\n<h3 class=\"wp-block-heading\">Oldest Sample<\/h3>\n\n\n\n<h4 class=\"wp-block-heading\">Quick Analysis<\/h4>\n\n\n\n<p>An analyst would likely start looking at the oldest sample (6aedfef6&#8230;), in order to investigate possible evolution of the attack.  In this sample, the installer&#8217;s <code>main()<\/code> routine was modified to load a malicious PE executable from its resources:<\/p>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"aligncenter is-resized\"><a href=\"https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/old_embedded.png\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/old_embedded.png\" alt=\"\" class=\"wp-image-2333\" width=\"273\" height=\"425\" srcset=\"https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/old_embedded.png 359w, https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/old_embedded-193x300.png 193w\" sizes=\"auto, (max-width: 273px) 100vw, 273px\" \/><\/a><figcaption>JEB Project View. The embedded executable can be seen in resources<sup class='footnote'><a href='#fn-2300-5' id='fnref-2300-5' onclick='return fdfootnote_show(2300)'>5<\/a><\/sup>.<\/figcaption><\/figure><\/div>\n\n\n\n<p>Here is the memory map after opening the malicious executable in JEB:<\/p>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"aligncenter\"><img loading=\"lazy\" decoding=\"async\" width=\"553\" height=\"29\" src=\"https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/old_payload_init_mem_map.png\" alt=\"\" class=\"wp-image-2420\" srcset=\"https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/old_payload_init_mem_map.png 553w, https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/old_payload_init_mem_map-300x16.png 300w\" sizes=\"auto, (max-width: 553px) 100vw, 553px\" \/><figcaption>Embedded PE navigation view. Blue is code, cyan is code identified by siglib, green is data.<br><\/figcaption><\/figure><\/div>\n\n\n\n<p>The large chunks of cyan correspond to routines identified as being part of &#8220;Microsoft Visual C++ 2010 \/MT&#8221; libraries. Then, we analyzed the remaining seven routines (the blue chunk in the navigation view), and renamed them as follow:<\/p>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"aligncenter\"><img loading=\"lazy\" decoding=\"async\" width=\"324\" height=\"187\" src=\"https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/image-4.png\" alt=\"\" class=\"wp-image-2422\" srcset=\"https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/image-4.png 324w, https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/image-4-300x173.png 300w\" sizes=\"auto, (max-width: 324px) 100vw, 324px\" \/><figcaption>Malicious Routines (our names)<\/figcaption><\/figure><\/div>\n\n\n\n<p>These routines implement the following logic: check if one of the machine&#8217;s <a href=\"https:\/\/en.wikipedia.org\/wiki\/MAC_address\">MAC address<\/a> match a hard coded list, and if it&#8217;s the case download a payload (otherwise a <code>.idx<\/code> log file is dropped).<\/p>\n\n\n\n<p>Now in order to re-use this knowledge on more recent trojanized ASUS installers, let&#8217;s generate signatures for this first sample.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Generating Signatures <\/h4>\n\n\n\n<p>In order to sign the analyzed file, we are going to create a configuration file from the sample file provided in <code>&lt;JEB install folder&gt;\/siglibs\/custom<\/code>:<\/p>\n\n\n<div class=\"wp-block-syntaxhighlighter-code \"><pre class=\"brush: plain; highlight: [13,18,24,28,31,35,38,41,44,50,56]; title: ; notranslate\" title=\"\">\n;------------------------------------------------------------------------------\n; *** SAMPLE *** JEB Signature Library configuration file\n;------------------------------------------------------------------------------\n\n;template file used to configure the generation of a *.siglib file for JEB\n\n;how to generate the siglib specified by this file?\n;open a terminal and execute: (eg, on Windows)\n;  $ ..\\..\\jeb_wincon.bat -c --siglibgen=sample-siglib.cfg\n\n;(mandatory) name of the folder containing files to sign\n; must be in the same folder as this configuration file \ninput_folder_name=\n\n;(mandatory) processor type \n; see com.pnfsoftware.jeb.core.units.codeobject.ProcessorType \n; eg: X86, X86_64, ARM, ARM64, MIPS, MIPS64\nprocessor=\n\n;(mandatory) output siglib file name\n; &#039;.siglib&#039; extension will be appended to it\n; IMPORTANT! once generated, this file must be moved to the &amp;lt;JEB&gt;\/siglibs\/ folder\n; (user generated siglibs have to be manually loaded)\noutput_file_name=mysiglib\n\n;(mandatory) unique identifier for your siglib\n; keep it &amp;lt; 0 and decrement for each package you generate\nuuid=-1\n\n;(mandatory) *absolute* path to JEB typelibs folder, usually &amp;lt;JEB&gt;\/typelibs\ntypelibs_folder=\n\n;(mandatory) name of your package\n; e.g. &#039;Microsoft Visual C++ 2008 signatures&#039; (without &#039;&#039;)\npackage_name=\n\n;(mandatory) package version\npackage_version=0\n\n;(optional) description of your package\npackage_description=\n\n;(optional) package author\npackage_author=\n\n;(mandatory) list of features included in each signature\n; i.e. the characteristics of the signed routines serving to identify them\n; see com.pnfsoftware.jeb.core.units.code.asm.sig.NativeFeatureSignerID\n; note: defaults should be suitable for most cases. ROUTINE_SIZE must always be included. \nfeatures=ROUTINE_SIZE,ROUTINE_CODE_HASH,CALLED_ROUTINE_NAME_ONLY_EXTERN \n\n;(mandatory) list of attributes included in each signature\n; i.e. additional knowledge on the signed routines conveyed by signatures \n; (other than routine name)\n; see com.pnfsoftware.jeb.core.units.code.asm.sig.NativeAttributeSignerID\nattributes=COMMENT,LABEL\n<\/pre><\/div>\n\n\n<p>A particularly interesting part of this configuration is the <code>features<\/code> field, where users can select the characteristics of the routine they want to put in signatures. The complete feature list can be found <a href=\"https:\/\/www.pnfsoftware.com\/jeb\/apidoc\/reference\/com\/pnfsoftware\/jeb\/core\/units\/code\/asm\/sig\/NativeFeatureSignerID.html\">here<\/a>; here are the features we included in our case (the default ones):<\/p>\n\n\n\n<table class=\"wp-block-table aligncenter has-fixed-layout\"><tbody><tr><td><strong>Feature Name<\/strong><\/td><td><strong>Description<\/strong><\/td><\/tr><tr><td>ROUTINE_SIZE<\/td><td>Size of the routine (number of instructions).<\/td><\/tr><tr><td>ROUTINE_CODE_HASH<\/td><td>Custom hash computed from the routine assembly code.<\/td><\/tr><tr><td>CALLED_ROUTINE_NAME_ONLY_EXTERN<\/td><td>Names of the <em>external<\/em> routines called by the signed routine.<\/td><\/tr><\/tbody><\/table>\n\n\n\n<p>Note that by including ROUTINE_CODE_HASH, our signatures will only match routines with the exact same code (but possibly mapped at a different location). The use of  <br>CALLED_ROUTINE_NAME_ONLY_EXTERN allows to distinguish different wrapper routines calling different API routines, but having the same code.<\/p>\n\n\n\n<p>Here is the specific configuration file <code>shadowhammer-oldest.cfg<\/code> we made for this first sample:<\/p>\n\n\n<div class=\"wp-block-syntaxhighlighter-code \"><pre class=\"brush: plain; title: ; notranslate\" title=\"\">\ninput_folder_name=input\nprocessor=X86\noutput_file_name=shadowhammer-6aedfef6\nuuid=-1\ntypelibs_folder=&#x5B;...REDACTED...]\\typelibs\npackage_name=ShadowHammer -- sample 6aedfef6 (oldest)\npackage_version=0\npackage_description=Signatures generated from the analysis of the oldest sample known\npackage_author=Joan Calvet\nfeatures=ROUTINE_SIZE,ROUTINE_CODE_HASH,CALLED_ROUTINE_NAME_ONLY_EXTERN \nattributes=COMMENT,LABEL\n<\/pre><\/div>\n\n\n<p>Then we put the JDB2 file of the analyzed sample into the <code>input<\/code> folder (see configuration&#8217;s <code>input_folder_name<\/code> field). SiglibGen can then be called by executing JEB startup script (e.g. <code>jeb_wincon.bat<\/code>) with the following flags:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>$jeb -c --siglibgen=shadowhammer-oldest.cfg<\/code><\/pre>\n\n\n\n<p>The generated signature libraries will then be written in the <code>output<\/code> folder. In our case, SiglibGen signed our seven routines, as indicated in <code>siggen_stat.log<\/code> file <sup class='footnote'><a href='#fn-2300-6' id='fnref-2300-6' onclick='return fdfootnote_show(2300)'>6<\/a><\/sup>:<\/p>\n\n\n<div class=\"wp-block-syntaxhighlighter-code \"><pre class=\"brush: plain; gutter: false; highlight: [3]; title: ; notranslate\" title=\"\">\n&gt; Package created on 2019.05.01.15.29.23\n&gt; metadata: X86\/ShadowHammer -- sample 6aedfef6 (oldest)\/0\/Signatures generated from the analysis of the oldest sample known\/Joan Calvet\/1556738959\n&gt; # sigs created: 7\n&gt; # very small routines: 0\n&gt; # small routines: 0\n&gt; # medium routines: 6\n&gt; # large routines: 1\n&gt; # unnamed routines: 1\n&gt; # blacklisted routines: 0\n&gt; # duplicated routines: 0\n<\/pre><\/div>\n\n\n<p>We can now copy <code>shadowhammer-6aedfef6.siglib<\/code> to <code>&lt;JEB&gt;\/siglibs\/<\/code> folder. It will now be available under File&gt;Engines&gt;Signature Libraries to be manually loaded.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Second Sample Analysis<\/h3>\n\n\n\n<p>Now, it is time to turn to the second sample (736bda6432&#8230;). The workflow is quite different from the previous one: a routine call has been inserted into Visual Studio library method <code>__crtExitProcess<\/code>, which is called whenever the program exists:<\/p>\n\n\n\n<figure class=\"wp-block-image\"><a href=\"https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/second_trojanized_crt_exit.png\"><img loading=\"lazy\" decoding=\"async\" width=\"1018\" height=\"388\" src=\"https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/second_trojanized_crt_exit.png\" alt=\"\" class=\"wp-image-2458\" srcset=\"https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/second_trojanized_crt_exit.png 1018w, https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/second_trojanized_crt_exit-300x114.png 300w, https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/second_trojanized_crt_exit-768x293.png 768w\" sizes=\"auto, (max-width: 1018px) 100vw, 1018px\" \/><\/a><figcaption>Trojanized __crtExitProcess. Call to __crtCorExitProcess was replaced by a call to malicious code.<\/figcaption><\/figure>\n\n\n\n<p class=\"has-background has-light-gray-background-color\">The astute reader might wonder why the routine is still named <code>__crtExitProcess()<\/code>, as if it was the original one, if one of its call has been rewritten to point elsewhere. In this case, the routine&#8217;s name comes from the fact that several caller routines were identified as library code (and are known to call <code>__crtExitProcess()<\/code>), as indicated by the routine header comment &#8220;Routine&#8217;s name comes from a caller [&#8230;]&#8221;.<\/p>\n\n\n\n<p>Following the dubious call, we end up decrypting the malicious payload, which is then executed. We can load the malicious dump in JEB with the x86 processor and the correct base address. After manually defining the code area, we obtain the following navigation view:<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"654\" height=\"33\" src=\"https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/second_payload_init_mem_map.png\" alt=\"\" class=\"wp-image-2466\" srcset=\"https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/second_payload_init_mem_map.png 654w, https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/second_payload_init_mem_map-300x15.png 300w\" sizes=\"auto, (max-width: 654px) 100vw, 654px\" \/><figcaption>Memory dump&#8217;s initial navigation view. Blue is code.<\/figcaption><\/figure>\n\n\n\n<p>For now, no compiler signature libraries were loaded because it is a memory dump without a proper PE header. As we know the previous malicious sample was compiled with Visual Studio 2010 \/MT libraries, we can manually load the corresponding signatures (File&gt;Engines&gt;Signature Libraries). Here is the navigation bar at this time:<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"659\" height=\"38\" src=\"https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/second_payload_mem_map_2.png\" alt=\"\" class=\"wp-image-2467\" srcset=\"https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/second_payload_mem_map_2.png 659w, https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/second_payload_mem_map_2-300x17.png 300w\" sizes=\"auto, (max-width: 659px) 100vw, 659px\" \/><figcaption>Memory dump&#8217;s navigation view with Visual Studio 2010 \/MT signature libraries loaded. Blue is code, cyan is library code. <\/figcaption><\/figure>\n\n\n\n<p>Most of the code has been identified. Now, we can load the custom signatures we generated from the previous sample, and we end up with two more routines being identified (i.e. miscreants directly re-used them from the first sample): <\/p>\n\n\n\n<ul class=\"wp-block-gallery columns-2 is-cropped\"><li class=\"blocks-gallery-item\"><figure><img loading=\"lazy\" decoding=\"async\" width=\"818\" height=\"275\" src=\"https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/second_id_routine_1-1.png\" alt=\"\" data-id=\"2471\" data-link=\"https:\/\/www.pnfsoftware.com\/blog\/?attachment_id=2471\" class=\"wp-image-2471\" srcset=\"https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/second_id_routine_1-1.png 818w, https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/second_id_routine_1-1-300x101.png 300w, https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/second_id_routine_1-1-768x258.png 768w\" sizes=\"auto, (max-width: 818px) 100vw, 818px\" \/><\/figure><\/li><li class=\"blocks-gallery-item\"><figure><img loading=\"lazy\" decoding=\"async\" width=\"811\" height=\"269\" src=\"https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/second_id_routine_2.png\" alt=\"\" data-id=\"2472\" data-link=\"https:\/\/www.pnfsoftware.com\/blog\/?attachment_id=2472\" class=\"wp-image-2472\" srcset=\"https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/second_id_routine_2.png 811w, https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/second_id_routine_2-300x100.png 300w, https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/second_id_routine_2-768x255.png 768w\" sizes=\"auto, (max-width: 811px) 100vw, 811px\" \/><\/figure><\/li><\/ul>\n\n\n\n<p>We can now look at the non-identified routines, without having to reanalyze the duplicates.<\/p>\n\n\n\n<p>Finally, after having analyzed the remaining routines, we can generate a new signature library, following the same steps previously described. This time we put two samples in the input folder (the trojanized installer&#8217;s JDB2, and the memory dump&#8217;s JDB2). <strong>Eight routines are then signed.<\/strong><\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Third Sample Analysis<\/h3>\n\n\n\n<p>The most recent sample (9a72f971944f&#8230;) follows the same logic as the previous one, namely it dynamically decrypts the malicious code, which is then executed. As previously, we load the memory dump in JEB with Visual Studio 2010 \/MT signatures:<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"660\" height=\"33\" src=\"https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/third_payload_mem_map_vs-2.png\" alt=\"\" class=\"wp-image-2512\" srcset=\"https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/third_payload_mem_map_vs-2.png 660w, https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/third_payload_mem_map_vs-2-300x15.png 300w\" sizes=\"auto, (max-width: 660px) 100vw, 660px\" \/><figcaption> Memory dump&#8217;s navigation view with Visual Studio 2010 \/MT signature libraries loaded.   <\/figcaption><\/figure>\n\n\n\n<p>Finally, we load the ShadowHammer signature libraries generated from the previous two samples:<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"654\" height=\"34\" src=\"https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/third_payload_mem_map_vs_shadow.png\" alt=\"\" class=\"wp-image-2500\" srcset=\"https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/third_payload_mem_map_vs_shadow.png 654w, https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/third_payload_mem_map_vs_shadow-300x16.png 300w\" sizes=\"auto, (max-width: 654px) 100vw, 654px\" \/><figcaption>Memory dump&#8217;s navigation view with  <br>Visual Studio 2010 \/MT and ShadowHammer signature libraries loaded.  <br><\/figcaption><\/figure>\n\n\n\n<p>At this point, <strong>only one malicious routine has not been identified<\/strong> (the large blue area in the navigation view). We can now focus on it, knowing that the rest of the code is the same. <\/p>\n\n\n\n<p>If we open the two binaries side-by-side, we can rapidly pinpoint that the unidentified routine has indeed been modified between the two samples. For example:<\/p>\n\n\n\n<ul class=\"wp-block-gallery columns-2 is-cropped wp-block-gallery-1 is-layout-flex wp-block-gallery-is-layout-flex\"><li class=\"blocks-gallery-item\"><figure><a href=\"https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/modified_rtn_sample1.png\"><img loading=\"lazy\" decoding=\"async\" width=\"693\" height=\"311\" src=\"https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/modified_rtn_sample1.png\" alt=\"\" data-id=\"2532\" data-link=\"https:\/\/www.pnfsoftware.com\/blog\/?attachment_id=2532\" class=\"wp-image-2532\" srcset=\"https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/modified_rtn_sample1.png 693w, https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/modified_rtn_sample1-300x135.png 300w\" sizes=\"auto, (max-width: 693px) 100vw, 693px\" \/><\/a><figcaption>Sample 736bda643291c<\/figcaption><\/figure><\/li><li class=\"blocks-gallery-item\"><figure><a href=\"https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/modified_rtn_sample2.png\"><img loading=\"lazy\" decoding=\"async\" width=\"579\" height=\"308\" src=\"https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/modified_rtn_sample2.png\" alt=\"\" data-id=\"2533\" data-link=\"https:\/\/www.pnfsoftware.com\/blog\/?attachment_id=2533\" class=\"wp-image-2533\" srcset=\"https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/modified_rtn_sample2.png 579w, https:\/\/www.pnfsoftware.com\/blog\/wp-content\/uploads\/2019\/04\/modified_rtn_sample2-300x160.png 300w\" sizes=\"auto, (max-width: 579px) 100vw, 579px\" \/><\/a><figcaption>Sample 9a72f971944fc <\/figcaption><\/figure><\/li><\/ul>\n\n\n\n<p>It appears the hardcoded list of searched MAC addresses (represented by their MD5 hashes) has been modified between the two samples.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Conclusion<\/h2>\n\n\n\n<p>We hope this blog post demonstrated how SiglibGen allows users to speed up their analysis by easily re-using their work. Remember that signatures can be generated in a lighter manner directly from JEB UI (as shown in the <a href=\"https:\/\/www.pnfsoftware.com\/blog\/jeb3-auto-signing-mode\/\">auto-signing mode video<\/a>). As usual, do not hesitate to contact us if you have any questions (<a href=\"mailto:support@pnfsoftware.com\">email<\/a>,&nbsp;<a href=\"https:\/\/twitter.com\/jebdec\">Twitter<\/a>,&nbsp;<a href=\"https:\/\/jebdecompiler.slack.com\/\">Slack<\/a>).<\/p>\n\n\n\n<p class=\"has-background has-light-gray-background-color\">Note: SiglibGen might set <code>.parsers.*.AnalysisStyle<\/code> and <code>.parsers.*.AllowAdvancedAnalysis <\/code>engines option to specific values suitable for signatures generation, <strong>without restoring the original values after the generation<\/strong>. For now, JEB power-users have to manually restore these two engines options to the intended values after having generated signatures (menu Edit>Options>Engines). This will be fixed in next release JEB 3.4.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"annex-a\">Annex: SiglibGen Log Files<\/h2>\n\n\n\n<p>A typical SiglibGen run will produce several log files (in the same folder):<\/p>\n\n\n\n<table class=\"wp-block-table\"><tbody><tr><td>File Name<\/td><td>Purpose<\/td><\/tr><tr><td>siggen_stat.log<\/td><td>Summary log (number of signatures created, etc). A new entry is appended to the log file at each signature generation.<\/td><\/tr><tr><td>siggen_report.html<\/td><td>Complete HTML log file; each signed routine is shown with the corresponding features and attributes.<\/td><\/tr><tr><td>conflicts.txt<\/td><td>Conflict resolution file; users can tweak here the decisions taken when several routines have the same features (and then regenerate the signatures).<\/td><\/tr><tr><td>removals.txt<\/td><td>Removals resolution file; users can tweak here the automatic decisions regarding removing certain signatures (and then regenerate the signatures) .<\/td><\/tr><\/tbody><\/table>\n\n\n\n<p><\/p>\n\n\n<div class='footnotes' id='footnotes-2300'><div class='footnotedivider'><\/div><ol><li id='fn-2300-1'> More formats could be handled, do not hesitate to <a href=\"mailto:support@pnfsoftware.com\">contact us<\/a> if you have such needs. <span class='footnotereverse'><a href='#fnref-2300-1'>&#8617;<\/a><\/span><\/li><li id='fn-2300-2'> While the signatures shown in this blog post will also be generated in a false positive free manner, SiglibGen allows to build more flexible signatures; this will the topic of another blog post. <span class='footnotereverse'><a href='#fnref-2300-2'>&#8617;<\/a><\/span><\/li><li id='fn-2300-3'> If signatures were built to be strict (i.e. not allowing any modifications to the original routine), this can be far from trivial, as the library needs to be compiled with the exact same options as the analyzed executable. <span class='footnotereverse'><a href='#fnref-2300-3'>&#8617;<\/a><\/span><\/li><li id='fn-2300-4'> There are numerous excellent analysis available for Operation ShadowHammer, like the one from <a href=\"https:\/\/www.countercept.com\/blog\/analysis-shadowhammer-asus-attack-first-stage-payload\/\">CounterCept<\/a>. <span class='footnotereverse'><a href='#fnref-2300-4'>&#8617;<\/a><\/span><\/li><li id='fn-2300-5'> Note that thanks to JEB recursive processing, the embedded executable does not need to be extracted, and can be directly analyzed within the original JEB&#8217;s project <span class='footnotereverse'><a href='#fnref-2300-5'>&#8617;<\/a><\/span><\/li><li id='fn-2300-6'> See <a href=\"https:\/\/www.pnfsoftware.com\/blog\/wp-admin\/post.php?post=2300&amp;action=edit#annex-a\">Annex<\/a> for a description of all log files produced by SiglibGen. <span class='footnotereverse'><a href='#fnref-2300-6'>&#8617;<\/a><\/span><\/li><\/ol><\/div>","protected":false},"excerpt":{"rendered":"<p>JEB 3.3 ships with our internal tool SiglibGen to generate signatures for native routines. Until now, users could sign individual routines only from JEB user interface (menu Native&gt; Create Signature for Procedure), or with the auto-signing mode. With the release of SiglibGen, users can now create signatures for whole files in batch mode, notably executables &hellip; <a href=\"https:\/\/www.pnfsoftware.com\/blog\/siglibgen-native-signatures-generation-for-jeb\/\" class=\"more-link\">Continue reading <span class=\"screen-reader-text\">Native Signatures Generation<\/span><\/a><\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[18,2,13],"tags":[],"class_list":["post-2300","post","type-post","status-publish","format-standard","hentry","category-jeb3","category-malware","category-native-code"],"_links":{"self":[{"href":"https:\/\/www.pnfsoftware.com\/blog\/wp-json\/wp\/v2\/posts\/2300","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.pnfsoftware.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.pnfsoftware.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.pnfsoftware.com\/blog\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/www.pnfsoftware.com\/blog\/wp-json\/wp\/v2\/comments?post=2300"}],"version-history":[{"count":0,"href":"https:\/\/www.pnfsoftware.com\/blog\/wp-json\/wp\/v2\/posts\/2300\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.pnfsoftware.com\/blog\/wp-json\/wp\/v2\/media?parent=2300"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.pnfsoftware.com\/blog\/wp-json\/wp\/v2\/categories?post=2300"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.pnfsoftware.com\/blog\/wp-json\/wp\/v2\/tags?post=2300"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}