New version don't work at all :( about vulnfanatic HOT 5 CLOSED

Hello,
Share the binary, that should be enough :)

Thanks

from vulnfanatic.

https://www.sendspace.com/file/l5viqy

in previous version it found potential UAF with [LOW] level of critically
Potential Use-afer-free Vulnerability
in current - nope.

from vulnfanatic.

and i noticed this while using new version

Loaded python3 plugin 'VulnFanatic'
Plugin Manager failed to parse 'plugins.json'. Error: '* Line 1, Column 1
  Syntax error: value, object or array expected.
'
Detected Little Endian endian ELF
ELF parsing took 0,006 seconds
Analysis update took 0,038 seconds
Analysis starting...
Adding section: .fini <0x1274 - 0x127c> for analysis.
Adding section: .init <0x1000 - 0x1016> for analysis.
Adding section: .plt <0x1020 - 0x107f> for analysis.
Adding section: .plt.got <0x1080 - 0x1087> for analysis.
Adding section: .text <0x1090 - 0x1270> for analysis.
Analysis Phase 2 created 0 functions. [x86_64:linux-x86_64]
Analysis Phase 3.0 created 1 functions [x86_64:linux-x86_64]
Analysis Phase 3.1 created 0 functions [x86_64:linux-x86_64]
Analysis update took 0,001 seconds
[*] Vuln scan done in 0.6714141368865967 and marked 0 out of 0 checked.
High: 0
Medium: 0
Low: 0
Info: 0

from vulnfanatic.

I think the last error you mention (the one with plugin.json parsing error is not related to this plugin). For the fist issue you submitted there is a following problem:

00001182  void* rax = malloc(bytes: 0x64)
0000118f  void* rax_2 = rax + 0x32
000011b9  if (rax != 0)
000011b9      memset(rax, 0x41, 0x64)
000011c5      puts(str: rax_2)
000011d1      free(mem: rax)
000011f5      memset(malloc(bytes: 0x64), 0x44, 0x64)
00001208      return puts(str: rax_2)
000011a3  exit(status: 1)
000011a3  noreturn

At address 0x0000118f the rax_2 variable is initialized with an offset to rax. This is a common way on how Binary Ninja handles structures and therefore the plugin assumes that the rax holds a structure value where rax and rax_2 point to different memebers of that structure. Therefore, freeing rax is treated as freeing the first member of that structure only and thus the use of rax_2 at address 0x00001208 is not considered to be an issue.
This is implemented as there were large number of false positives for functions which worked with structures passed as parameters to functions where members of that structure were referenced as arg1 + 0x8 (and similar).

There might be some improvements into how a variables that are likely a structure pointers are handled in the future but at this point this is not considered to be a bug as it is the way it is working right now. I am working on some updates continuously so you can check back later on.

from vulnfanatic.

This issue is now detected with version 3.2 as I have changed the way that variables are treated.

from vulnfanatic.