disassembly

问题 I'm new to MIPS and am trying to understand the disassembly of a function. (EDIT: it is dynamically linked to /lib/ld-uClib.so.0 and uses some usual libc functions, so I assume it was written in C using the uClibc toolchain, and should therefore have that calling procedure and stack frame, etc.). At the start of the function it does 00400824 <practice_crackme>: 400824: 3c1c0fc0 lui gp,0xfc0 ; ??? 400828: 279c673c addiu gp,gp,26428 ; ??? 40082c: 0399e021 addu gp,gp,t9 ; ??? 400830: 27bd8020

问题 I have an Interop DLL RCW.Xyz.dll but I can't find the corresponding DLL. Because the name doesn't follow the default naming scheme Interop.Xyz.dll my guess is that the interop assembly was simply renamed. (Even if the DLL is generated by Visual Studio with a default name, if the DLL has spaces in its name, the spaces will get lost, making it hard to find the source DLL again) How can I find out the COM DLL name behind the interop assembly? I assume I need to use disassembly tools. Preferably

问题 Recently I have gotten interested into dis-assembling C code (very simple C code) and followed a tutorial that used Borland C++ Compiler v 5.5 (compiles C code just fine) and everything worked. Then I decided to try my own c code and compiled them in Dev C++ (which uses gcc). Upon opening it in IDA Pro I got a surprise, the asm of gcc was really different compared to Borland's. I expected some difference but the C code was EXTREMELY simple, so is it just that gcc doesn't optimize as much or

问题 I compile following C program on lubuntu 12.10 with anjuta int main() { return 0; } the file name is foobar then I open up terminal and write command ndisasm foobar -b 32 1>asm.txt (disassemble foobar with 32 bit instruction option and save disassembled result to asm.txt) I open up asm.txt there are many 0x0000 and miss-understandable code. the instruction jg 0x47(0x7F45) on 0x00000000 and dec esp(0x4C) on 0x00000002 seems ELF file format signature. (because the hex code 0x454c46 is 'ELF' in

问题 Disassembling printf doesn't give much info: (gdb) disas printf Dump of assembler code for function printf: 0x00401b38 <printf+0>: jmp *0x405130 0x00401b3e <printf+6>: nop 0x00401b3f <printf+7>: nop End of assembler dump. (gdb) disas 0x405130 Dump of assembler code for function _imp__printf: 0x00405130 <_imp__printf+0>: je 0x405184 <_imp__vfprintf+76> 0x00405132 <_imp__printf+2>: add %al,(%eax) How is it implemented under the hood? Why disassembling doesn't help? What does * mean before

问题 During one of my (FWIW, ARM) debugging sessions I noticed the source-interleaved disassembly output from GDB and objdump -S differ in an interesting way: objdump seems hop through individual/group of instructions and display the source line from which those instructions were generated (instruction order). GDB disassembly, on the other hand, seems to hop through source lines, and lists all assembly instructions generated from that source line (source order). For an -O0 code, output from both

问题 I'm trying to analyze and reverse a Objective-C program I have. I made few modifications to the executable by changing some opcodes by hand. When I test the modified software, however, I get Killed: 9 That's fine, I think I touched something I should not. I launched then gdb myprogram in order to analyze the error. Here something (strange to me) happened: if I do not put any breakpoint the program receives SIGKILL, while if I try to put a breakpoint few lines before the one in which I receive

问题 I've been looking into the Software Developer's Manual of the x86 architecture trying to brush my reverse engineering skills. I know that the architecture is complex and backwards compatible with previous generations. With newer generations some of the older documentation parts get left out. But one of the disturbing explanations and misinterpretations were instructions similar to this one: 80 /2 ib So instructions based on the following 80 OpCode would be followed by a MOD/RM/REG byte. One

问题 I've been using the dis module to observe CPython bytecode. But lately, I've noticed some inconvenient behavior of dis.dis() . Take this example for instance: I first define a function multiplier with a nested function inside of it inner : >>> def multiplier(n): def inner(multiplicand): return multiplicand * n return inner >>> I then use dis.dis() to disassemble it: >>> from dis import dis >>> dis(multiplier) 2 0 LOAD_CLOSURE 0 (n) 3 BUILD_TUPLE 1 6 LOAD_CONST 1 (<code object inner at

问题 In Python you have the ability to view the compiled bytecode of a user-defined function using dis . Is there a builtin equivalent to this for Lua? It would really useful! 回答1: The luac utility that comes with standard lua can create an assembly listing from Lua source using its -l option. For example, compiling from source on stdin : C:...> echo a=b | luac -l - main (3 instructions, 12 bytes at 00334C30) 0+ params, 2 slots, 0 upvalues, 0 locals, 2 constants, 0 functions 1 [1] GETGLOBAL 0 -2 ;