Breakpoints should have a setting which allows them to halt analysis or not

[SecondNewtonLaw]

Version and Platform (required):

• Binary Ninja Version: 4.2.6412-dev Personal (6254307f)
• OS: Windows 11
• OS Version: 24H2 (OS Build: 26100.2161)
• CPU Architecture: x86_64

Bug Description: Breakpoints stop function analysis; this is especially harmful when reverse engineering dumps of some programs, as sometimes authors will purposefully place breakpoints and break analysis throughout, and while I solved this manually on my PE dumper by byte patching the breakpoints, it is a pressing issue for any other reverse engineer that maybe does not want to write their own dumper, yet they're still faced with breakpoints throughout. This is worse considering __noreturn propagates to callers and int3 makes a function be __noreturn, so if I make a function simply have a breakpoint, I can break analysis in the binary in a substantial manner.

Steps To Reproduce:

• Create a function that has a normal body.
• Add interrupts (__debugbreak(), etc) throughout the function

Expected Behavior: The function should be analyzed completely, or if so, try to continue analysing after a breakpoint if some conditions are met; this could be done in a separate stage or after the initial analysis of the function is completed if it proves to be expensive enough.

Screenshots/Video Recording: N/A

Binary: N/A

Additional Information: IDA Pro handles breakpoints my simply placing __breakpoint() in its stead, which could be a manageable solution, as it also continues disassembling the function until it cannot continue. for whichever reason.

[xusheng6]

I have seen both cases where we should and should not stop analysis at int3. Maybe we should at a configurable option for it

[plafosse]

I believe the behavior that we have currently is the best option, however we should allow a setting which can override this default behavior. This is unfortunately not an easy fix as its reliant on #551

[Pixeluted]

I believe the behavior that we have currently is the best option, however we should allow a setting which can override this default behavior. This is unfortunately not an easy fix as its reliant on #551

For some scenarios it might be the best, however for malware analysis it is making the reverse engineering much more harder as malware developers can simply put __debugbreak() and break Binary Ninja's analysis.

[psifertex]

They'll also break the application unless it's being debugged too! So if they're going to register an exception handler to handle it they might as well just put junk bytes, or ud2 or any number of invalid instructions as those will also stop analysis. It's basically impossible to generically solve this problem and so just making sure we give users the ability to modify analysis (which we already do) is the most important thing.