- #INSTALLBUILDER ACTION LIST INSTALL#
- #INSTALLBUILDER ACTION LIST ARCHIVE#
- #INSTALLBUILDER ACTION LIST CODE#
This time comparing BitRock installer files yielded interesting results.
#INSTALLBUILDER ACTION LIST CODE#
Using existing bitrock-unpacker code I created this Tcl script to dump all installer files from the Metakit database to disk.
#INSTALLBUILDER ACTION LIST ARCHIVE#
That also meant that I needed to dig a bit further.Īfter going through bitrock-unpacker code I noticed that it first mounted the Metakit database in order to extract installer files that were used to locate and extract the Cookfs archive storing JXplorer files. To my surprise there were no differences which meant that JXplorer application files were left intact. Then I used the WinMerge tool to compare resulting files and directories. Once I installed the ActiveTcl and downloaded required SDX file I used the bitrock-unpacker script to unpack JXplorer installation files from both installers.
#INSTALLBUILDER ACTION LIST INSTALL#
Fortunately, JXplorer web page mentioned that JXplorer was using the BitRock Install Builder and after short search I managed to find the following Tcl unpacker for BitRock archives: bitrock-unpacker. The identified ZLIB data was placed in the PE file overlay space and I figured that it was likely part of an archive used by the installer to store JXplorer files. The first two differences did not seem to be important so I focused on the last one. Note the clear text file names just before the ZLIB header ( http-2.7.9.tm, platform-1.0.10.tm): A relatively small (3230 bytes) blob of what seemed to be ZLIB compressed data at offset 0x4be095.Additional newline character appended to the file - explaining 1 byte size difference between the files.The original file required Administrator privileges ( requireAdministrator) while the modified was fine with running with caller’s privilege level
The manifest file located in the resource section, specifically the requestedExecutionLevel property.The tool actually revealed the following modifications: I was not sure how content of the PE resource section could affect behavior of the installer so I used VBinDiff to see the exact difference. The sections were all identical, with exception of the resource section. As binaries were packed with UPX, I unpacked them with the upx tool and compared MD5s of PE sections.
Last thing I wanted to do was to disassemble two 7 megabytes PE binaries so I started with simpler checks in order to locate difference(s). Unsurprisingly, the MD5 hashes of both files were different. In order to validate my VirusTotal finding I downloaded a matching version of Windows installer (3.3.1.2) from the official JXplorer SourceForge repository. However, analyzing the JXplorer binary turned out to be only the first step into the world of backdoored software.
I initially planned to keep this write-up short and focus on dissecting suspicious JXplorer binary. Why was it strange? Mostly because I did not expect an installer for a quite popular LDAP browser to create a scheduled task in order to download and execute PowerShell code from a subdomain hosted by free dynamic DNS provider: The file claimed to be an installer for the JXplorer 3.3.1.2, a Java-based “cross platform LDAP browser and editor” as indicated on its official web page. Recently I was playing with VirusTotal Intelligence and while testing some dynamic behavior queries I stumbled upon this strange PE binary (MD5: 7fce12d2cc785f7066f86314836c95ec).
0 kommentar(er)
