You can either typedef it like this:
// typedef <return-type>(__thiscall* <type-name>)(<ecx>, <stack-1>, <stack-2>);
typedef int(__thiscall* tSomeFunc)(int thisPtr, int arg1, int arg2);
tSomeFunc func = (tSomeFunc) 0xBAADC0DE;
// this is how you call it
func(/* this */ 0x123, /* arg1 */ 1, /* arg2 */ arg2);
Or directly call ...
How come the jz instruction jump to a non-instruction (0x400AC9)?
It does not. There is no such thing as "an instruction". Jumps do not jump to instructions, they jump to addresses.
How come the call invokes a non-existing address?
It does not. If you check what the code actually does, you will find this call will never be executed.
Here is the ...
Cross References (or simply XREFs) is a feature of disassemblers to show you where certain functions and objects were called from or which functions and objects are used by a specific function. We can simplify it by relate to it as XREF-To and XREF-From. The referenced can be either Data or Code.
XREFs are a valuable resource when we want to figure out ...
Note: You'll probably get a better answer on stackoverflow, as your question is more about creating software than about reversing it.
First, you'll want to split your text file into blocks. You can do that looking for the ============= S U B R O U T I N E ============ comments that IDA emits, or checking the sub_XXXX proc [near|far] and sub_XXXX endp ...
If you run across an API call that you're unfamiliar with, check the MSDN page. Parameter 2 is "The function or variable name, or the function's ordinal value." Looking at your offset only one of those things is a function name, WNetEnumCachedPasswords.
You can verify this as the comment in your post said, by counting 12 (0xc) bytes from aPstorec_dllwne. db ...
The leading ? identifies a C++ name mangled symbol. Two ?? signify operators, constructors, destructors, constant strings, and various compiler generator functions. For example ??0 is a constructor. This site has a good breakdown of the mangling pieces used by MSVC.
A leading underscore _ can either be due to the calling convention or due to the CRT/...
opcode for call $+5 is e8 00000000 so it calls the next instruction
opcode for jmp $+5 is e9 00000000 so it jumps to the next insturction
76E95FE0 E8 00000000 CALL 76E95FE5 ; <ntdll.call here>
76E95FE5 <ntdll.call here> 00 DB 00
76E95FE6 E9 00000000 JMP 76E95FEB ...
These are so-called "mangled" or "decorated" names. You can use undname utility from Visual Stduio to demangle them:
void * __cdecl operator new(unsigned int)
public: __thiscall CBLObject::CAdviseObject::CAdviseObject(struct IDispatch *,cl
ass CBLInstance *)
protected: void __thiscall CBLObject::StartAutoReconnect(unsigned int,int)
For more info: Wikipedia,...
it seems the "code" you're trying to disassemble is not actually code but just the table of offsets for the indirect jump (likely a switch implementation). Try interpreting it as a list of 4-byte flat addresses. E.g. :
.text:667013BC 03C cmp ebx, 7 ; SWITCH ; switch 8 cases
.text:667013BF 03C ja loc_667015AB ; SWITCH ...
x-refs is just a static cross-reference in the binary that can be identified during static-analysis.
So if you main call funcA you could tell that by looking at x-refs on funcA. But you can't be sure that it will be in fact called during runtime - there might be some conditional jumps that only call funcA in a certain state.
Stacktrace presents the actual ...
It appears you've already guessed what the actual issue is - your call instruction is using direct addressing and not relative addressing. This means that when a DLL changes it's location between executions you're still trying to execute the same absolute value, resulting in different types of errors depending on the content of the actual content in that ...
From the provided disassembly, mana is a structure and you need to understand this structure and it's members.
The instruction below:
.text:0807EC41 call dword ptr [mana+0Ch]
It is invoking the function with pointer stored at offset 0xC in the structure, mana.
Where is the structure mana derived from?
This can also be inferred from ...
Assuming you're using a software breakpoint (int 3), you have a few alternative options:
Use a hardware breakpoint instead
Use an OllyDbg-style memory breakpoint instead
Hook the target function by overwriting the beginning of the function with a jump/call to an injected tracing function
Find the code that's causing the application to crash (the code that's ...