7. Displaying and Reporting Results
Once items have been discovered by SHAREM, a summary of everything found can be generated using the Print Menu, accessible by typing p from the main menu. Here, each category of item can be toggled by typing g, then typing codes corresponding to each selection:
If the j option is toggled on, SHAREM will generate useful JSON files that can be easily integrated with other tools. Printing style of emulation and artifacts can be altered as well via the e and m options. If output is excessively long, printing to screen can be disabled with p and output can be parsed via the files created upon running the print feature with z.
The s option corresponds to the “Windows Syscall” category of shellcode instructions. The option leads to the menu seen below, where the user can select which syscalls ID (System Service Number – SSN) sets are used. Since SSNs change between Windows OSs and release builds, the user should select those relevant to the environment(s) where the sample might typically be found.
Once the desired options are selected, the print feature can be executed by typing z. Reports of information such as annotated disassembly, shellcode instructions, JSON files, and more are saved to the …/sharem/sharem/sharem/sharem/logs folder. If printing to screen is enabled, much of this information can be seen in the console as well.
This will utilize the well-known SSN .csv files available from https://github.com/j00ru/windows-syscalls and also displayed in a table at https://j00ru.vexillium.org/syscalls/nt/64/ SSNs often change for each release, so what is one syscall in one release, may be an entirely different syscall in another!
Note that it is possible to select as many or a few syscall selections if one likes, or to just do only latest releases, only latest Windows10, and only latest Windows 10 and Windows 7, etc. These can also be set in the config file.
Additionally, it is important to note that once the syscalls have been found via this pseudo-emulation method, then you can switch back and forth or print out multiples of each. This submenu and pseudo-emulation of syscalls method – while extremely effective – is different from the syscall detection method utilized in the emulation. (That one will obtain all parameters, whereas this pseudo-emulation method – which we created earlier – does not.)
Shellcode files can come in many forms, whether as raw binary data or different types of ASCII text representing the shellcode. The o option allows the user to output files containing several different forms of the shellcode for use in different situations. The option produces a .bin file and a .txt file, both found within the logs folder. The .bin file contains the raw binary data of the shellcode, while the .txt file contains several ASCII representations of the data:
- Raw Hex
- String Literal
- Array Literal
One situation in which this selection is especially useful is when working with obfuscated shellcode. First, SHAREM can be used to decode the shellcode via the emulation feature or brute force deobfuscation. Afterwards, with the decoded shellcode selected (U at the main menu toggles between encoded and decoded), use the o option to output files containing the decoded shellcode which can be used for further analysis.
SHAREM will also by default create a .bin of every submitted file in a folder alongside the text format and JSON reports. The ASCII representation will appear below the disassembly. IF the file has been deobfuscated through emulation, it will also additionally spawn a .bin of the deobfuscated shellcode, with the decoder stub (what does the decoding) removed, leaving just the recovered form of the shellcode. Finally, SHAREM will generate a C file by default as well that can be compiled and used as a “harness,” if the user wishes to execute it and debug it in WinDbg. That will be in the saved directory for outputs, found off of logs and then the name of the executable. This is just a convenience to save the user time in having to create that themselves.