{"id":9828,"date":"2025-01-25T01:22:29","date_gmt":"2025-01-25T01:22:29","guid":{"rendered":"https:\/\/www.hexacorn.com\/blog\/?p=9828"},"modified":"2025-01-25T16:36:55","modified_gmt":"2025-01-25T16:36:55","slug":"being-a-tool-while-using-a-tool","status":"publish","type":"post","link":"https:\/\/www.hexacorn.com\/blog\/2025\/01\/25\/being-a-tool-while-using-a-tool\/","title":{"rendered":"Being a tool while using a tool"},"content":{"rendered":"\n

This case is kinda DFIR-fascinating.<\/p>\n\n\n\n

There is an unwritten rule in the DFIR world that says – always check the results provided by one tool, with another tool, or manually…<\/p>\n\n\n\n

Well… it all sounds nice in theory, until we come across a case that will change it all.<\/p>\n\n\n\n

So…<\/p>\n\n\n\n

If you use many different tools, and on regular basis, be warned that this case will destroy your faith in them…<\/p>\n\n\n\n

Ready?<\/p>\n\n\n\n

Let’s go!<\/p>\n\n\n\n

I have been using Total Commander for over 2 decades. I absolutely love this tool, and can’t imagine working with gazillion of files and samples that I play with on regular basis, without using it.<\/p>\n\n\n\n

But recently, I got fooled by it.<\/p>\n\n\n\n

When you download the Signal desktop client installer for Windows (v7.39), you can browse its contents with Total Commander+its (various) archive plugins to see the following output:<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

I was specifically interested in the Signal.exe<\/code> binary so I used TC to copy Signal.exe<\/code> to my temporary work folder.<\/p>\n\n\n\n

To my surprise, the sigcheck reported that this binary was compiled for… ARM processors!<\/p>\n\n\n\n

Verified:       Signed\nSigning date:   01:00 2025-01-23\nPublisher:      Signal Messenger, LLC\nCompany:        Signal Messenger, LLC\nDescription:    Signal\nProduct:        Signal\nProd version:   7.39.0.0\nFile version:   7.39.0\nMachineType:    64-bit ARM<\/pre>\n\n\n\n
Huh?<\/p>\n\n\n\n
I was puzzled. <\/p>\n\n\n\n
I literally downloaded what I believed to be an installer of Signal that was meant for Intel-based Windows, but now I am seeing the ARM binary inside it!<\/p>\n\n\n\n
<Anxiety level intensifies><\/p>\n\n\n\n
I then tried the very same approach with the installer of the older version of Signal (7.38), but the result was the same….<\/p>\n\n\n\n
What’s going on here? I wondered…<\/p>\n\n\n\n
I must make a note here that the Signal setup program is using the Nullsoft installer to deliver the software to users. And in the reverse engineering world, once you recognize the installer type, the natural step in analysis is to decompile the script used by the installer. <\/p>\n\n\n\n
Using the older version of 7z (7z_1505) that extracts the [NSIS].nsi script file I got the following output listing all the embedded files inside the most recent Signal installer:<\/p>\n\n\n\n
$PLUGINSDIR\\app-64.7z\n$PLUGINSDIR\\app-arm64.7z\n$PLUGINSDIR\\nsExec.dll\n$PLUGINSDIR\\nsis7z.dll\n$PLUGINSDIR\\SpiderBanner.dll\n$PLUGINSDIR\\StdUtils.dll\n$PLUGINSDIR\\System.dll\n$PLUGINSDIR\\WinShell.dll\n$R0\\Uninstall Signal.exe\n$PLUGINSDIR\\installerHeaderico.ico\n[NSIS].nsi<\/pre>\n\n\n\n
Huh…<\/p>\n\n\n\n
As you can see, there are two embedded 7z files listed above:<\/p>\n\n\n\n