New answers tagged ida
0
The best way to debug this in my opinion is to use WinDbg from Windows SDK or WinDbg Preview from Windows Store. In Windows it is not possible to attach two debuggers to the same process. WinDbg supports easily debugging .NET and native processes.
To access .NET functionality you can run commands:
.loadby sos clr
More details of the .NET extensions here
...
4
When I assembled the code, the offending instruction was:
0x6c 40 ff d1 call rcx
You will need to use Change Stack Pointer command in IDA to fix this in disassembly. As per IDA documentation:
This command allows you to specify how the stack pointer (SP) is modified by the current instruction.
You cannot use this command if ...
0
There is no easy way to do that.
Several approaches:
Build your own libc for ARM and then do a compare using IDA FLIRT, bindiff, diaphora or similar, or just use is as a reference to see how those function should look like.
Look for the most referenced functions, a good chance that some of them will be libc. After finding some, look at the neighbor ...
0
Keypatch is a plugin for IDA that uses keystone to assemble instructions for patching. It supports ARM. Once you've patched the IDB you can go to Edit -> Patch Program -> Apply Patches to Input File
2
You need to change the Actions from "Trace" to "Break" When the condition is true the action will execute.
0
I did not have the latest release of WinDbg but while debugging a 32-bit EXE, adding the WinDbgx64 directory to the PATH environment solved this problem.
Works as well with remote Windbg.
2
I would assemble the code and then analyze it using emulation.
Example assembly taken from the link:
mov rax, QWORD PTR [rbp-16] ; Move i (=9) to RAX
movabs rdx, -3689348814741910323 ; Move some magic number to RDX (?)
mul rdx ; Multiply 9 by magic number
mov rax, rdx ; Take only the upper 64 bits of ...
0
To get complete dark theme you must use IDASkins and Ida Consonance
If you're using IDA 6.5 - > 6.9 you will need IDASkins 1.4.1
For all versions of IDA you can use the same ida-consonance version for the code blocks and highlighting.
Install IDASkins first:
Copy IDASkins.p64 & IDASkins.plw into the IDA plugins folder
Open IDA Pro
Edit -> Plugins -> ...
0
In case it is running into this error Received a SIGTRAP: Trace/breakpoint trap even though there are no breakpoints in the program, check the power of Hardware Debugger e.g. J-Link.
In my case, J-Link was powered on but the port wasn't delivering enough power. Changing the port to high-power one fixed this.
0
Those are indirect jumps caused by the compiler or/and the linker in order to locate an external function.
According to how the function is defined, both the linker and the compiler may end up in emitting a stub, thus making the call stack insanely deep during the analysis.
As stated in the comments, this SO answer Indirect jumps for DLL function calls ...
1
Depending on the original source, the class definition could be entirely in the header file. Class definitions are no longer useful in object files as the compiler already knows how fields and methods are laid out.
You have to guess the original definition. Keep in mind that you already have guessed a lot when reverting via hex-rey as C++ allows ...
2
Keypatch is a plugin for IDA that uses keystone to assemble instructions for patching. It works much better than IDA's old built-in assembler, and it should be able to handle 64-bit operands.
0
You'll find a commented analysis of the assembly code with pseudo-code. What's obvious is that this is 'crappy' compiler generated code used to align local variables to a 4-bytes boundary. Most optimizing compilers avoid using the stack and use registers when optimization flags are set (i.e. gcc -O2, ...).
lea eax, [esp+12h]
mov ecx, 1Ah
...
-1
I guess newByte[two.length + 1] = 1; look like iterate some value in variable two
1
You were almost there.
But they have to point to exactly the same address so this "cmp" instruction that comes after it will succeed
This statement is incorrect. Not addresses are being compared, but the data at each. The code, starting from .text:00C21094 compares 13 subsequent bytes at byte_C23018 with their counterparts at loc_C23024.
So, to get the ...
1
I don't know IDA debugger very well, but I can tell how it can be done in GDB.
First of all, I would suggest disabling ASLR (echo 0 | sudo tee /proc/sys/kernel/randomize_va_space) to prevent address space randomization. If the string you are looking for is at the same location each time, then simply setting watchpoint at that location will do the job.
If ...
1
Since you code seems to be un-optimized, you have to manually follow the memory access manually. In your case, you have to apply this structure offset (T) at 0x000000000040111C (rax), 0x0000000000401122 (rax) and 0x000000000040112C (rdx). AFAIK, there's no easy way to define a local variable as a pointer to a structure and automatically show reference to the ...
0
The answer of @igor says about algorithm failures of IDA. Beside, I think you can use a function which is not type-able in the type system of the decompilation target language of IDA (I believe it's a subset of C), e.g.
int foo(void *f, int i) {
return ((int (*)(void*, int))(f))(foo, i);
}
clang -c test.c
then IDA decompilers gives something likes
...
1
You can check "graceful failures" for some common problems that can prevent decompilation and try to induce them deliberately. However, most of them can be worked around with a bit of effort so don’t expect them to stop a motivated person.
1
IDA results look pretty good. I believe that the signature of main comes from any kind of FLIRT or other function recognitions - It detects that the function is main, and therefore gives it the default main signature. it looks like foo disassembled well. You can configure yourself the signature by pressing y on the function call. You must understand that the ...
0
check if jump destination is a continuous area behind the function, if true, alt+p, adjust function range.
if not, first undefine target area, then use IDA-built-in function "append_func_tail" to add that chunk to owner function. here is the IDA-reference doc link
one jump out done. if there is too many, then write a script to automate it.
2
Although you can use several tools, I would suggest you to use GDB if possible, since it has a built-in feature of breaking at each function call.
Now, what you can do, is to run your program two times - first, without pressing buttons, and second, with doing so. I'm attatching a python script that will print each function call with a number of calls to it, ...
1
In addition to Nirlzr's answer, you can go to the function Imports window in the debugger (IDA, OllyDbg and x64Dbg for example), and set a breakpoint on the functions you are curious about. Then, simply run the program and the debugger will stop the execution of the program at the time each function is called.
For example, if you want to see when a program ...
Top 50 recent answers are included
