disassembly

What does the "SHORT" mean in this code? JE SHORT 00013FB8 Short jumps (and near calls) are jumps whos target is in the same module(they are intramodular, however it is possible to get intermodular variants from certain hacks), they are most commonly up to 127 bytes of relative displacement(they change the flow of execution forward or backward from the address of the instruction), however there are 16bit variants offering 32k bytes. You don't really need to worry about it much, its really superfluos information, but the intel developer manuals(volumes 2a and 2b, specifically 2a) will cover the

How can one determine which C or C++ compiler was used to build a particular Windows executable or DLL? Some compilers leave behind version strings in the final executable, but this seems to be rarer on Windows than on Linux. Specifically, I'm interested in distinguishing between Visual C++ and the various MinGW compilers (usually fairly easy from the function signatures), and then between Visual C++ versions (6, 2002/2003, 2005, 2008; more difficult to do). Is there a tool out there that can make the distinction in a semi-reliable way? One source of a hint to distinguish among VC versions is

I've compiled the following using Visual Studio C++ 2008 SP1, x64 C++ compiler: I'm curious, why did compiler add those nop instructions after those call s? PS1. I would understand that the 2nd and 3rd nop s would be to align the code on a 4 byte margin, but the 1st nop breaks that assumption. PS2. The C++ code that was compiled had no loops or special optimization stuff in it: CTestDlg::CTestDlg(CWnd* pParent /*=NULL*/) : CDialog(CTestDlg::IDD, pParent) { m_hIcon = AfxGetApp()->LoadIcon(IDR_MAINFRAME); //This makes no sense. I used it to set a debugger breakpoint ::GdiFlush(); srand(:

Can anyone let me know how we are going to output all the subroutine's graphs in batch mode suing IDC . i.e. I have 447 subroutine's and wanna be output them all and I would like to make sure I first retrieve all the routines address automatically, cuz by knowing the address I can simply use GenFuncCall . P.S: Is this the only cfg that I can get from Ida Pro given a binary dis-assembled file? If you just want the address of all known functions in the IDB, you could use something like this using IDAPython (just an example): def main(): for count, func_ea in enumerate(Functions()): if func_ea ==

Have found a function address in a DLL. Have no source code for this DLL, not mine. This DLL is not really changed frequently, but when changed, it is a problem for me to find it by disassembling. Saw some notes in web about making it signature and then find it by this saved signature. Can you, please, give some ideas or working example on how to implement this? You can achieve this by code signature scanning, which is something I have done in the past. The concept mainly works by relying on the fact that functions often do not change too much between updates, but simply relocate because they

EDIT I tested release in 32 bit, and the code was compact. Therefore the below is a 64 bit issue. I'm using VS 2012 RC. Debug is 32 bit, and Release is 64 bit. Below is the debug then release disassembly of a line of code: crc = (crc >> 8) ^ crcTable[((val & 0x0000ff00) >> 8) ^ crc & 0xff]; 0000006f mov eax,dword ptr [ebp-40h] 00000072 shr eax,8 00000075 mov edx,dword ptr [ebp-3Ch] 00000078 mov ecx,0FF00h 0000007d and edx,ecx 0000007f shr edx,8 00000082 mov ecx,dword ptr [ebp-40h] 00000085 mov ebx,0FFh 0000008a and ecx,ebx 0000008c xor edx,ecx 0000008e mov ecx,dword ptr ds:[03387F38h] 00000094