[question] Undefined function when I use Ghidra to dissemble a shared object

[Montana]

I'm trying to dissemble a shared object file and I found something strange:

Following, FUN_004d9f38(void) lead me to this:

I'm trying to understand why is .so calling undefined __cdecl. I'm aware of using a shared object may cause confusion on occasion in gcc but for me the advantage of using a shared object, over a library is that they are linked during the runtime i.e., after creation of your .o file -o option in gcc.

I'm aware ghidra uses to to mark locations where the type is not known/defined yet. I've tried changing the datatype in the list to e.g. qword, I still get a precursor of undefined.

Seen a similar issue, I have many ideas of what's happening but can't be certain any of them. Some of the information I've changed but still the same premises.

Thanks, Montana Mendy.

[Wall-AF]

The reason could be that the function at 004d9f38 hasn't yet been disassembled. For disassembly (by pressing the key D at that location) and go from there.

[Montana]

Good call @Wall-AF,

That was partially the answer, the other part is for frame N, the payload data starts at sizeof(CGFHeader) + cgf_header.frame_count*sizeof(FrameMeta) + frame_meta[N].payload_offset (i.e. at the corresponding payload_offset, based immediately after the metadata structs).

I then started dumping frames to 0.png, 1.png, etc in subdirectory (which goes to my Enum question I had in another thread).

I don't think these values are compressed, there's a lot of redundancy in the data which compression would obviously destroy.

[ghidra1]

There is insufficient information in your description to make heads-or-tails or the issue. If you could supply a sample binary we may be able to understand the issue better.