danielplohmann / smda Goto Github PK

SMDA is a minimalist recursive disassembler library that is optimized for accurate Control Flow Graph (CFG) recovery from memory dumps.

License: BSD 2-Clause "Simplified" License

Makefile 0.13% Python 99.87%

disassembler code-analysis control-flow-graph control-flow-analysis memory-dump x86 x64

smda's Introduction

Hi! I'm Daniel and I do research around (malware) reverse engineering and analysis automation.

The root and motivation for most of my projects is Malpedia, a a resource for rapid identification and actionable context when investigating malware. It was launched in December 2017 by Steffen Enders and me and is maintained by us ever since.

SMDA is a minimalistic recursive disassembler, which internally uses capstone. It was created to study and improve heuristics for function entry point detection, especially in memory-mapped buffers and shellcode.

MCRIT is the MinHash-based Code Relationship & Investigation Toolkit, a binary code similarity analysis framework. It uses SMDA as its built-in disassembler, and picblocks for the hashing of basic blocks. For easy deployment, it comes as docker-mcrit, including its web UI mcritweb.

To filter out library code during analysis, we created mcrit-data, a collection of reference library code for various compilers (MSVC, MinGW, Go, Nim, ...) and commonly found 3rd party libraries. For this, the support tool lib2smda was created, which can be used to convert LIB/OBJ files into SMDA reports, which can then be imported into MCRIT. Empty MSVC was a pre-cursor to this, which is a collection of "empty main()" Visual Studio projects, compiled with various options - which can also serve well as ground truth for commonly found compiler/library code.

During my research on dynamic Windows API imports in malware, I wrote ApiScout. It's a method/tool to reliably recover such dynamic imports and make them usable in other tools. We also showed that the entirety of Windows API imports used by a malware family can be used effectively for its identification.

In 2012, I created IDAscope, an IDA Pro plugin that provides various convenience functionality during reversing. It was one of the first plugins which extensive rich use of PySide/PyQt in IDA and served as a template for many others.

Over the years, I occassionally wrote some blog posts, which cover many of the above projects or aspects of them in detail.

If you want to support my work, I would be happy if you'd buy me a coffee.

smda's People

Contributors

Stargazers

Watchers

smda's Issues

Speed up analysis of bigger buffers

It's a known issue that disassembly of dumps containing a couple thousand functions is currently very slow. This is likely to some suboptimal choices of data structures and will be investigated asap.

Use OEP info to populate FEP candidate list

No idea why this is not done yet, if an explicit oep param is added to disassembleBuffer, then of course it should be used...

Incorporate demangling for Rust symbols

Can possibly reuse code from here:

https://github.com/teambi0s/rust_demangler/tree/main/demangler

Windows: struct.error: argument out of range

I'm not sure I was able to locate the right error source here, but running this on Windows we get two exceptions in capa, see https://github.com/fireeye/capa/pull/470/checks?check_run_id=2277082296#step:7:28

================================== FAILURES ===================================
_ test_smda_features[al-khaser x64-function=0x14004B4F0-api(__vcrt_GetModuleHandle)-True] _

ins = <smda.common.SmdaInstruction.SmdaInstruction object at 0x0000025A8DC23550>

    @staticmethod
    def escapeBinaryPtrRef(ins):
        escaped_sequence = ins.bytes
        addr_match = re.search(r"\[(rip (\+|\-) )?(?P<dword_offset>0x[a-fA-F0-9]+)\]", ins.operands)
        if addr_match:
            offset = int(addr_match.group("dword_offset"), 16)
            if "rip -" in ins.operands:
                offset = 0x100000000 - offset
            #TODO we need to check if this is actually a 64bit absolute offset (e.g. used by movabs)
            try:
>               packed_hex = str(codecs.encode(struct.pack("I", offset), 'hex').decode('ascii'))
E               struct.error: argument out of range

c:\hostedtoolcache\windows\python\3.9.2\x64\lib\site-packages\smda\intel\IntelInstructionEscaper.py:334: error

During handling of the above exception, another exception occurred:

self = <smda.Disassembler.Disassembler object at 0x0000025A97BF9310>
file_path = 'D:\\a\\capa\\capa\\tests\\data\\al-khaser_x64.exe_', pdb_path = ''

    def disassembleFile(self, file_path, pdb_path=""):
        loader = FileLoader(file_path, map_file=True)
        file_content = loader.getData()
        binary_info = BinaryInfo(file_content)
        binary_info.raw_data = loader.getRawData()
        binary_info.file_path = file_path
        binary_info.base_addr = loader.getBaseAddress()
        binary_info.bitness = loader.getBitness()
        binary_info.code_areas = loader.getCodeAreas()
        start = datetime.datetime.utcnow()
        try:
            self.disassembler.addPdbFile(binary_info, pdb_path)
>           smda_report = self._disassemble(binary_info, timeout=self.config.TIMEOUT)

c:\hostedtoolcache\windows\python\3.9.2\x64\lib\site-packages\smda\Disassembler.py:52: 
...

ERROR    smda.Disassembler:Disassembler.py:56 An error occurred while disassembling file.
_ test_smda_features[a1982...-function=0x4014D0-characteristic(cross section flow)-True] _

ins = <smda.common.SmdaInstruction.SmdaInstruction object at 0x0000025A9AA2A9A0>

    @staticmethod
    def escapeBinaryPtrRef(ins):
        escaped_sequence = ins.bytes
        addr_match = re.search(r"\[(rip (\+|\-) )?(?P<dword_offset>0x[a-fA-F0-9]+)\]", ins.operands)
        if addr_match:
            offset = int(addr_match.group("dword_offset"), 16)
            if "rip -" in ins.operands:
                offset = 0x100000000 - offset
            #TODO we need to check if this is actually a 64bit absolute offset (e.g. used by movabs)
            try:
>               packed_hex = str(codecs.encode(struct.pack("I", offset), 'hex').decode('ascii'))
E               struct.error: argument out of range

c:\hostedtoolcache\windows\python\3.9.2\x64\lib\site-packages\smda\intel\IntelInstructionEscaper.py:334: error

During handling of the above exception, another exception occurred:

self = <smda.Disassembler.Disassembler object at 0x0000025A9B4FFAC0>
file_path = 'D:\\a\\capa\\capa\\tests\\data\\a198216798ca38f280dc413f8c57f2c2.exe_'
pdb_path = ''

    def disassembleFile(self, file_path, pdb_path=""):
        loader = FileLoader(file_path, map_file=True)
        file_content = loader.getData()
        binary_info = BinaryInfo(file_content)
        binary_info.raw_data = loader.getRawData()
        binary_info.file_path = file_path
        binary_info.base_addr = loader.getBaseAddress()
        binary_info.bitness = loader.getBitness()
        binary_info.code_areas = loader.getCodeAreas()
        start = datetime.datetime.utcnow()
        try:
            self.disassembler.addPdbFile(binary_info, pdb_path)
>           smda_report = self._disassemble(binary_info, timeout=self.config.TIMEOUT)

c:\hostedtoolcache\windows\python\3.9.2\x64\lib\site-packages\smda\Disassembler.py:52: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = <smda.Disassembler.Disassembler object at 0x0000025A9B4FFAC0>
binary_info = <smda.common.BinaryInfo.BinaryInfo object at 0x0000025A9B4FFE20>
timeout = 300

    def _disassemble(self, binary_info, timeout=0):
        self._start_time = datetime.datetime.utcnow()
        self._timeout = timeout
        self.disassembly = self.disassembler.analyzeBuffer(binary_info, self._callbackAnalysisTimeout)
>       return SmdaReport(self.disassembly, config=self.config)

c:\hostedtoolcache\windows\python\3.9.2\x64\lib\site-packages\smda\Disassembler.py:101: 
...

Issue with Push+Call String Obfuscation

Hello,

It appears that SMDA is disassembling instructions that are strings. The malicious sample 57E441BBB7345E63F2EE9547A4C108C1B70448C107E17CBBC92739A56F77F12E uses a call to mimic a stack push of a string.

.flat:0040100F FF 15 28 31 40 00                       call    ds:LoadLibraryA
.flat:00401015 83 F8 00                                cmp     eax, 0
.flat:00401018 74 32                                   jz      short loc_40104C
.flat:0040101A E8 13 00 00 00                          call    loc_401032
.flat:0040101A                               ; ---------------------------------------------------------------------------
.flat:0040101F 52 74 6C 41 64 6A 75 73 74 50+aRtladjustprivi db 'RtlAdjustPrivilege',0
.flat:00401032                               ; ---------------------------------------------------------------------------
.flat:00401032
.flat:00401032                               loc_401032:                             ; CODE XREF: .flat:0040101A↑p
.flat:00401032 50                                      push    eax

Output from the smda json. You can see at offset 543 that smda is disassembling the string RtlAdjustPrivilege.

    ],
    "538": [
     [
      538,
      "e813000000",
      "call",
      "0x232"
     ],
     [
      543,
      "52",
      "push",
      "edx"
     ],
     [
      544,
      "746c",
      "je",
      "0x28e"
     ]
    ],

This issue is usually caused when a disassemblers assumes that the offset following a call is a return address.

Integrate with IDA

IDA won't recognize any code/functions when loaded as binary buffer for x64.
Therefore, have SMDA run over the buffer loaded and IDA and provide CFG information to be then used by IDA.
This should be also usable for x86 with incomplete function discovery.

Reuse capa code for string extraction

When we integrated SMDA into capa, we already basically had string extraction done.
We can adapt the code and port it into SMDA.

New parameters for disassembleBuffer(): OEP, and code_start/code_end

When disassembling shellcode, it might be useful to be able to manually provide information about an Original Entry Point (OEP) and a range of bytes to which disassembly should be limited to avoid over-aggressive processing.

behaviour differs in disassembleFile / disassembleBuffer

It looks like disassembling a file from disk yields different results than reading from buffer.
Do you have encountered this before?

Logging is broken

Currently all files are using

LOGGER = logging.getLogger(__name__)

which creates a new logger for each of the files. Moreover, config:

smda/smda/SmdaConfig.py

Lines 36 to 38 in 97a5a6d

 def __init__(self, log_level=logging.INFO): 

 if len(logging._handlerList) == 0: 

 logging.basicConfig(level=log_level, format=self.LOG_FORMAT)

doesn't actually assign self.LOG_LEVEL to variable passed
uses logging.basicConfig which overwrites root logger config (that means, any application using smda)

The solution I propse is to replace

logging.getLogger(__name__)

with

logging.getLogger("smda")

which would make smda use only 1 logger in all of the files and remove call to logging.basicConfig in SmdaConfig.

SMDA incorrectly maps sections/segments from ELF files

The variable min_raw_segment_offset used

smda/smda/utility/ElfFileLoader.py

Line 61 in bb9cdab

mapped_binary[0:min_raw_section_offset] = binary[0:min_raw_section_offset]

and

smda/smda/utility/ElfFileLoader.py

Line 77 in bb9cdab

mapped_binary[0:min_raw_segment_offset] = binary[0:min_raw_segment_offset]

in the ElfFileLoader are used incorrectly, leading to sections/segments being truncated.

This variable contains a virtual address; however, it is used as a raw file offset (the raw file offset of the first section/segment). When the virtual address is something like 0x401000, then the assignment tries to copy 0x401000 from the source binary, ends up with much less data (the size of the file amount of data), and this truncates the mapped data to len(size of file). Subsequent assignments to the mapped data somehow don't throw exceptions despite failing to write beyond the end of the truncated mapping.

A reasonable fix is to operate on physical/raw file offsets rather than virtual addresses.

PE loader crashes with LIEF .0.13.2

LIEF 0.13.2 has restructured fields internally, which now breaks with how they are currently accessed in SMDA.
Specifically, this line in the PeLoader now causes errors.

Output Consistency

Using methods from DisassemblyResult gives less information than iterating over the output JSON files.

SmdaBlock should provide information about predecessor and successor blocks

simple QoL addition, see title.

Crash when handling InRefs in SMDAReport

In a edge case the disassembler can run into a situation where an incoming Xref is not coming from an instruction offset. This will cause a crash at:

smda/smda/common/SmdaReport.py

Line 160 in b300eef

 function.code_inrefs.append(CodeXref(offset2ins[inref], offset2ins[function.offset])) 

The attached file is a example of this. (it is malware, password is infected)
check.zip

I added a quick check that will work for our usecase but I'm not sure if it will break anything.

for inref in function.inrefs:
    if inref in offset2ins:
        function.code_inrefs.append(CodeXref(offset2ins[inref], offset2ins[function.offset]))

Unhandled mnemonics related to XMM

I initiated a recalculate minhashes in mcrit, and while it was running, I saw numerous repeats of these errors (not in this exact order):

ERROR:smda.intel.IntelInstructionEscaper:********************************************** Unhandled mnemonic: cmpeqpd
ERROR:smda.intel.IntelInstructionEscaper:********************************************** Unhandled mnemonic: cmpleps
ERROR:smda.intel.IntelInstructionEscaper:********************************************** Unhandled mnemonic: cmpltss
ERROR:smda.intel.IntelInstructionEscaper:********************************************** Unhandled mnemonic: cmpnleps
ERROR:smda.intel.IntelInstructionEscaper:********************************************** Unhandled mnemonic: cmpnles
ERROR:smda.intel.IntelInstructionEscaper:********************************************** Unhandled mnemonic: cmpnltpd
ERROR:smda.intel.IntelInstructionEscaper:********************************************** Unhandled mnemonic: cmpnltps
ERROR:smda.intel.IntelInstructionEscaper:********************************************** Unhandled mnemonic: cmpunordpd
ERROR:smda.intel.IntelInstructionEscaper:********************************************** Unhandled mnemonic: cmpunordps
ERROR:smda.intel.IntelInstructionEscaper:********************************************** Unhandled mnemonic: vcmpeqpd
ERROR:smda.intel.IntelInstructionEscaper:********************************************** Unhandled mnemonic: vcmpeqps
ERROR:smda.intel.IntelInstructionEscaper:********************************************** Unhandled mnemonic: vcmpge_oqpd
ERROR:smda.intel.IntelInstructionEscaper:********************************************** Unhandled mnemonic: vcmpge_oqps
ERROR:smda.intel.IntelInstructionEscaper:********************************************** Unhandled mnemonic: vcmpgt_oqpd
ERROR:smda.intel.IntelInstructionEscaper:********************************************** Unhandled mnemonic: vcmpgt_oqps
ERROR:smda.intel.IntelInstructionEscaper:********************************************** Unhandled mnemonic: vcmple_oqpd
ERROR:smda.intel.IntelInstructionEscaper:********************************************** Unhandled mnemonic: vcmple_oqps
ERROR:smda.intel.IntelInstructionEscaper:********************************************** Unhandled mnemonic: vcmplt_oqpd
ERROR:smda.intel.IntelInstructionEscaper:********************************************** Unhandled mnemonic: vcmplt_oqps
ERROR:smda.intel.IntelInstructionEscaper:********************************************** Unhandled mnemonic: vcmpnle_uqpd
ERROR:smda.intel.IntelInstructionEscaper:********************************************** Unhandled mnemonic: vcmpnle_uqps
ERROR:smda.intel.IntelInstructionEscaper:********************************************** Unhandled mnemonic: vcmpnlt_uqpd
ERROR:smda.intel.IntelInstructionEscaper:********************************************** Unhandled mnemonic: vcmpnlt_uqps

According to the Intel documentation, they are Pseudo-ops for the opcodes CMPPD, CMPPS, CMPSD, and CMPSS. There may be more in the Intel documentation than those listed above.

Do they just need to be added to the _xmm_group in the smda/intel/INtelInstructionEscaper.py file? If so, then I am happy to make the edits and submit a PR if that would help.

Investigate breaking functions in Go

In binary hello.exe, function runtime.cgoIsGoPointer is suddenly ended when encountering a multibyte NOP (0F 1F 00 nop dword ptr [rax]) and function analysis apparently ends. This leads to another gap function being found starting at 0x4039a0 that should instead be part of the previous function.

Unhandled AssertionError Processing ELF File

Spotted this error while processing an ELF file with MCRIT in dir mode and wanted to report it. File hash d2f94e178c254669fb9656d5513356d2

ERROR: SMDA caused an exception while processing this file: Samples/d2f94e178c254669fb9656d5513356d2
Traceback (most recent call last):
  File "/usr/home/schrodinger/.local/src/mcrit/mcrit/client/McritConsole.py", line 109, in getSmdaReportFromFilepath
    smda_report = disassembler.disassembleFile(filepath)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/schrodinger/.venv/mcrit/lib/python3.11/site-packages/smda/Disassembler.py", line 42, in disassembleFile
    loader = FileLoader(file_path, map_file=True)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/schrodinger/.venv/mcrit/lib/python3.11/site-packages/smda/utility/FileLoader.py", line 22, in __init__
    self._loadFile()
  File "/home/schrodinger/.venv/mcrit/lib/python3.11/site-packages/smda/utility/FileLoader.py", line 36, in _loadFile
    self._data = loader.mapBinary(self._raw_data)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/schrodinger/.venv/mcrit/lib/python3.11/site-packages/smda/utility/ElfFileLoader.py", line 113, in mapBinary
    assert len(segment.content) == segment.physical_size
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError

Broken pypi build

Sadly package on pypi does not include dependencies, which means performing

python -m venv .venv
source .venv/bin/activate
pip install smda
python3 -c "from smda.Disassembler import Disassembler"

will fail, as capstone dependency is missing.

SMDA does not recognize imported APIs from ELF files

As triaged in mandiant/capa#725, SMDA doesn't parse imports from ELF files into a representation used for APIs.

I'd propose implementing an ElfApiResolver that uses LIEF to parse the ELF imports and responds to getApi.

Does it handle indirect jumps?

I am building a Value Set Analysis on top of this, but first question is does it handle indirect jumps, if so, how? Thanks!

when parsing PE/ELF headers, feed OEP into function candidate list

Are entrypoint(s) and calls_from exposed?

Are the below features exposed and if so, how can I access them?
I'd like to update the SMDA capa backend with this data.

entry points, e.g. AddressOfEntryPoint and exported functions
optionally calls/xrefs from a function (on a higher level, otherwise I can reuse some existing code)

Thanks!

IntelInstructionEscaper escapeBinary check logic bug

In the IntelInstructionEscaper on line 272 there is a flaw in the logic.

if lower_addr is not None and upper_addr is not None and ins.operands.startswith("0x") or ", 0x" in ins.operands:

This will sometimes crash if ins.operands.startswith("0x") or ", 0x" in ins.operands is true.

I think the intended logic here should be:

if lower_addr is not None and upper_addr is not None and (ins.operands.startswith("0x") or ", 0x" in ins.operands):

Support more architectures

The same method for CFG recovery should be applicable to other popular architectures such as ARM and MIPS(el).
Therefore, refactor and expand the disassembler part to be mostly architecture-agnostic.

Unhandled mnemonics

While bulk processing some files into MCRIT I witnessed some errors related to smda and unhandled mnemonics.

ERROR:smda.intel.IntelInstructionEscaper:********************************************** Unhandled mnemonic: endbr64
ERROR:smda.intel.IntelInstructionEscaper:********************************************** Unhandled mnemonic: vpsllw
ERROR:smda.intel.IntelInstructionEscaper:********************************************** Unhandled mnemonic: vcvtss2sd

Unfortunately I don't have hashes available as it was a bulk job of a large directory of samples. At least endbr64 is a common instruction in ELF files compiled with GCC.

escaping instructions replaces menmonic bytes

In this case only the [ptr] is replaced.
IntelInstructionEscaper.escapeBinaryPtrRef: 2 occurrences for ac974a00 in c705ac974a00ac974a00 (mov dword ptr [0x4a97ac], 0x4a97ac), escaping only the first one

Here might be a problem:
IntelInstructionEscaper.escapeBinaryPtrRef: 2 occurrences for 05050505 in 010505050505 (add dword ptr [0x5050505], eax), escaping only the first one

IntelInstructionEscaper.escapeBinaryPtrRef: 2 occurrences for 05050505 in 020505050505 (add al, byte ptr [0x5050505]), escaping only the first one

IntelInstructionEscaper.escapeBinaryPtrRef: 2 occurrences for 05050505 in 030505050505 (add eax, dword ptr [0x5050505]), escaping only the first one

IntelInstructionEscaper.escapeBinaryPtrRef: 2 occurrences for 15151515 in 011515151515 (add dword ptr [0x15151515], edx), escaping only the first one

IntelInstructionEscaper.escapeBinaryPtrRef: 2 occurrences for 15151515 in 0f101515151515 (movups xmm2, xmmword ptr [0x15151515]), escaping only the first one

Exception when parsing Delphi structs

When trying to parse Delphi structs, processing may fail due to exceptions involving negative offsets

Example file: 62f2adbc73cbdde282ae3749aa63c2bc9c5ded8888f23160801db2db851cde8f
Trace:

  File "smda/Disassembler.py", line 57, in disassembleFile
    smda_report = self._disassemble(binary_info, timeout=self.config.TIMEOUT)
  File "smda/Disassembler.py", line 109, in _disassemble
    self.disassembly = self.disassembler.analyzeBuffer(binary_info, self._callbackAnalysisTimeout)
  File "smda/intel/IntelDisassembler.py", line 443, in analyzeBuffer
    self.fc_manager.init(self.disassembly)
  File "smda/intel/FunctionCandidateManager.py", line 46, in init
    self.disassembly.language = self.lang_analyzer.identify()
  File "smda/intel/LanguageAnalyzer.py", line 222, in identify
    t_objects = self.getDelphiObjects()
  File "smda/intel/LanguageAnalyzer.py", line 164, in getDelphiObjects
    data.seek(method_table - image_base)
ValueError: negative seek value -4194260

time.clock() is deprecated

Is it possible to speed up the recognition function

43.669s -> (architecture: intel.32bit, base_addr: 0x00400000): 9448 functions

Bug: dereferencing a buffer that may be too small

Hey!

I've found a few examples where SMDA analysis fails, both for the same reason. Looking into the issue, it seems to be in dereferenceQword method inside DisassemblyResult.py. It seems like, in some cases, the rel_start_addr may be too close to the end of the binary buffer. Toy example: binary is 100 bytes, rel_start_addr is index 94 in the binary buffer, and rel_end_addr in this case is 102. In this case binary[rel_start_addr:rel_end_addr] will just return the last 6 bytes of that binary, resulting in an error since struct.unpack("Q", ...) expects it to be 8 bytes.

List of affected files I've found:

0deaaed7b6b6bfb3d96b1354377b9dbc01c44f6a09e72d1620a38296e61adb48
136960b3e46c46c5057d4d222190c2bad2e490f6b5fe0c62765a3a7644cab276
395f83caedfdf3b3403bbaa950c08515919ab3799cef9a6c72f19e4462a216bf

Traceback:

An error occurred while disassembling file.
 0.085s -> Traceback (most recent call last):
  File "/usr/local/lib/python3.8/dist-packages/smda/Disassembler.py", line 57, in disassembleFile
    smda_report = self._disassemble(binary_info, timeout=self.config.TIMEOUT)
  File "/usr/local/lib/python3.8/dist-packages/smda/Disassembler.py", line 109, in _disassemble
    self.disassembly = self.disassembler.analyzeBuffer(binary_info, self._callbackAnalysisTimeout)
  File "/usr/local/lib/python3.8/dist-packages/smda/intel/IntelDisassembler.py", line 450, in analyzeBuffer
    state = self.analyzeFunction(candidate.addr)
  File "/usr/local/lib/python3.8/dist-packages/smda/intel/IntelDisassembler.py", line 331, in analyzeFunction
    self._analyzeCallInstruction(i, state)
  File "/usr/local/lib/python3.8/dist-packages/smda/intel/IntelDisassembler.py", line 168, in _analyzeCallInstruction
    dereferenced = self.disassembly.dereferenceQword(call_destination)
  File "/usr/local/lib/python3.8/dist-packages/smda/DisassemblyResult.py", line 154, in dereferenceQword
    return struct.unpack("Q", extracted_qword)[0]
struct.error: unpack requires a buffer of 8 bytes

Not sure if it has any connection to the issue but both files seem to be dotnet drivers, so I tried some other similar files and they seemed to be ok. Not sure if this file type has anything to do with this or they're both that just by chance.
In any case, maybe some guard checks regarding size should be implemented? This seems to be a potential issue also in similar methods like dereferenceDword so it may be good to look at them too.

OverflowError: cannot fit 'int' into an index-sized integer

Spotted this error while submitting files with MCRIT in dir mode and wanted to report it. File hash f3af394d9c3f68dff50b467340ca59a11a14a3d56361e6cffd1cf2312a7028ad

0.001s -> (architecture: intel.32bit, base_addr: 0x00000000): 0 functions
ERROR: SMDA caused an exception while processing this file: Samples/f3af394d9c3f68dff50b467340ca59a11a14a3d56361e6cffd1cf2312a7028ad
Traceback (most recent call last):
  File "/usr/home/schrodinger/.local/src/mcrit/mcrit/client/McritConsole.py", line 109, in getSmdaReportFromFilepath
    smda_report = disassembler.disassembleFile(filepath)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/schrodinger/.venv/mcrit/lib/python3.11/site-packages/smda/Disassembler.py", line 42, in disassembleFile
    loader = FileLoader(file_path, map_file=True)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/schrodinger/.venv/mcrit/lib/python3.11/site-packages/smda/utility/FileLoader.py", line 22, in __init__
    self._loadFile()
  File "/home/schrodinger/.venv/mcrit/lib/python3.11/site-packages/smda/utility/FileLoader.py", line 36, in _loadFile
    self._data = loader.mapBinary(self._raw_data)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/schrodinger/.venv/mcrit/lib/python3.11/site-packages/smda/utility/ElfFileLoader.py", line 97, in mapBinary
    mapped_binary = bytearray(align(virtual_size, 0x1000))
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
OverflowError: cannot fit 'int' into an index-sized integer

Investigate gap function analysis

when analyzing Go binary hello.exe, a gap function consisting of just a single int3 is found at 0x4032f0 - why is this identified as a gap function and not the surrounding int3s etc.

Double check calculation of PIC hashes for functions

Looking at the example provided in the IDA blog post for Diaphora, the two DLLs are almost identical, which should lead to many overlapping PIC hashes.
Given binaries:

408cb1604d003f38715833a48485b6a4e620edf163fb59aef792595866e4796b
c115d15807b96dcb9871ebc69618ef77473f1451c427e7349f9aa3c72891ddc2
this is however not the case, e.g. function 0x633b3b81 (both binaries, same offset) appears identical in both binaries, yet produces two distinct PIC hashes?
0x304cda7a0ed10b98
0xaa2ceb7c973bc0c5

Line 13 in 64ca170

requirements.append("lief==0.11")

Recent update: function detection regression?

One of the recent updates resulted in a regression for capa (function not found?), see mandiant/capa#369.

	def __init__(self, log_level=logging.INFO):
	if len(logging._handlerList) == 0:
	logging.basicConfig(level=log_level, format=self.LOG_FORMAT)

danielplohmann / smda Goto Github PK

smda's Introduction

smda's People

Contributors

Stargazers

Watchers

Forkers

smda's Issues

Recommend Projects

Recommend Topics

Recommend Org