In the body, we have the RunAppModalLoopForWindow call, then at the end we find jne 0xBD3D which brings us back to 0xBD3D at the start, before the modal window call. Basic Block Input Regs: - Killed Regs: ebx ebp 0000bdcb 43 inc ebx XREF=0xbd70 0000bdcc FF8570FEFFFF inc dword 0000bdd2 83FB28 cmp ebx, 0x28 0000bdd5 0F8562FFFFFF jne 0xBD3D Around address 0xbd3d we find the following loop: We disassemble the binary and search for that modal window with something that looks like a loop. This is exactly the behavior that we have noticed previously. Right, so this seems pretty clear, Snapz Pro X seems stuck in an endless loop with a modal window showing. # 9 0x99fd25a5 in RunAppModalLoopForWindow ( ) # 6 0x99e53bb9 in ReceiveNextEventCommon ( ) # 5 0x99e53e04 in RunCurrentEventLoopInMode ( ) # 3 0x9014b3c4 in CFRunLoopRunSpecific ( ) Now we run the backtrace to see where that SIGKILL signal was received by Snapz Pro X: Program received signal SIGKILL, Killed. doneĪt this point we get a modal window that does not go away so we send SIGKILL to the Snapz Pro X process in order to detach GDB. Starting program : /Applications /Snapz Pro X /Snapz Pro X. Make breakpoint pending on future shared library load? (y or ) Since this one is a little more mean, we load up the Snapz Pro X binary in GDB and perform a backtrace after stepping once into the assembly:
0 kommentar(er)
