What would be the recommended settings for large malformed binaries?

[DeprecatedLuke]

The issue that I am having is at Step 1, which is the initial control flow analysis.

What happens is that the binary has a lot of random indirect branches, mostly jumps (50% of the binary) which causes binary ninja to slow down to a crawl, changing settings doesn't appear to help that much.

Although patching out most of them is rather trivial. I feel like binary ninja should at-least be able to pass the control-flow step as the binary is only 1/5th the size with all "junk" code removed.

A rather simple example would be:

0:  72 08                   jb     0xa
2:  c0 f4 00                shl    ah,0x0
5:  73 65                   jae    0x6c
7:  0f 31                   rdtsc
9:  e8 72 60 00 00          call   0x6080
e:  80 e8 20                sub    al,0x20
11: 0f 82 8d cf 00 00       jb     0xcfa4
17: f6 de                   neg    dh
19: c7 c7 8f 61 70 06       mov    edi,0x670618f
1f: 0f 85 94 bb 00 00       jne    0xbbb9
25: 81 c3 ad 48 57 bf       add    ebx,0xbf5748ad
2b: 54                      push   rsp
2c: 80 ed da                sub    ch,0xda
2f: 50                      push   rax
30: 81 c0 20 29 1a 12       add    eax,0x121a2920
36: 0f 80 fe 76 01 00       jo     0x1773a
3c: 81 c1 86 c3 eb 11       add    ecx,0x11ebc386
42: e8 92 bf 00 00          call   0xbfd9
47: 77 57                   ja     0xa0
49: f6 dd                   neg    ch
4b: c7 c5 e1 ba 5b 07       mov    ebp,0x75bbae1
51: 80 e9 94                sub    cl,0x94
54: 79 b4                   jns    0xa
56: 83 c2 08                add    edx,0x8
59: 6a 74                   push   0x74
5b: 80 c1 c6                add    cl,0xc6
5e: 52                      push   rdx
5f: c6 c6 13                mov    dh,0x13
62: 83 c5 e6                add    ebp,0xffffffe6
65: f6 db                   neg    bl
67: 4d 6b 9f 71 86 48 8b    imul   r11,QWORD PTR [r15-0x74b7798f],0x44
...
1000: c3 ret

This is a simple vmprotect type number mutation combined with a large amount of jump branches as junk code.

Not sure if this is already a setting within binary ninja to prevent binary ninja trying to follow every single possible path a program can take.

More information:

The log that is generated in this case is:

Creating function within basic block at 0x7ff75bb22a02
Creating function within basic block at 0x7ff75bb22a02
Creating function within basic block at 0x7ff75bb22a02
Creating function within basic block at 0x7ff75bb22a02
Creating function within basic block at 0x7ff75bb22a02
Creating function within basic block at 0x7ff75bb22a02
Creating function within basic block at 0x7ff75bb22a02
Creating function within basic block at 0x7ff75bb22a02
Creating function within basic block at 0x7ff75bb22a02
Creating function within basic block at 0x7ff75bb22a02
Creating function within basic block at 0x7ff75bb22a02
Creating function within basic block at 0x7ff75bb22a02
Creating function within basic block at 0x7ff75bb22a02
Creating function within basic block at 0x7ff75bb22a02
Creating function within basic block at 0x7ff75bb22a02
Creating function within basic block at 0x7ff75bb22a02
Creating function within basic block at 0x7ff75bb22a02
Creating function within basic block at 0x7ff75bb22a02
Creating function within basic block at 0x7ff75bb22a02
Creating function within basic block at 0x7ff75bb22a02
Creating function within basic block at 0x7ff75bb22a02
Creating function within basic block at 0x7ff75bb22a02
Creating function within basic block at 0x7ff75bb22a02
Added windows-x86_64 function at 0x7ff75bb22a02

which adds a large amount of "Continuation of function sub_*.

[psifertex]

Not following branches is... impossible. Binary Ninja wouldn't know which branch to follow and wouldn't be analyzing anything if it didn't. It has to identify complete functions at the disassembly level before it can lift to an IL and use its data flow analysis to be able to optimize paths as dead and remove them from analysis.

I would recommend opening with options and choosing "basic" or control flow" mode for analysis mode. You can also try changing the analysis time per function or minimum function analysis size to enable quicker first analysis before patching and re-enabling to continue analysis.

Additionally, this would likely benefit from a plugin to do those patches such as OPP: https://github.com/Vector35/OpaquePredicatePatcher

The new workflow APIs (only really available in the C++ APIs unfortunately for performance reasons right now) could also be used to rewrite the binary on the fly and improve analysis but that would be a lot more work.

[DeprecatedLuke]

Changing the "analysis time per function" even to 1 ms doesn't appear to do anything, no skipped messages in debug log.

[psifertex]

Analysis time limit is problematic for a variety of reasons I wouldn't recommend relying on it to skip functions. Instead, try lowering analysis.limits.maxFunctionSize or analysis.limits.maxFunctionUpdateCount.