CODEWITHSUNDEEP
assemblycomx86
the_endian
the_endian

Reputation: 2525

How does this x86 mov work in reverse?

I am reading the book Practical Malware Analysis and in it appears this example code:

00401022 call ds:CoCreateInstance
00401028 mov eax, [esp+24h+ppv]

The author then states:

The COM object returned will be stored on the stack in a variable that IDA Pro has labeled ppv, as shown.

My question is, why is this? Since we do a mov eax, [esp+24h+ppv], wouldn't this be moving the data inside of [esp+24h+ppv] into eax and overwriting the return value rather than storing the return value in the variable? I thought in Intel format, mov operand1, operand 2 always placed the 2nd operand into the first.

Note: It's page 558 if anyone happens to have the book, by the way.

Upvotes: 0

Views: 879

Answers (2)

zx485
zx485

Reputation: 29042

I have very little experience with COM, but a quick glance at MSDNs CoCreateInstance function reveals this signature

HRESULT CoCreateInstance(
  _In_  REFCLSID  rclsid,
  _In_  LPUNKNOWN pUnkOuter,
  _In_  DWORD     dwClsContext,
  _In_  REFIID    riid,
  _Out_ LPVOID    *ppv
);

So CoCreateInstance does return an out parameter called ppv which seems to be, conveniently, extracted by IDA Pro as well.

The ppv out value is defined as

Address of pointer variable that receives the interface pointer requested in riid. Upon successful return, *ppv contains the requested interface pointer. Upon failure, *ppv contains NULL.

The return value supposedly returned in EAX is merely one of these five values:

  • S_OK: An instance of the specified object class was successfully created.
  • REGDB_E_CLASSNOTREG: A specified class is not registered in the registration database. Also can indicate that the type of server you requested in the CLSCTX enumeration is not registered or the values for the server types in the registry are corrupt.
  • CLASS_E_NOAGGREGATION: This class cannot be created as part of an aggregate.
  • E_NOINTERFACE: The specified class does not implement the requested interface, or the controlling IUnknown does not expose the requested interface.
  • E_POINTER: The ppv parameter is NULL.

The returned ppv value is the real pointer to the COM object which is then accessed with the

mov eax, [esp+24h+ppv]

instruction. So the return value which contains the possible error code (anything other than S_OK) is immediately overwritten (So it it assumed that the COM call succeeds).

DWORD PTR [esp+24h+ppv] (somehow) points to the base address of the COM-object, loading it into EAX.

But I cannot denote the addressing mode. Maybe it is a special kind of syntax display of IDA Pro.

From there, this pointer in EAX is used to access the COM-object and - one step further - its methods like described in the comments.

This CodeProject article may give you further insight.

Upvotes: 2

TypeIA
TypeIA

Reputation: 17258

It's clear from the author's description of the code that those operands are in AT&T order (source first, then destination). Did the author earlier specify that the code was written with Intel ordering or is that just an assumption on your part? It is (unfortunately and confusingly) common for x86 assembly to be written using both styles, as discussed in another question:

MOV src dest (or) MOV dest src?

Upvotes: 0

Related Questions