The purpose of sub_3699 is to return address of the next instruction after the one that called that procedure. call sub_3699 pushes address of the next instruction onto the stack and jumps to the first instruction of sub_3699.
That instruction takes the value at the top of the stack (without removing it) and writes it to ebx. Such a mechanism is usually used ...
I have experienced this in the past too with different tools. What I have done is find something easy to locate in both tools such as the DLL Main of a library or Entry Point of the PE file, (or another string) etc. Then you can calculate the offset between the two tools. Depending on the program, it can change with each run of the debugger. What X64DBG is ...
the buffer is at data_20a0 as comment next to instruction shows
are you running it under a debugger if so set a conditional logging breakpoint to print and continue
if you are not running it under debugger you may need to use some instrumentation framework
shown below is a windows example see if you can ...
i got the solution.
The solution is on internet in the next links:
Thank Edward for your help!
Yeah, finally figured it out by myself. After further testing, it turns out that the problem was indeed with branching. Instead of branching in thumb state, I should have branched in arm state.
0x2cc3a8 33F0EABF b 0x33fd8
0x2cc3a8 4C3A0CEA b 0x33fd8
I don't exactly understand the reason behind this since the original ...
Actually what I needed to do was to branch to an empty code cave and insert my code there. Also, I was using a disassembler which was not correctly analysing the function, for example this 71704708hex value was decoded as a thumb instruction set on another disassembler while on the disassembler I first used it was an ARM instruction set. The starting address ...
Standalone LDC and STC instructions are almost never used in ARM binaries. They were used for a short time in early ARM ISA extensions:
FPA (Floating-point accelerator) used some variants of LDC/STC etc. to load and store data. IIRC they used coprocessor numbers 0/1/2. It used custom 48-bit floating point format and just a few processors were released that ...