1. Installation and Steps to quickly analyze a sample
The setup instructions should be followed. These are reproduced here, but this will differ slightly once it is on GitHub, after it has been released publicly. Right now it is available via Google Drive for Black Hat reviewers.
At a high-level, what we are doing is installing a package locally. The steps below should be followed closely.
To run this, it must be on a Windows machine. All OSs are supported, but for ease of use to demo it, Windows is recommended (more detailed instructions are needed for other OSs).
Note: SHAREM will extract Windows DLLs, inflate them by a set amount as specified by PE file, and save them into a special directory, allowing these to be loaded into the emulation. For other OSs, these would need to be imported – but in an “inflated” state.
- Obtain the SHAREM code from the Google drive
- From the \sharem directory, run install.bat
- Next, an ssdeep wrapper for Windows must be installed. Go to https://github.com/MacDue/ssdeep-windows-32_64 and follow the instructions in the readme for ssdeep after downloading the code for this Windows version of ssdeep.
Note: this is the only Windows ssdeep -- other ways of installing ssdeep are for Linux -- and this step must be completed in order for the framework to work, as ssdeep is required, and this one dependency causes issues with the install script.
SHAREM will go and acquire DLLs from the Syswow64 directory. It will expand them slightly, each one according to what is in the PE file, so that they are similar to how they would be in memory. It will also map functions to addresses contained in those DLLs. This initial setup will be performed once, and it will take several minutes. If it hangs up after more than several minutes, hit enter. After it is done, this step need not be completed ever again. This step will run automatically if required – no special actions are required, other than to go into the emulation menu (l) and type z.
In order to set up the emulation, navigate inside the sharem_cli directory. 'Shellcode.bin' is any shellcode.
py main.py -r32 shellcode.bin
Alternatively, from the main directory, you can run it with
py sharemMain.py -r32 shellcode.bin
The initial set up should be ran by launching SHAREM. It will launch a process to begin setting up the emulation, and it will provide a message indicating this as well. Once complete, enter z (may need to restart the program). If it hangs up on setting up the emulation, this process may need to be repeated. Once completed, it will begin by saying Emulating x86_32 shellcode.
Ideally, this should be set up on a modern Windows 10 system with Python installed – older versions of Windows 7 potentially could be temperamental, although it does work on some we tested. A modern Windows 10 should present no problems.
To run the program, please provide a shellcode .bin or .txt (ASCII of shellcode binary) as input, using the -r switch
E.g.
py sharemMain.py -r32 shellcode.bin
Or from the sharem_cli directory:
py main.py -r32 shellcode.bin
The command in the bat file is as follows:
start python -m pip install -e ./sharem/
If you have multiple versions of python, you may need to adjust the version of Python. E.g. some may have python for 2.74 and py for newer versions. One scenario could be where someone has python for 2.74, and py for more modern Python. In that case, we would change the command in the .bat to the following:
start py -m pip install -e ./sharem/
If you want to ensure the SHAREM package is installed correctly, you may enter
py -m pip list
You should see SHAREM listed among the packages, and in the location column, there should be the file location where you installed it.
E.g. sharem 0.0.1 c:\sharem\github\sharem\sharem
This should be done automatically via the install.bat file. If it does not, you can try a variation on this command. In the root of the project (/sharem) in a terminal run the command:
python -m pip install -e .
We are available for help, although we are doubtful there are any in a Windows environment, as we have tested this on fresh installs of Windows.
In most cases, SHAREM should install fine without errors. Sometimes a user may accidentally interrupt the initial generation of the inflated DLLs -- this typically is not interrupted on its own. If this is the case, then some additional steps will be necessary to delete what was done and restart the generation of DLLs. This is described more fully below.
It can take several minutes for DLLs to be generated initially. What SHAREM is doing is it is putting each Windows DLL into memory and then inflating it a small amount, to mimic what is done when a DLL is loaded into memory. This is necessary for these to be usable for emulation. Secondly, it is generating a listing of all the APIs and their respective addresses from the DLLs. This is used so that if the shellcode tries to go to a certain place in memory, we can intercept it, and check to see what address corresponds to what API. It will generate a file in sharem/sharem/sharem/sharem/ called foundDLLAddresses32.json and foundDLLAddresses64.json. For Windows 7, it should be about 600KB in size for each; for Windows 10, it should be about 900KB. (SHAREM supports some DLLs not present on Windows 7 - thus, they cannot be harvested - hence the discrepancy in sizes.) If you are having problems and getting errors about addresses not being found - and you cannot get anything to emulate - you can check the size of these two .json files. If they are rather small, like 100KB, then the process was likely interrupted.
What do do if the ripping of the DLLs was interrupted? You can go and delete all the DLLs as well as the foundDLLAddresses file(s), and then try to run a shellcode. The DLLs are in sharem/sharem/sharem/sharem/DLLs/ and then either x86/ or x64/. Do not delete the actually sub directories x86 or x64 - delete the DLLs contained therein. It should restart the initial generation of the DLLs once again, whenever you next try to emulate a shellcode. Once the generation of the DLLs is complete, it should then attempt to emulate the shellcode in question.
Please note that there are separate inflated DLLs and JSONs for x64 and x86, so a similar process will be repeated when first trying to do a shellcode from a x64 or x86, if one has already been done.