This is for position independent code. The call 0xe50b instruction pushes the address of the next instruction, and then jumps. It jumps to the immediately following instruction, which has no effect. The next instruction, pop eax, loads its own address into eax (as it was the value pushed by call).
Further down it uses an offset from eax:
mov eax, dword [ds:...
This is a frequently used "trick" to determine the address of the instruction following the call, i.e. the call instruction pushes the return address on the stack, which in this case corresponds to 0xe50b. After the pop instruction, eax contains that address.
For instance, this idiom is used for position independent code (pic), but is also quite commonly ...
Now I cannot possibly know what the exact reason is here, but there is another very good reason, not mentioned so far, for using this kind of method: throwing off a disassembler during static analysis.
The mechanics of call $+5 have been discussed, so I'll assume they are known by now - otherwise refer to the other answers. Basically like with any call on ...
A CALL instruction has the effect of pushing a return address onto the stack, before performing the control transfer to the call target.
In your example above, the CALL instruction will push the value 0x0000E50B onto the stack, before transferring control to 0x0000E50B. The POP instruction at 0x0000E50B will then pop the last value off of the top of the ...
Actually, GDB rely on the GNU binutils to open and disassemble the binary. So, the management of the binary format is done through libbfd.so.
Usually, MacOS X binutils comes with the Mach-O management, but it might be that you are using a buggy package. Or, you may also try to open a Mach-O on another system than MacOS X, and on other systems the Mach-O ...
Many thanks for your answer!
I did some more research and found the following out:
because my target is a part of the Macintosh system, the so-called "Apple binary protection" protects that from being disassembled/debugged directly.
otool -l [target]" reveals the following information:
Load command 0
You can modify strings or other bytes within the hex editor (⇧⌘H) or click on the hex edit panel.
Then modify whatever you want
You'll need to write a new executable back (⇧⌘E) if you want to save it. Also, be aware that if it is a signed binary, you will need to remove any code signature or resign it as the binary won't match the signature after a change....
As others have said, this is for getting current instruction's address. But it's not recommended as it'll hurt performance because it won't return anywhere, causing disagreement of return addresses in data stack and in the CPU's internal calling stack
The recommended way is
mov eax, [esp]
^^ ^ ^ ^^^^
|| Addr Data CRC16
` Data tag
D for data
L20 for 0x20 or 32 hex bytes, or 64 hex digits
I000000 the address (note ...
I'm surprised nobody posted an answer, but here's what I eventually came to realize:
A lot of times disassembling is used for taking apart potential malicious apps like viruses, worms, or malware to understand how they affect a system. There is both static and dynamic disassembly. Static disassembly poses (little) threat to your system as it is only looking ...
If I correctly understand your question, you are searching for the Cross References feature in Hopper.
Cross References (or simply XREFs) is a feature of disassemblers to show you where certain functions and objects were called from or which functions and objects are used by a specific function. We can simplify it by relate to it as XREF-...
Update: Admirably, after just a few days after I sent in a request to include a feature to send input to command line applications, the sole developer of Hopper disassembler has included the feature. Notice the new 'application output' tab in the new Hopper disassembler 3.3.3:
Some binaries hide the string on base64, with basic encryption algorithms rc4 or even with xor just for avoid what you are trying to achieve. Depending on the design of the owner of the binary you can find this types of techniques on them.
For example instead of do this
const char *msg = "Good morning";
You can do
const char *msg = "R29vZCBtb3JtaW5nCg==";...
Although OP clarified only the inner for is unreadable to him, I'll write an answer that thoroughly explains the first few lines and then abruptly stops at the most crucial part of the inner for loop. While believing examples are a great way to learn, I do that to make this as educational as possible, without interfering with the learning process of ...
I was able to achieve this by installing gdbserver on my ipad. Then i ssh into the ipad and attach a remote lldb debugger (xcode tools) to attack breakpoints. A long method but works. There are now tools to debug in same way on android and ios.
Finally I've found an answer.
After parsing result lies into $rbp-0xdo
(gdb) x/8w ((int*)($rbp-0xd0))
0x7fffffffdf90: 0x00000000 0x00001111 0x00002222 0x00003333
0x7fffffffdfa0: 0x00004444 0x00005555 0x00006666 0x00007777
when input is 0000:1111:2222:3333:4444:5555:6666:7777
So $rbp-0xb8 (var_b8) is similar to $rbp-0xd0+0x18, ...
Recent versions of Hopper do let you define the types for local variables.
With the focus on a procedure open the inspector and navigate down to the "Local Variables" section. Double click on the variable you want to change and a dialog will appear where you can change the name /and/ set the type for that variable.
I found a solution thanks to this ressource on GitHub: https://github.com/peterfillmore/removePIE/issues/1
After disabling ASLR, I copied the binary from the iPhone to a laptop.
Then, as described in the previously linked ressource, I extracted the entitlements with ldid, and put it back in while signing them. This step requires an apple developper account.
The values are stored in a plist file under ~/Library/Preferences (or ~/Library/Containers/.../ if sandboxed). You can find more information about it from Apple's documentation.
The easiest way to modify a value is to use the defaults program under terminal.
defaults write <bundle identifier> <key> <value>
I've checked version v3 and yes, it does not work with such instruction and it does work in v4. There are few bug reports that might be related to such issues.
Unfortunately I couldn't find if there is any workaround for this apart from installing a latest one.
I figured out how to make it work. Here's the procedure that needs to be followed:
Open a copy of the executable to be analyzed in Hopper on the host Mac
Put a copy of the executable to be analyzed on the VM
Install Hopper Debugger Server on the VM and launch it
In Hopper on the host Mac, choose Debug > Select Debugger
Select the VM
Change the path to the ...
If you compile optool from source, there is a new unrestrict flag.
optool unrestrict -t Payload/MY_APP.app/MY_APP
This worked. Load command removed.
There is even a nice guide explaining how to compile from source, here.
This seems to be a Hilbert curve representation of the binary's entropy values (probably each pixel is averaged over some small byte range). It was likely inspired by this work:
It might be easier to read the actual disassembly rather than an attempted decompilation.
arg0 is really argc for the main function. So, it is comparing argc to 2 and exiting if it is not equal; i.e. there should be one argument passed to the executable (keep in mind there is always one implicit argument which is the executable name itself)
According to the answer from the support (thanks, @Vincent Bénony)
There is a possibility to add a structure to the database, Modify --> Manage Types.
There is no possibility to assign a type to local variable for now.
There is a possibility to assign a synonym for register, but it will not be seen in decompilation view.