search

carbonblack / binee

Binee: binary emulation environment
GNU General Public License v2.0
502 stars 73 forks source link

non-deterministic enumeration of imported libraries #41

Open mewmew opened 4 years ago

mewmew commented 4 years ago

Upon two consecutive executions of binee (with added debug statements for SearchFile, the following debug output was obtained. Notice that rpcrt4.dll follows shell32.dll in the output of the first execution, while msvcrt.dll follows shell32.dll in the outut of the second execution; thus indicating non-deterministic results.

emu.SearchPath
SearchFile("apisetschema.dll")
SearchFile("ntdll.dll")
SearchFile("kernel32.dll")
SearchFile("shell32.dll")
SearchFile("rpcrt4.dll")
SearchFile("advapi32.dll")
SearchFile("secur32.dll")
SearchFile("shlwapi.dll")
SearchFile("gdi32.dll")
SearchFile("user32.dll")
SearchFile("msvcrt.dll")
SearchFile("version.dll")
emu.SearchPath
SearchFile("apisetschema.dll")
SearchFile("ntdll.dll")
SearchFile("kernel32.dll")
SearchFile("shell32.dll")
SearchFile("msvcrt.dll")
SearchFile("rpcrt4.dll")
SearchFile("secur32.dll")
SearchFile("advapi32.dll")
SearchFile("shlwapi.dll")
SearchFile("gdi32.dll")
SearchFile("user32.dll")
SearchFile("version.dll")
mewmew commented 4 years ago

I think this was the only source of non-determinism was in ImportedDlls, and as such, this issue should be fixed by #42. Given the nature of non-deterministic bugs, this cannot be guaranteed.

As such, it would be good to add a test case that has a few additional imports (except kernel32.dll and ntdll.dll which are always at fixed locations in the list of imported libraries). Any CI test case failures would then let us know if this issue was also caused by other non-deterministic computations.