Cannot run OAES example

[KaneX]

Trying to run the OAES example on my macbookpro with Intel CPU, MacOS version is 14.4.1.

This is what I get:

Traceback (most recent call last):
  File "/Users/***/Program/attacks/rainbow/examples/OAES/OAES_x86.py", line 65, in <module>
    e, func = generate_targetf()
  File "/Users/***/Program/attacks/rainbow/examples/OAES/OAES_x86.py", line 13, in generate_targetf
    e.load("libnative-lib_x86.so")
  File "/Users/***/opt/miniconda3/envs/attack/lib/python3.9/site-packages/rainbow/rainbow.py", line 270, in load
    return load_selector(filename, self, *args, **kwargs)
  File "/Users/***/opt/miniconda3/envs/attack/lib/python3.9/site-packages/rainbow/loaders/__init__.py", line 35, in load_selector
    return loader(filename, rainbow_instance, *args, **kwargs)
  File "/Users/***/opt/miniconda3/envs/attack/lib/python3.9/site-packages/rainbow/loaders/cleloader.py", line 29, in cleloader
    ld = cle.Loader(path, except_missing_libs=True, ld_path=ld_path)
  File "/Users/***/opt/miniconda3/envs/attack/lib/python3.9/site-packages/cle/loader.py", line 188, in __init__
    self.initial_load_objects = self._internal_load(
  File "/Users/***/opt/miniconda3/envs/attack/lib/python3.9/site-packages/cle/loader.py", line 823, in _internal_load
    obj = self._load_object_isolated(spec)  # loading dependencies
  File "/Users/***/opt/miniconda3/envs/attack/lib/python3.9/site-packages/cle/loader.py", line 947, in _load_object_isolated
    binary = self._search_load_path(spec)  # this is allowed to cheat and do partial static loading
  File "/Users/***/opt/miniconda3/envs/attack/lib/python3.9/site-packages/cle/loader.py", line 1104, in _search_load_path
    raise CLEFileNotFoundError("Could not find file %s" % spec)
cle.errors.CLEFileNotFoundError: Could not find file liblog.so

[KaneX]

Looks like there is something wrong with the config of CLE, here is what I get when running the hacklu2009 example on my macos:

Traceback (most recent call last):
  File "/Users/***/Program/attacks/rainbow/examples/hacklu2009/go.py", line 13, in <module>
    e.load('crackme.exe')
  File "/Users/***/opt/miniconda3/envs/attack/lib/python3.9/site-packages/rainbow/rainbow.py", line 270, in load
    return load_selector(filename, self, *args, **kwargs)
  File "/Users/***/opt/miniconda3/envs/attack/lib/python3.9/site-packages/rainbow/loaders/__init__.py", line 35, in load_selector
    return loader(filename, rainbow_instance, *args, **kwargs)
  File "/Users/***/opt/miniconda3/envs/attack/lib/python3.9/site-packages/rainbow/loaders/cleloader.py", line 29, in cleloader
    ld = cle.Loader(path, except_missing_libs=True, ld_path=ld_path)
  File "/Users/***/opt/miniconda3/envs/attack/lib/python3.9/site-packages/cle/loader.py", line 188, in __init__
    self.initial_load_objects = self._internal_load(
  File "/Users/***/opt/miniconda3/envs/attack/lib/python3.9/site-packages/cle/loader.py", line 823, in _internal_load
    obj = self._load_object_isolated(spec)  # loading dependencies
  File "/Users/***/opt/miniconda3/envs/attack/lib/python3.9/site-packages/cle/loader.py", line 947, in _load_object_isolated
    binary = self._search_load_path(spec)  # this is allowed to cheat and do partial static loading
  File "/Users/***/opt/miniconda3/envs/attack/lib/python3.9/site-packages/cle/loader.py", line 1104, in _search_load_path
    raise CLEFileNotFoundError("Could not find file %s" % spec)
cle.errors.CLEFileNotFoundError: Could not find file kernel32.dll

[yhql]

Thanks for reporting this. Seems we're overzealous with CLE loading the whole binary + shared libraries when none of those are actually required to run the example

[yhql]

@erdnaxe I think in this line ld = cle.Loader(path, except_missing_libs=True, ld_path=ld_path)
except_missing_libs should be False (do not throw an exception if a lib is missing) instead. What do you think?

The OAES example runs again with this modification

[erdnaxe]

@erdnaxe I think in this line ld = cle.Loader(path, except_missing_libs=True, ld_path=ld_path) except_missing_libs should be False (do not throw an exception if a lib is missing) instead. What do you think?

The idea behind except_missing_libs=True:

• if an user is loading a dynamic executable, they might want to map as much as libraries they can in memory. CLE raises an exception to remind the user than they might need to copy the ".so" in the right place.
• if an user is loading a static executable, then there are no missing libs.

In a perfect world, we should just print a warning that there are missing libs.
In the mean time, I am ok with except_missing_libs=False, or putting an extra optional named argument on load() to disable it.