search

Bw3ll / sharem

SHAREM is a shellcode analysis framework, capable of emulating more than 20,000 WinAPIs and virutally all Windows syscalls. It also contains its own custom disassembler, with many innovative features, such as being able to show the deobfuscated disassembly of an encoded shellcode, or integrating emulation data to enhance the disassembly.
GNU General Public License v3.0
336 stars 53 forks source link

Fix File Printing & JSON Problems #57

Closed vvelitkn closed 1 year ago

vvelitkn commented 1 year ago

In /sharem/sharem/sharemu.py, the files stored at outFile and stackFile were closed, resulting in the occurrence of errors as described below. As a temporary solution, these lines have been commented out.

 Sharem>Emulator> z

    [*] Emulating x86 shellcode
Emulation error:  I/O operation on closed file.
Last address: 0x12000000
Traceback (most recent call last):
  File "/home/vvelitkn/Desktop/sharem/sharem/sharem/sharem/sharemu.py", line 1153, in test_i386
    mu.emu_start(startLoc, (CODE_ADDR + em.entryOffset) + len(code))
  File "/usr/local/lib/python3.8/dist-packages/unicorn/unicorn.py", line 550, in emu_start
    raise self._hook_exception
  File "/usr/local/lib/python3.8/dist-packages/unicorn/unicorn.py", line 392, in wrapper
    return func(self, *args, **kwargs)
  File "/usr/local/lib/python3.8/dist-packages/unicorn/unicorn.py", line 663, in _hookcode_cb
    cb(self, address, size, data)
  File "/home/vvelitkn/Desktop/sharem/sharem/sharem/sharem/sharemu.py", line 576, in hook_code
    outFile.write(instructLine)
ValueError: I/O operation on closed file.

    [*] CPU counter: 1
    [*] Emulation complete

 Sharem>Emulator> z

    [*] Emulating x86 shellcode
Emulation error:  I/O operation on closed file.
Last address: 0x12000000
Traceback (most recent call last):
  File "/home/vvelitkn/Desktop/sharem/sharem/sharem/sharem/sharemu.py", line 1153, in test_i386
    mu.emu_start(startLoc, (CODE_ADDR + em.entryOffset) + len(code))
  File "/usr/local/lib/python3.8/dist-packages/unicorn/unicorn.py", line 550, in emu_start
    raise self._hook_exception
  File "/usr/local/lib/python3.8/dist-packages/unicorn/unicorn.py", line 392, in wrapper
    return func(self, *args, **kwargs)
  File "/usr/local/lib/python3.8/dist-packages/unicorn/unicorn.py", line 663, in _hookcode_cb
    cb(self, address, size, data)
  File "/home/vvelitkn/Desktop/sharem/sharem/sharem/sharem/sharemu.py", line 536, in hook_code
    stackFile.write(timelessStack )
ValueError: I/O operation on closed file.

    [*] CPU counter: 1
    [*] Emulation complete
vvelitkn commented 1 year ago

Solution for JSONDecodeError and fix JSON file The occurrence of errors is described below. sharem_json

Bw3ll commented 1 year ago

Hi, You are actually our first external contributor who is not part of the same group. Please bear with us/me, as our responses to pull requests may not be as polished and smooth as we may not be as experienced in talking to others through GitHub as part of the pull request process.

re: JSON error One issue here is that this is somehow triggered by going back and forth from 32 and 64 bit. I had it happen to me once during testing, but I thought I resolved it. This is not something that should normally happen - and ordinarily would not happen. If you remember the exact sequence of steps you did to cause that, then I can try to reproduce it. I am unclear on your solution (i see the code), since it is not trying to do the same thing here (essentially re-adding all the function name and address pairs). We do not want them to be in there twice - and unsure if being in it twice could cause issues.

Notice that the new content after the }{ with no comma is NTDLL? All those functions are suppose to be at the beginning, NTDLL. Wtsapi32.dll is supposed to be the current last one. I would say as a temporary solution, delete everything after the the wtsapi32.dll and the }{ with no comma.

WE do not want things to be in there twice / duplicates. It is not clear to me what your proposed change does - is it handling duplicates or just adding something there twice and fixing the }{ with by replacing it with },{. I think ideally a better solution is figured out what you are doing to trigger that and coming up with something to handle that. Though if yours can address duplicates and get rid of them, that could also possibly help for error situations we do not anticipate. But it is not clear to us from your other issue if you are getting any results from APIs being detected in shellcode samples. Getting results is a good indicator that it is "working" okay - if it is not working and you are not getting results, then we want to figure out why.

re: closed files and error messages SHAREM is really only set up to allow it to emulate something once per "session" without restarting it. The outFile and stackfile are not causing that. However, if it is not closed, and you are trying to view the emulation log, then you cannot see the emulationlog.txt until after SHAREM ends (and the files are closed that way). Therefore, we want to keep those closed. Sometime later in the future I probably will likely look into seeing if we can allow it to be run more than once per session. (SHAREM is pretty complex with many optional modes, so an answer to this may not be as straightforward without impacting other things - will take more time.) You should only ever see that error message if you are trying to run the emulation more than once in the same session - which unfortunately SHAREM is not setup to do.

json printing No comment yet - let me look into this. ARe you able to get any results from APIs being detected? I will post some shellcode samples for you on your other issue, so you can also use those to test.

vvelitkn commented 1 year ago

Thank you for getting back to me. I would like to clarify that the purpose of this pull request is not to make a direct contribution to the project. Instead, I have opened this pull request to bring an issue to your attention and share a simple solution that I have found.

Currently, I am in the process of redesigning the source code using SHAREM to customize it for my specific requirements. My aim is to make it more script-friendly by eliminating the need for a command-line interface and automating the process of generating responses and files.

Thank you for sharing the samples, I will try them out.

Bw3ll commented 1 year ago

Well, some of your contributions might be good to include. I was just seeking more info - particularly on the one where it tried to regenerate the JSON. IT somehow gets into a state where it thinks it needs to build some of the files - it gets those from parsing the inflated DLLs using Pefile library - but it should never get into that position in the first place. I encountered that once in development going back and forth form 32 and 64-bit in a way not intended and thought I fixed it for that situation to prevent that behavior. You may have found another way to cause that.

There is a way to run it without command line arguments. There is a config file called config.cfg in \sharem\sharem\sharem\sharem\config.cg. In that are options you can select. Under Sharem startup, you can put startup_enabled = True to make it just run automatically and "do everything" with the config options that have been selected - without the need to go into any kind of menu. With this mode, it should generate all applicable outputs. That might help. It is not the most user friendly to add things to the config file as there are a few places you have to make changes. By default Sharem always runs with the options from the config file, and you can save changes you made in the UI to the config (if so desired).

Let us know if you come up with anything cool. If you have problems or errors, feel free to let us know.