Can NOT successfully disassembler an elf file (64bit)

[JaySon-Huang]

I try to use binaryninja to disassemble a crackme, but it cannot successfully disassemble it. The file can be downloaded from here: http://pan.baidu.com/s/1kTl5wxD

[JaySon-Huang]

I think that it is something wrong with the way to find next block while analyzing binary file.
In class Analysis 's analyze method, it find next block just by finding out * call instructions* but ignore \ jmp instructions **. That is why i figure out why this elf file can NOT successfully be disassembled.

https://github.com/Vector35/binaryninja-python/blob/master/Analysis.py#L982 Analysis.py line 982:

            func.findBasicBlocks()
            calls = func.findCalls()

            for call in calls:
                already_found = self.functions.has_key(call)
                for i in self.queue:
                    if i == call:
                        already_found = True
                if not already_found:
                    self.queue += [call]

https://github.com/Vector35/binaryninja-python/blob/master/Analysis.py#L916 line 916:

def findCalls(self):
    calls = []
    for block in self.blocks.values():
        for instr in block.instrs:
            if instr.isCall() and (instr.target != None):
                if (instr.target >= self.exe.start()) and (instr.target < self.exe.end()):
                    calls += [instr.target]
    return calls

[JaySon-Huang]

one more things, I think it is better to use spaces instead of tabs. According to PEP 0008 -- Style Guide for Python Code
https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces

[psifertex]

Can you be more specific about what's not working in that binary? When I load up that binary and use g to go to main (or just double click the main symbol in _start), it disassembles reasonably well. What parts are not disassembling for you? Can you give me a function offset that has trouble?

Secondly, the functions you're looking at are specifically for finding out call relationships, not basic block identification.

Also, as to PEP, I realize that's recommended, but note that it also says:

Many projects have their own coding style guidelines. In the event of any conflicts, such project-specific guides take precedence for that project.

That said, it might be helpful if we were to update the files to include source format hinting for emacs/vi.

One reason for not trying to arbitrarily change style is that, for example, your fork is really hard to cherry pick changes back into since basically /everything/ has been changed making it much harder to actually identify what was really done. I appreciate that you were able to get it working with Qt 5 (mostly? Last I checked there were still some bugs), but trying to integrate those changes is going to be difficult and maintain compatibility with other forks that are out there.

[psifertex]

Oh! @D0ntPanic pointed out to me what might be the problem -- some functions aren't auto-identified as code but you can just hit p to treat it as a function and it will disassembly properly. I did that without even realizing that might be what you referring to on main.

[JaySon-Huang]

oh! I don't know that there are short cut g && p, I didn't notice that from your website and I have not found that in the menu bar.

When I opened this file, I just see a single block _start and I can't find the way the jump to main by clicking nor dragging.

[JaySon-Huang]

I think that listing all the symbols on a side bar and let user jump to the disassembly block is a more easy way to use.

[JaySon-Huang]

for the branch I tried to migrate binja to PyQt5 and Python3. now I am used to use Python3 and have the environment of PyQt5, so have a try to reuse that. But under Python3, many bugs appear because of the differences between bytes and string, so I stopped and build a Python2 environment to use binja...

[psifertex]

Yeah, the C++ version (which will be a commercial app) already supports listing the symbols in the sidebar, it's one of the features that might make it back to this version.

There's actually a number of hidden hotkeys that we should get around to documenting or indicating somewhere. Adding a menu item might be the easiest way to do that. I made #9 to track that.

You can double-click main from the start function and then you only need to use p to tell it there's a function there instead of also using g.

I'm definitely interested in trying PyQt5 as well -- already had to work around one bug in Qt 4 that won't get fixed (#3), if you end up getting just that part going, be happy to accept a PR, or I might give it a go based on what you did later.

Anyway, I'm going to close this bug as it's spawned a few other ideas. For what it's worth, I've avoided using/knowing Python 3 so I wouldn't accept any PRs that migrated over to that, though of course you're welcome to maintain your own branch.