I'm newbie in Reverse Engineering and I'm trying to change a jnz condition to jz with IDA. After I patched the binary the application can not be open.
There's the original binary:
And the modified:
EDIT:
Another hypothesis for the problem is that the patched binary has a different number of bytes due to the switch from jnz to jz. Can be it? If so, how can I resolve this difference in bytes?
JZ and JNZ both have 1 or 2 byte instructions not including arguments. Perhaps IDA used a different sized instruction.
To view the assembly bytes to go Options->General->Disassembly and in "Number of Opcode bytes" put an 8. Now you can see the bytes in the disassembly.
Now you can change back and forth and find out how many bytes each instruction is.
View more info about these instructions here
If IDA is generating the wrong instruction, then manually change it by editing the hex.
You can always view file size to see if the size has changed. If the program continues to "not run", attach the debugger and find out why, there is no reason I can think of, if the number of bytes is the same it should work fine with the worst case scenario being an infinite loop
Related
What kinds of bytes does GDB insert in memory to debug the executable?
I know that GDB must insert (or manipulate) some bytes in memory, since when I debug a program that computes, i.e., the XOR over a region of memory and set the breakpoint within this region, then the program computes the wrong result.
However, if I do x (inspect memory), then everything in memory seems unchanged.
My question is therefore:
Suppose I set a breakpoint, e.g., b *0x40206e. What (invisble) changes does GDB make to the executable within memory to support debugging it?
I know that GDB must insert (or manipulate) some bytes in memory
t
You know that it does, not that it must.
GDB could instead use debug registers to insert (small number of) breakpoints without modifying program code, but it's easier to simply insert 0xCC at every breakpoint address: doing so doesn't have any limitations, works on all processors, and is simply easier.
Thus, to insert a breakpoint on x86, GDB saves the first byte of the original instruction in its own memory (so it can restore the original instruction later), and overwrites that byte with 0xCC (the int3 "trap to debugger" instruction).
However, if I do x (inspect memory), then everything in memory seems unchanged.
That's because GDB knows where it has inserted breakpoints, and pretends that the program code is unmodified (in other words, the examine command shows you what is supposed to be in memory, not what actually is there).
If it didn't, it would be very confusing to e.g. issue disassemble command and see int3 and "gargbage" remains of the original instructions.
This is an abstract view of the implementation of the MIPS subset showing the
major functional units and the major connections between them
Why we need to add the result of (PC+4) with instruction address?
I know that the PC (Program Counter) is a register in a computer processor that contains the address (location) of the instruction being executed at the current time, but i didn't understand why we add the second adder in this picture?
Some of the operations that can be performed by the CPU are 'jumps'.
If your operation is a Jump, from the second block you get the address of the new instructions OR the lenght of the jump you have to do.
It's not the instruction address, the output of the instruction memory is an instruction itself.
They've obviously hidden most of the components (there's NO control circuitry). What they probably meant is the data path for branches, though they really should have put at least the link with the ALU output in there. Even so it would be better to explicitly decode the instruction, sign extend and shift left. So it's really inaccurate, but I don't see what else they could mean.
I am working with a Cortex-A9 and my program crashes because of an UNDEFINED_INSTRUCTION exception. The assembly line that causes this exception is according to my debugger's trace:
Trace #9999 : S:0x022D9A7C E92D4800 ARM PUSH {r11,lr}
Exception: UNDEFINED_INSTRUCTION (9)
I program in C and don't write assembly or binary and I am using gcc. Is this really the instruction that causes the exception, i.e. is the encoding of this PUSH instruction wrong and hence a compiler/assembler bug? Or is the encoding correct and something strange is going on? Scrolling back in the trace I found another PUSH instruction, that does not cause errors and looks like this:
Trace #9966 : S:0x022A65FC E52DB004 ARM PUSH {r11}
And of course there are a lot of other PUSH instruction too. But I did not find any other that tries to push specifically R11 and LR, so I can't compare.
I can't answer my own question, so I edit it:
Sorry guys, I don't exactly know what happend. I tried it several times and got the same error again and again. Then I turned the device off, went away and tried it again later and know it works fine...
Maybe the memory was corrupted somehow due to overheating or something? I don't know. Thanks for your answers anyway.
I use gcc 4.7.2 btw.
I suspect something is corrupting the SP register. Load/store multiple (of which PUSH is one alias) to unaligned addresses are undefined in the architecture, so if SP gets overwritten with something that's not a multiple of 4, then a subsequent push/pop will throw an undef exception.
Now, if you're on ARM Linux, there is (usually) a kernel trap for unaligned accesses left over from the bad old days which if enabled will attempt to fix up most unaligned load/store multiple instructions (despite them being architecturally invalid). However if the address is invalid (as is likely in the case of SP being overwritten with nonsense) it will give up and leave the undef handler to do its thing.
In the (highly unlikely) case that the compiler has somehow generated bad code that is fix-uppable most of the time,
cat /proc/cpuinfo/alignment
would show some non-zero fixup counts, but as I say, it's most likely corruption - a previous function has smashed the stack in such a way that an invalid SP is loaded on return, that then shows up at the next stack operation. Best double-check your pointer and array accesses.
I have a ARMv5-powered non-XScale device (the SHARP Brain™ electronic dictionary) with Windows Embedded CE 6.0 installed in NAND flash, and I use TCPMP to play my favorite AAC tunes and MPEG-4 movies.
But, when I start TCPMP, sometimes TCPMP freezes. So I looked into TCPMP and I managed to found that the freeze happens when this code is executed.
CheckARMXScale PROC
mov r0,#0x1000000
mov r1,#0x1000000
mar acc0,r0,r1 ; <--- here
mov r0,#32
mov r1,#32
mra r0,r1,acc0
cmp r0,#0x1000000
moveq r0,#1
movne r0,#0
cmp r1,#0x1000000 ;64bit or just 40bit?
moveq r0,#2
mov pc,lr
This code determines whether XScale is present by trying executing XScale instruction, and catching the exception if the "Undefined Instruction" exception was thrown.
The problem is that somehow the system fails to pass this exception to TCPMP properly, causing TCPMP to freeze. It seems to be not because of Windows CE, but rather because of buggy drivers in this device. Any driver updates are not expected since running TCPMP on this device is not officially supported.
I posted this issue to 2channel, and some people claimed that this way to determine if XScale is present is not good, but no one even tried to find a better way. So I googled and read through ARMv5 Architecture Reference Manual and so on, but I could find nothing. It appears that almost every program that utilizes XScale instruction set determines if XScale is present in the same way.
The question is that, is it possible to determine if XScale instruction set is present, without making use of any exception or any CPU mode except user mode?
Try IOCTL_PROCESSOR_INFORMATION
(needs switching into kernel mode) read the CP15 register c0, Main ID register aka ID Code Register aka ARM CPUID. The top byte is the implementor which will be 0x69 ('i', Intel) for XScale.
Check also this thread.
I know that executables contain instructions, but what exactly are these instructions? If I want to call the MessageBox API function for example, what does the instruction look like?
Thanks.
Executables are binary files that are understood by the operating system. The executable will contain sections which have data in them. Windows uses the PE format. The PE Format has a section which has machine instructions. These instructions are just numbers which are ordered in a sequence and is understood by the CPU.
A function call to MessageBox(), would be a sequence of instructions which will
1) have the address of the function which is in a DLL. This address is put in by the compiler
2) instructions to "push" the parameters onto a stack
3) The actual function call
4) some sort of cleanup (depends on the calling convention).
Its important to remember that EXE files are just specially formatted files. I dont have a disassembly for you, but you can try compiling your code, then open your EXE in visual studio to see the disassembly.
That is a bloated question if I ever saw one.
BUT, I will try my best to give an overview.
In a binary executable there are these things called "byte codes", byte codes are just the hex represtation of an instruction. Commonly you can "look up" byte codes and convert them to Assembly instructions. For example:
The instruction:
mov ax, 2h
Has the byte code representation:
B8 02 00
The byte codes get loaded into RAM and executed by the processer as that is its "language". No one sane that I know programs in byte code, it would just be wayyyy to complicated. Assembly is...fun enough as it is. Whenever you compile a program in a higher level language it has to take your code and turn it into Assembly instructions, you just imagine how mangled your code would look after it compiles it. Don't get me wrong, compilers are great, but disassemble a C++ program with IDA Pro Freeware and you will see what I am talking about.
That is executables in a nutshell, there are certainly books written on this subject.
I am not a Windows API expert, but someone else can show you what the instruction would look like for calling the Windows API "MessageBox". It should only be a few lines of Assembly.
Whatever code is written (be it in C or some other language) is compiled by a compiler to a special sort of language called assembly (well, machine code, but they're very close). Assembly is a very low-level language, which the CPU executes natively. Normally, you don't program in assembly because it is so low-level (for example, you don't want to deal with pulling bits back and forth from memory).
I can't say about the MessageBox function specifically, but I'd guess that it's a LOT of instructions. Think about it: it has to draw the box, and style it however your computer styles it, and hook up an even handler so that something happens when the user clicks the button, tells Windows (or whatever operating system) to add it to the taskbar (or dock, etc), and so many other things.
It depends on the language that you are working in. But for many it is as simple as...
msgbox("Your message goes here")
or
alert("Your message goes here")