I have some code that OllyDbg is having trouble disassembling. This mostly happens at indirect jumps. For example in the code shown in the image below you can see that the EIP (CPU instruction pointer) is at 401839 which is a valid code address. 0x83F800 should disassemble to "cmp eax 0", but OllyDbg is not doing it. The CPU happily runs the code but I can't see the disassembly.
Is there any way to hint OllyDbg to disassemble the code (starting at 401836, eg)?
I tried using the menu choice "Analyse Code" (ctrl+A), but that did not work in this instance.
If "Analyse Code" doesn't change anything, try the reverse; removing it with "Remove analysis from selection"
Right Click -> Analysis -> During Next analysis, treat selection as -> Command
Select Your db ?? and Analyze again,
You should get more familiar with Analysis.
Unfortunatly I don't have any doc or link for you.
Related
I am currently debugging some assembly code using GDB and am stuck on the following problem. Somehow or other, I've ended up at a bogus instruction address, probably because either I called a bogus function pointer, or I mangled the return address on the parent stack frame.
GDB is fantastic and stops the program exactly when it detects this has happened. However, what it doesn't tell me is the instruction address that sent me to this bogus address. So now I am stuck. I know that I am now at a bogus address, but I have no way of knowing how I got here. What I think I need is a list of the last n values that $rip has taken on. But I cannot find any way of doing that in GDB's documentation and am pretty sure it is not possible.
So I would appreciate it if anyone else had any great tips on low-level debugging they could share. Thanks!
-Patrick
I think GDB's trace might helps
https://sourceware.org/gdb/onlinedocs/gdb/Tracepoints.html
When your code crash, the trap is raised and the instruction pointer jump to the trap table, the jump depends on the trap raised.
You want to determine which instruction causes this trap, so you can execute the command backtrace (bt) to show the latest exectuted functions before the jump to the trap table. When you identify the function, execute step by step to idenfy the instruction which causes the error.
If you are using a target with gdb in remote mode, you need to give gdb a strong symbol table to allow the awareness of the whole code symbols.
I have an application compiled using GCC for an STM32F407 ARM processor. The linker stores it in Flash, but is executed in RAM. A small bootstrap program copies the application from Flash to RAM and then branches to the application's ResetHandler.
memcpy(appRamStart, appFlashStart, appRamSize);
// run the application
__asm volatile (
"ldr r1, =_app_ram_start\n\t" // load a pointer to the application's vectors
"add r1, #4\n\t" // increment vector pointer to the second entry (ResetHandler pointer)
"ldr r2, [r1, #0x0]\n\t" // load the ResetHandler address via the vector pointer
// bit[0] must be 1 for THUMB instructions otherwise a bus error will occur.
"bx r2" // jump to the ResetHandler - does not return from here
);
This all works ok, except when I try to debug the application from RAM (using GDB from Eclipse) the disassembly is incorrect. The curious thing is the debugger gets the source code correct, and will accept and halt on breakpoints that I have set. I can single step the source code lines. However, when I single step the assembly instructions, they make no sense at all. It also contains numerous undefined instructions. I'm assuming it is some kind of alignment problem, but it all looks correct to me. Any suggestions?
It is possible that GDB relies on symbol table to check instruction set mode which can be Thumb(2)/ARM. When you move code to RAM it probably can't find this information and opts back to ARM mode.
You can use set arm force-mode thumb in gdb to force Thumb mode instruction.
As a side note, if you get illegal instruction when you debugging an ARM binary this is generally the problem if it is not complete nonsense like trying to disassembly data parts.
I personally find it strange that tools doesn't try a heuristic approach when disassembling ARM binaries. In case of auto it shouldn't be hard to try both modes and do an error count to decide which mode to use as a last resort.
I want to debug into the implementation of a [MethodImpl(MethodImplOptions.InternalCall)] BCL method, which is presumably implemented in C++. (In this particular case, I'm looking at System.String.nativeCompareOrdinal.) This is mainly because I'm nosy and want to know how it's implemented.
However, the Visual Studio debugger is refusing to step into that method. I can set a breakpoint on this call:
"Hello".Equals("hello", StringComparison.OrdinalIgnoreCase);
then bring up Debug > Windows > Disassembly, step into the Equals call, and step until it gets to the call x86 instruction. But when I try to use "Step Into" on that call (which I know from Reflector is the nativeCompareOrdinal call), it doesn't step to the first instruction inside nativeCompareOrdinal like I want -- it steps over instead, and goes straight to the next x86 instruction in Equals.
I'm building as x86, since mixed-mode debugging isn't supported for x64 apps. I've unchecked "Just My Code" in Tools > Options > Debugging, and I have "Enable unmanaged code debugging" checked in project properties > Debug tab, but it still steps over the call. I also tried starting the process and then attaching the debugger, and explicitly attaching both the managed and native debuggers, but it still won't step into that InternalCall method.
How can I get the Visual Studio debugger to step into an unmanaged method?
Yes, it is tricky. The offset you see for the CALL instruction is bogus. Plus it won't let you navigate to an unmanaged code address when the current focus is on a managed function.
Start by enabling unmanaged code debugging and setting a breakpoint on the call. Run the code and when the break point hits use Debug + Windows + Disassembly:
"Hello".Equals("hello", StringComparison.OrdinalIgnoreCase);
00000025 call 6E53D5D0
0000002a nop
The debugger tries to display the absolute address but gets it wrong because it uses the bogus incremental address instead of the real instruction address. So first recover the true relative value: 0x6E53D5D0 - 0x2A = 0x6E53D5A6.
Next you need to find the real code address. Debug + Windows + Registers and look at the value of the EIP register. 0x009A0095 in my case. Add 5 to get to the nop, then add the relative offset: 0x9A0095 + 5 + 0x6E53D5A6 = 0x6EEDD640. The real address of the function.
Debug + Windows + Call Stack and double-click an unmanaged stack frame. Now you can enter the calculated address in the Disassembly window's Address box, prefix with 0x.
6EEDD640 push ebp
6EEDD641 mov ebp,esp
6EEDD643 push edi
6EEDD644 push esi
6EEDD645 push ebx
6EEDD646 sub esp,18h
etc...
Bingo, you're know you're good if you see the stack frame setup code. Set a breakpoint on it and press F5.
Of course, you'll be stepping machine code since there's no source code available. You'll get much better insight in what this code is doing by looking at the SSCLI20 source code. No guarantee that it will be a match for the actual code in your current version of the CLR but my experience is that these low-level code chunks that have been around since 1.0 are highly conserved. The implementation is in clr\src\classlibnative\nls, not sure which source code file. It won't be named "nativeCompareOrdinal", that's just an internal name used by ecall.cpp.
This is definitely obsessive, but I am fascinated by how cleverly the compiler translates C code into machine instructions. Since I am a little fuzzy on some instructions, it would be helpful if I could watch the operation of a compiled program at the level of individual machine instructions - "below" the level of a C statement (which might generate several CPU instructions). In other words, can I watch the registers/memory change after a single machine instruction?
I'm sure it's possible with some other debuggers, but I am only using Xcode.
It's possible to use Xcode's step over, step in, and step out commands with the debugger. The trick is to hold the ctrl (Control) key while you mouse over the debugger step icons to change the context. Underneath each step icon, the line will change to a dot and you can then step at the instruction level.
See the attached screenshot highlighted with a red oval.
si is "Step Instruction", and ni is "Next Instruction". They have the same semantics as "step" and "next" do for lines of code, just on the instruction level.
In the Debugger window, enable assembly: Run/Debugger display/Source and disassembly. Wait till you hit a breakpoint. Then use Run/Step into(over) instruction to step in assembly.
Ooops, didn't check closely enough - Step Into w/Option (Cmd-Opt-Shft-I = ⌘⌥⇧I)
I'm having trouble using software breakpoints in WinDbg in order to break in a given address.
It's a Visual C++ 6.0 MFC executable without symbols (belive me, I just can not generate the symbols).
Suppose my executable image is named image00400000. Using Software Breakpoints (bp):
0:000> bp image00400000 + 0x003ba1eb
0:000> bl
0 e 007ba1eb 0001 (0001) 0:**** image00400000+0x3ba1eb
0:000> g
I get the relative address (0x003ba1eb) from the .map file (this one I got it). I pick up a line which I'm sure that will be executed, but there is no stop at all...
Does anyone have any ideas? I'd appreciate them. Thank you!
PD: If there's anything left to explain or you need more info, just drop me a comment :-)
Sorry I'm not allowed to create comments yet (too new) to SO.
It is a bit tricky to be specific with the information available. I guess it is possible that the breakpoint address isn't calculated correctly. Given the situation I would attempt to calculate the breakpoint address as: Module start + code start + code offset from the map file. Maybe this is what you did (unless I got it wrong ;-) )
Also worth noting that the bp address needs to align on an instruction boundary. If it doesn't then it won't be set properly. This could be possible if you are having to guess at trying to get a breakpoint into a particular function.
It might be helpful to outline a little more about the condition under which you want the program to stop in the debugger.
To add symbols, you need to make a debug build
BUILD menu item
Set Active Configuration
Select the Debug Configuration, instead of the release configuration.
Rebuild everything, and your symbols should be there.