2

I have an object named ComputeService::RPC that is being used as input in a function inside a binary file:

__int64 __fastcall ComputeService::Rpc::GetClientProcessId(ComputeService::Rpc *this)  
pc *this)
{
  unsigned int v1; // ebx
  int RpcCallAttributes[32]; // [rsp+20h] [rbp-98h] BYREF

  v1 = -1;
  memset_0(RpcCallAttributes, 0, 0x78ui64);
  RpcCallAttributes[1] = 16;
  RpcCallAttributes[0] = 3;
  if ( !RpcServerInqCallAttributesW(0i64, RpcCallAttributes) )
    return (unsigned int)RpcCallAttributes[16];
  return v1;
}

* I used the Pseudocode in IDA to extract this information.

I went to the window of the "Local Types" and it shows that it is a struct but that's it.
enter image description here

Is there a way to check what are the fields inside this struct?

3

IDA knew that there was a struct named ComputeService::RPC due to a mangled name containing a reference to it -- for example, a mangled name for the function shown in your question. However, IDA did not have a struct declaration for it, so it created an empty struct -- you can tell this because the Description field for that entry simply says struct. If IDA had had access to a struct declaration, you would see it in your second screenshot.

So the short answer is: no, it does not appear that you have access to the struct declaration (e.g. from a PDB file with full type information), otherwise IDA would have already created it. You're going to have to reconstruct it yourself. However, you might also want to see Ghidra 10.0's new features for exactly this type of situation:

Scripting. Added prototype RecoverClassesFromRTTIScript and that uses RTTI information to enhance Ghidra's knowledge of class hierarchy, class member function types (constructors, destructors, deleting destructors, clones) and class member data. The script will label and put member functions into correct class namespace and apply new class structures created either using PDB information, if available, or Decompiler pcode information. (GP-339)

2

Is there a way to check what are the fields inside this struct?

The old fashion way. Follow that pointer around through the assembly and see what offsets are used and how. If you can find where it's created, you can know it's total size. If you can debug the program live you can set watch points and see what data actually gets put into each offset. The size of the 'objects' manipulated at each offset and how they're used can clue you in to what they are. If you're really lucky some will get passed to system calls, OS APIs, or other well documented functions so you can just look up the expected arguments.

If you're going to do that, you'll need to refresh structure padding/packing. You might be able to locate the RTTI if its a virtual class or ever used as part of an exception which would give you more hints.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.