In the xor specification, that you can see here, there is no version of xor with imm64 - an immediate value of 64 bits.
You can do something like this:
mov rcx, 0x8000800080008000
xor qword ptr [rbx], rcx
Note that the register in the xor command must be r64 type (rax, rbx, ...) and not the r32 type (eax, ebx, ...)
Generally, the solutions to this problem can be classified to:
Pattern matching heuristics. Just like what you are proposing. For example, searching for pushes in the binary can provide a (rather) rough approximation of function starts. Things are more difficult if you want to locate function ends though.
Machine learning. Pattern matching can be automated ...
The function prologue (push ebp, etc.) is common in assembly, but not required. ebp is often used for local varible access, but can as well be used as a general purpose register, just like eax.
Assembly allows the code to manipulate stack pointer at any place and doesn't force it to follow any convention - as long as there are no exceptions, CPU will not ...
reading your question several times and the discussion in the comments i did not understand what you're trying to get/obtain, so i will be answering to parts that i think that are relevant according to the problems you posed. maybe other and more experienced people here would help elaborate and improve:
if you're trying to "reverse" an interpreted code, ....
The segment register value applies from one change point until the next or end of segment, so you don't have to set it for each function, just once per segment or a contiguous ARM or Thumb chunk is enough. If you have many wrong intermediate changepoints from previous analysis, you can delete them en masse from the "Jump to segment register..." dialog (Ctrl-...
Your physical RAM size doesn't say too much about what your memory addresses will look like. What matters is your system architecture and how many bits there are (usually 64 or 32). Virtual memory also makes RAM insignificant; each process has virtual memory space covering possibly the entire address space but mapped to a limited section of physical memory. ...
One of things I do is to read the machine code and translate it back into IR pseudo opcodes sans any addressing address values, and then perform differences between those two pseudo-IR binaries after using this reduction method on each.
The compiler creates the code block by block, each line of the source code can correspond to one or several blocks. In the case of optimized code, sometimes several blocks of source code can turn into one.
This basic block of code can be divided into the following logical blocks
; block #1
mov edi, offset _Z3strB5cxx11
call basic_string::length() ; // ...
This problem is not unique to call eax but potentially any indirect call or a call to a function with wrong type information. The possible causes and solutions are described in the Hex-Rays Decompiler manual.
One common cause is the stack adjustment of the call not being correctly detected by IDA (e.g. the called function is stdcall with arguments but IDA ...
You can take one of the following approaches:
call eax usually means there is an indirect call. try to find what and where eax is defined. Maybe only by looking at it, you will found the problem. If you find the origin but not understand the problem, you can try to patch it, to something like: mov eax, <known_function_address>
Maybe you can change a ...
If you want instruction access references to a particular variable, then first define the reference manager:
refmanager = program.referenceManager
Then lets say you get all the local variables of a particular function - using -
vars = function.getLocalVariables()
You can get references to a particular variable:
for var in vars:
for ref in refmanager....