It was present on the stack before and esp, 0xfffffff0 instruction that aligns the stack to 16 bytes. This instruction doesn't erase the data that was previously at esp (so ecx-4 still points to the return address), but stack pointer points now to possibly different value than at the begining of the function. So there is a need to push the return value ([ecx-...
Without the proguard mapping, this is not possible. That information is simply no longer contained in the dex file.
The best you could do would be to manually rename the methods, etc. with your own names.
You're showing x86 (32bit) shellcode, but are not compiling your program for that architecture, so gcc most likely creates an amd64 (64bit) executable instead. This can be fixed by adding the -m32 switch:
gcc -g -Wall -fno-stack-protector -z execstack -m32 code.c -o code
You can verify this by running file on the resulting file:
code: ELF 32-bit LSB ...
The opcode you are interested in is a9 01 00 00 00 standing for test eax, 1.
The easiest way to get the opcode of assembly instruction is just to compile it and disassemble the result (for example using nasm and then objdump or simply this site) - this way you don't have to remember anything about the opcodes which are sometimes weird.
However, you want ...
For an individual instruction, yes, sure. See this recent blog post of mine and search for "Jenga". If you're talking about inspecting the pcode after the decompiler has done its business with it, there's a couple of scripts that user d-millar has repeatedly linked on the Ghidra GitHub that demontrate how to use that form of the pcode from the API, as well ...
You're correctly interpreting C++'s way of implementing class inheritance, however your assumption that the "subobject" is a member object of the class may be incorrect.
Through compiled code alone, It is impossible to completely distinguish member objects from additional inheritance in multiple inheritance classes as both appear the same. As a matter of ...
When you have just raw bytes without proper headers tools might not know how to process as the code might not start from offset 0. They could try to analyze the bytes to detect if there's code, data or something else but you might also get some false-positives.
In your case, you instruct r2 to display those bytes as code (pd - print disassembly) and it does ...
After a bit more research, and help from a friend, I figured it out.
the movss and mov are opcodes and its usually in the form of a float (for movss atleast)
So, hence, you CAN change its value.
Simply write movss [..address..],(float)### replace ### with your number.
As for my question, it works, I have disabled the entire game's health decrement. ...
If you have loaded the binary into IDA and the data has no references, I would suggest, you have loaded the binary into the wrong address space.. Or it's referenced in a relative fashion and you have not decoded the code that references it.. depending on the CPU and how does references, aka something like a FR only does absolute references, so you can ...
The ds means "data segment" register in x86 architecture, while ss states for "stack segment" register. You would probably want to read link for more comprehensive description. When you see
mov ds:[address], 0xAA,
it means "move 0xAA to address address in data segment", that is segment pointed by the current value of ds register. Similarly with every other ...
I would try CP949. Of course, this assumes that text data is not packed or encoded, which can happen too. Maybe try dumping/searching the emulator process memory at runtime (add UTF-16 too in that case), then try to track down how it appears there.
EDIT I missed originally that the game is for PS2. In that case UTF-8 is unlikely, as well as plain text data ...
This has something to do with the way Ghidra handles relocations. Loading the SLUS_204.99 binary with the following processor options and relocations disabled.
The disassembly is the same as that of IDA.
Using readelf shows that there are relocations of type R_MIPS_26 at the said ...
To examine in radare2 you can think as 'print values' and you can use:
px show hexdump
pxl display N lines (rows) of hexdump
pxr[j] show words with references to flags and code (q=quiet)
> px [nBytes] @[address][offset]
"Print hex 10 bytes at rbp plus 10"
[0x5618eccbf77a]> px 10 @rbp+10
There are no set definitions for "32-bit disassembler" and "64-bit disassembler". The terms are in fact ambiguous.
32-bit and 64-bit just refer to CPU architectures. Specifically to things such as register size and bus size. These can apply to many things.
Specifically, in the case of a disassembler, they can apply to two things:
The CPU architecture for ...
The function parses the PE header to locate the IMAGE_EXPORT_DIRECTORY which has the structure
NumberOfNames contains the number of symbols exported by this PE and is located at an offset of 0x18.
AddressOfNames is a pointer to an array of null-separated list of exported function names. This is located at offset 0x20.
Using the NumberOfNames value it ...
Could it be multiple inheritance? That could explain why the vptr of the supposed subobject is overwritten by ctor_2 without having to assume the compiler to inline anything. The derived class might actually have two base classes, the "base" and the "subobject". If this is the case, it kinda makes sense why the compiler would make ctor_3 to change the vptr ...
The point of dynamic linking a library is not including the library in the object, so the sections you want to disassemble just aren't there.
You could even replace the dynamic library (the .so object) with something else, which could result in different code being run by your same main program.
So you first need to identify which dynamic objects are ...
Yes, it is possible. Although you could solve your problem in several ways, I'll provide you with the easiest one in my opinion. The tool you could use is objcopy. It allows you to change contents of ELF files and I'll show you step-by-step example how to use it to achieve your goal. In the example presented below, I'm working on 64bit Linux machine.
The 24 pin debug connector on the GR-55 seems to have all required signals for the E10A-USB, so I'm guessing they just used a smaller connector to reduce board space and cost. The connection diagram below is for a different CPU, but the pin designations match those in the GR-55 so I bet they are compatible. You just have to make a custom adapter cable.
I recently made a tool to make the early stuff in 8051 reverse engineering easier, called at51 and will shamelessly use this answer as a showcase.
First off, you want the image to be properly aligned.
Rarely is 8051 firmware aligned, and for this file this is also true.
By using the base subcommand, you get the offsets most likely to be the offset the file ...
Looks like you also asked the question over on the Ghidra GitHub page and the answer there is the same.
Essentially, no, Ghidra does not do that. But you should investigate Angr, Klee, Bitblaze, or others.
What's these instruction sequences for?
They are for code optimization.
To optimize memory accesses, the CPU uses its own (small) internal memory called cache. It usually consists of several levels named L1, L2 etc. A lower suffix number means that the memory is located closer to the CPU core, thus is faster to access, but it's smaller as well. ...
The esp value at the end of the function is computed based on the ecx value stored on the stack. This value is stored immediately "above" (has higher address) the buffer which in your case has 260 bytes instead of 256 (notice sub esp, 0x104 - the reason behind this is to keep the stack aligned to 16 bytes before each function call). So why does providing 260 ...
First, a bit of background on why these registers are needed. PPC is a RISC-like ISA, in that all instructions are of the same size (32 bits) and there is limited space for immediate values (usually 16 bits at most) that you would use for things like addresses. So how do you address more that 16 bits?
One option is to build addresses by 16-bit slices, e.g. ...
I'll present the steps that I would perform in such a case. Note that they aren't necessarily the most efficient and reliable ones although they should work in many cases. I'm assuming that the binary you want to examine isn't packed and obfuscated.
Look for the imports. Sometimes the code you are looking for is just taken from external library. In this ...
There seems to be a local array on the stack frame that takes up 78h =
120d bytes on the stack, indicated by this line :
no the local var is of type int and it takes 4 bytes on 32 bit machine
it is located at the address ebp - 0x78
the other one is again a int and is located at esp+4
the circus is probably some home grown obfuscation may be
all it does ...
you don't have to attach to a running process you can open any binary as a dumpfile and ask windbg to disassemble a given function
There is a dbgeng api Execute and ExecuteCmdFile that can execute commands
you can write a standalone dbgeng executable that can open a binary run the command uf and quit
with ".opendump \..\foo.dll ; uf foo!blah;q"
I think this is a strcmp function which was compiled without optimization and is really inefficient.
Here is why:
The function only uses r0 and r1 which are first and the second parameter.
Both parameters are pointer because they are dereferenced
All memory access are byte long
Read bytes are compared against '\0'
Read bytes are compared using the ...