This is probably a program compiled with "Whole Program Optimization" or "Link-time code generation". From MSDN:
When /LTCG is used to link modules compiled with /Og, /O1, /O2, or
/Ox, the following optimizations are performed:
Interprocedural register allocation (64-bit operating systems only)
Custom calling ...
My guess is that the function signature should be something like:
int __usercall Call_HTTP@<eax>(int x, int y, void* http_object@<edi>);
__usercall means the calling convention for the function is not a standard one (like stdcall, cdecl, etc.) as the function passes two arguments on stack and one in edi.
@<eax> : function returns a value ...
If the compiler can prove that it has all call sites for a given function under its control then it can discard conventions and arrange things around to its liking. Microsoft's C/C++ compiler has been doing this for decades in connection with link-time code generation and profile-guided optimisation, especially internal copies of the compiler like the one ...
Your faux function is not fixing up the stack on the epilog of the function. It should have
at the end by the calling convention.
If you look at the original function it fixes up the stack correctly.
Let's say the stack pointer had the value of 1000h coming into the function (after CS:IP is already pushed on the stack for the far ...
The only idea I have is to compare the dumps. The places that are same in all dumps are code or read only data. The places that are changing from dump to dump are either stack or section like .bss. After finding places that are not changing I'd try to disassemble these places in order to divide between code and data.
I think that the places with the code ...
With global optimisation (link-time code generation) the compiler is free to ignore the declared calling convention for all functions that aren't externally visible - that is, neither exported nor otherwise pinned by having their addresses taken and passed to external code.
This can make the resulting binaries difficult to analyse since even the well-known ...
The "problem" with your example is that the structure is too small (four bytes), so it fits in a register and is not actually passed on the stack. From the Itanium C++ ABI (used by most GCC implementations):
A type is considered non-trivial for the purposes of calls if:
it has a non-trivial copy constructor, move constructor, or destructor, or
So, your question is mainly about this part of the code (if I do not care about the second call which is similar anyway):
mov EDI, .L.urandom
mov ESI, 8
In fact, this is perfectly okay to go through ESI and EDI as it is done here, because the value that are transfered are 32 bits values... and, anyway, in amd64, when manipulating 32 bits ...
We can see from this list that IA-32's Delphi/Free Pascal calling convention is the register calling convention. My guess is you're dealing with a binary that's the result of something like this: How to call a function using Delphi's register calling conventions from Visual C++?
To partially quote the top-voted answer:
Delphi's register calling ...
The decompiler decided that ecx is used by sub_431C00 because of push ecx at the beginning of the function which fills the stack slot later used by the variable phkResult, so it may look as if the initial value of phkResult is taken from ecx:
.text:00431C00 push ecx
.text:00431C01 lea eax, [esp+4+phkResult]
Welcome to RE.SE!
How to understand what the problem is?
When the function is decompiled, IDA checks for its dependencies via dataflow analysis. Basically, it asks which values have to be defined in order to make this function work.
When it encounters the first line of the function (push ecx) IDA noticed that the value of ecx is used before it was ...
Yep, I think I've seen a similar case before. It happens very rarely, but because you can do some stunts at the C preprocessor level as well as at the linker level, this happens to work.
In this case I looked it up in the 3790.1830 DDK (Windows 2003 Server) and several newer WDKs and SDKs.
Windows 2000/XP target (3790.1830/inc/w2k/winbase.h and 3790.1830/...
x8 pointer to where to write the return value if >128 bits, otherwise scratch register
So it seems x8 is used to pass an address at which the return value will land if it's too big, rather than the return value directly, hence indirect I suppose.
I couldn't find official ...
Calling conventions are compiler specific, meaning they are specified by the compiler manufacturer like Microsoft, and not by the 8086 manufacturer like Intel. In case you program in Assembler or build your own compiler, you can apply your own method to pass function parameters.
Nevertheless, in the C/C++ world, there are mainly the __cdecl and the __stdcall ...
First make sure you are using correct calling convention, in 64-bit Windows most APIs expect parameters via registers not push.
An example of calling convention for 64-bit Windows:
lea r9d, uType ; uType
lea r8, Caption ; Caption
lea rdx, Text ; Text
mov rcx, hWnd ; hWnd
This is covered in more ...
I have found the solution to this problem, which is quite simple. I got confused with the hooked function signature and the __fastcall trick to get a non member function to work with the __thiscall convention. In my initial post, the two first arguments in the function signatures are the one passed using ecx and edx, but I forgot about one of the pointer ...
This is not a standard function but a compiler helper, used by the compiler to perform some necessary housekeeping (allocate extra stack space) so it doesn’t have to follow the ABI for “normal” functions.
Because it is called in the prolog of the parent function while the user code has not started executing yet, special care needs to be taken.
EAX use ...
Seems like it has 4 arguments, and they are passed through stack, yet the more lines of disassembly above E42D6A needed to make sure. Are those mov and lea instruction confusing you? If you've expected to have 4 push instruction in a row, then let me disappoint you: compiler can insert as many instructions as it likes between the push instructions. And let ...
I have been in touch with IDA support and unfortunately, right now, there does not seem to be a good way to do this. IDA assumes in many cases that the return value of a function must be stored in a register. This is also the reason for the crash when trying to overrule this inherent assumption with scattered arguments.
Most likely it's just LTCG/LTO, especially if the function in question is only never called externally. Using it can result in the following:
Interprocedural register allocation (64-bit operating systems only)
Custom calling convention (x86 only)
Small TLS displacement (x86 only)
Stack double alignment (x86 only)
Improved memory ...
Many non-Microsoft compilers pass the first argument in EAX.
The three lexically first (leftmost) arguments are passed in EAX, EDX, and ECX...
Evaluating arguments from left to right, it passes three arguments via EAX, EDX, ECX.