I see these graph in your paper. Can I generate these graph by this repository's code or other way？
Look forward to your reply.

Hello, I have this example contract which has an unbounded mass operation vulnerability.

pragma solidity >=0.4.22 <0.6.0;
contract NaiveBank {
  struct Account {
    address addr;
    uint balance;
  }

  Account[] accounts;

  function applyInterest() public returns (uint) {
    for (uint i = 0; i < accounts.length; i++) {
      // apply 5 percent interest
      accounts[i].balance = accounts [i].balance * 105 / 100;
    }
    return accounts.length;
  }
  
  function createAccount() public {
    accounts.push(Account(msg.sender, 0));
  }
}

When I try to run ./tools/analyser/analyse.rb tools/bulk_analyser/spec.dl vulnerability.hex, the script does not return that the contract is vulnerable to an unbounded mass operation vulnerability.

What am I doing wrong?

Thanks in advance.

Fail to run MadMax on Mac OS X with the following errors:

Traceback (most recent call last):
File "", line 1, in
File "/usr/local/Cellar/[email protected]/3.9.12/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/spawn.py", line 116, in spawn_main
exitcode = _main(fd, parent_sentinel)
File "/usr/local/Cellar/[email protected]/3.9.12/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/spawn.py", line 125, in _main
prepare(preparation_data)
File "/usr/local/Cellar/[email protected]/3.9.12/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/spawn.py", line 236, in prepare
_fixup_main_from_path(data['init_main_from_path'])
File "/usr/local/Cellar/[email protected]/3.9.12/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/spawn.py", line 287, in _fixup_main_from_path
main_content = runpy.run_path(main_path,
File "/usr/local/Cellar/[email protected]/3.9.12/Frameworks/Python.framework/Versions/3.9/lib/python3.9/runpy.py", line 268, in run_path
return _run_module_code(code, init_globals, run_name,
File "/usr/local/Cellar/[email protected]/3.9.12/Frameworks/Python.framework/Versions/3.9/lib/python3.9/runpy.py", line 97, in _run_module_code
_run_code(code, mod_globals, init_globals,
File "/usr/local/Cellar/[email protected]/3.9.12/Frameworks/Python.framework/Versions/3.9/lib/python3.9/runpy.py", line 87, in _run_code
exec(code, run_globals)
File "/Users/luliu/MadMax/gigahorse-toolchain/gigahorse.py", line 559, in
proc.start()
File "/usr/local/Cellar/[email protected]/3.9.12/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/process.py", line 121, in start
self._popen = self._Popen(self)
File "/usr/local/Cellar/[email protected]/3.9.12/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/context.py", line 224, in _Popen
return _default_context.get_context().Process._Popen(process_obj)
File "/usr/local/Cellar/[email protected]/3.9.12/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/context.py", line 284, in _Popen
return Popen(process_obj)
File "/usr/local/Cellar/[email protected]/3.9.12/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/popen_spawn_posix.py", line 32, in init
super().init(process_obj)
File "/usr/local/Cellar/[email protected]/3.9.12/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/popen_fork.py", line 19, in init
self._launch(process_obj)
File "/usr/local/Cellar/[email protected]/3.9.12/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/popen_spawn_posix.py", line 42, in _launch
prep_data = spawn.get_preparation_data(process_obj._name)
File "/usr/local/Cellar/[email protected]/3.9.12/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/spawn.py", line 154, in get_preparation_data
_check_not_importing_main()
File "/usr/local/Cellar/[email protected]/3.9.12/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/spawn.py", line 134, in _check_not_importing_main
raise RuntimeError('''
RuntimeError:
An attempt has been made to start a new process before the
current process has finished its bootstrapping phase.

    This probably means that you are not using fork to start your
    child processes and you have forgotten to use the proper idiom
    in the main module:

        if __name__ == '__main__':
            freeze_support()
            ...

    The "freeze_support()" line can be omitted if the program
    is not going to be frozen to produce an executable.

Traceback (most recent call last):
File "/MadMax/gigahorse-toolchain/gigahorse.py", line 572, in
open(v, 'r') # check program exists
FileNotFoundError: [Errno 2] No such file or directory: 'decompiler_compiled'

When using MadMax with the linked branch of gigahorse-toolchain (#f89ccb4) and souffle 2.0.2-1538-geb8c6f6e4, gigahorse.py fails with errors like

Compiling madmax.dl to C++ program and executable
Error: Atom's argument type is not a subtype of its declared type in file data_structures.dl at line 12
Variable_Value(resVar, @add_256(val0, val1)) :-
-----------------------^------------------------
The argument's declared type is Value in file decompiler_imports.dl at line 57
.decl Variable_Value(var: Variable, value: Value)

Apparently there is a mismatch of versions between gigahorse and souffle.

Replacing gigahorse by the current version resolves the problem.

Is it safe for madmax to replace gigahorse #f89ccb4 by #8d7c33b, or should I expect problems?

Description

It doesn't detect ecrecover failing upon invalid input

How to Reproduce

See the following piece of code:

https://gist.github.com/HarryR/cce52596ffebdff2744c5d790888015a

This was caused by a compiler bug in Solidity < 0.4.14, where the output memory area for the ecrecover call wasn't cleared, which means in the case of an invalid signature the memory may contain user-controllable input.

If the contract address is passed in as the last 20 bytes of the 32-byte stuff2hash input, then the if condition will be true and the contract will send all funds to the caller.

This was recently highlighted as a problem with the 0x contracts, see: https://samczsun.com/the-0x-vulnerability-explained/

Expected behavior

this bug should be detected

Hello, wanted to test MadMax and run into some compilation issues for a contract:

Compiling /home/nettrino/smartcontractfuzzing/tools/madmax/MadMax/madmax.dl to C++ program and executable
compiler error: cannot compile source file /home/nettrino/smartcontractfuzzing/tools/madmax/MadMax/gigahorse-toolchain/cache/dddbde8644ecadfa59a1c5ace530c43e.cpp
g++ -std=c++17   -fwrapv  -DUSE_NCURSES  -O3 -DUSE_LIBZ  -DUSE_SQLITE  -fopenmp  -march=native  -std=c++17 -Wdate-time -D_FORTIFY_SOURCE=2 -o/home/nettrino/smartcontractfuzzing/tools/madmax/MadMax/gigahorse-tool
chain/cache/dddbde8644ecadfa59a1c5ace530c43e /home/nettrino/smartcontractfuzzing/tools/madmax/MadMax/gigahorse-toolchain/cache/dddbde8644ecadfa59a1c5ace530c43e.cpp  -ldl -lpthread -lsqlite3 -lz -lncurses -lfunct
ors  -I/usr/bin/../include -I/usr/bin/include
g++: fatal error: Killed signal terminated program cc1plus
compilation terminated.
failed to compile C++ source </home/nettrino/smartcontractfuzzing/tools/madmax/MadMax/gigahorse-toolchain/cache/dddbde8644ecadfa59a1c5ace530c43e.cpp>
Process Process-3:
Traceback (most recent call last):
  File "/usr/lib/python3.9/multiprocessing/process.py", line 315, in _bootstrap
    self.run()
  File "/usr/lib/python3.9/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "/home/nettrino/smartcontractfuzzing/tools/madmax/MadMax/gigahorse-toolchain/gigahorse.py", line 287, in compile_datalog
    assert not(process.returncode), "Compilation failed. Stopping."
AssertionError: Compilation failed. Stopping.
Processing contract names.
Setting up workers.
Analysing...

0: test.hex completed in 0.01 + 3.07 + 0.28 + 0.06 secs

Finished 1 contracts...

gigahorse-toolchain /gigahorse.py -j3 ~/test.hex works fine. Is this a bug or is there something wrong with my setup? (I am on Debian 11 and had to go through some hoops to install the older version of souffle needed). Attaching a zip with the binary for reference: test.hex.zip

Hi, I have used your famous Ethereum smart contract vulnerability detect tool, Madmax. I find only 3 vulnerability about DOS can be detected.
Could madmax defect other bug? I can't find the souffle file about other bug except oldclient.dl. But the result from this souffle file is not well, more than 50% was flagged with reentrance, the false positive may be too high.
Another word, I am interesting in your related work, gigahorse. The result of gigahorse from contract-lib is lower than 50% in detecting reentrancy, have you change to use another souffle file to detect, or the same file oldclient.dl?