0

I'm currently attempting to read decompilation in Ghidra. I've identified what I believe to be a "God object" that the library is uses to store state for the entire program. It's passed everywhere and has ~216 fields to it. It's far too large to manually figure out the structure of the struct (with my current ability), so I had Ghidra "Auto create structure" to define it.

The problem now is, I'm seeing weird behavior where the struct is used. For the initialization of the mutexes that it holds for example, prior to retyping, this is how the code looks in the decompilation window (__arg is a pointer to the newly calloced God-object):

undefined4 *god
. . .
pthread_mutex_init((pthread_mutex_t *)(god + 2),(pthread_mutexattr_t *)0x0);
pthread_mutex_init((pthread_mutex_t *)(god + 0x39),(pthread_mutexattr_t *)0x0);
pthread_mutex_init((pthread_mutex_t *)(god + 0x1c00f2),(pthread_mutexattr_t *)0x0);

Which is ugly, but mostly makes sense. I'm assuming god + 0x39 is a reference to a field (although, god + 0x1c00f2 is a rather huge field offset) . The problem is, when I retype the field to be of type God (the auto-generated type), it changes to this:

God *god;

pthread_mutex_init(&god->mutex1,(pthread_mutexattr_t *)0x0);
pthread_mutex_init(&god[1].mutex1,(pthread_mutexattr_t *)0x0);
pthread_mutex_init((pthread_mutex_t *)&god[0x8258].field_0x28,(pthread_mutexattr_t *)0x0);

My best guess as to this weird result is the struct was created improperly. If I go around to different functions where it's used and have Ghidra attempt to create a struct, the size of the struct changes every time (although, it's always around 210-230 fields).

Is there anything I can do to improve Ghidra's auto-creation of the struct? And am I correct that the array-access notation suggests an improper creation of a struct?

Improve this question
3
  • 1
    When I've seen this, it's always meant that the generated structure is too small. I'd recommend checking its size and seeing if it matches the size of memory allocated to create the object. If it's too small, increasing the size to be correct should fix your offsets
    – hairlessbear
    Jul 2, 2021 at 2:58
  • @hairlessbear Thank you. That makes sense. The index is larger than the size of the structure, so it assumes it's indexing into an array? If that's the case though, an index of 0x8258 suggests a massive structure.
    – Carcigenicate
    Jul 2, 2021 at 4:17
  • 1
    That would definitely be a massive structure, but in some settings, that's not uncommon. Structures that large generally have multiple large objects as members, although of course that's not a guarantee. Could also have one or more large arrays in it. And I think you're right about Ghidra thinking it's an array, but admittedly that's a guess; I've never investigated why the decompiler has this exact behavior, I just know how to fix it when I encounter it :)
    – hairlessbear
    Jul 2, 2021 at 6:14

0

Reset to default

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Browse other questions tagged or ask your own question.