NSO Loader: Index 0 out of bounds for length 0 about ghidra-switch-loader HOT 3 CLOSED

Ok so the binary I was loading was the exefs main of 0100000000001010 (LibAppletLns), from fw version 16.0.3.

I commented out these three lines and was able to get the binary loaded:

Presumably, there were 0 plt entries, but the code assumes that there's always at least one. I suppose a proper solution would be to only create the .plt section if there's 1 or more plt entries? But maybe there's something more subtle going on here, and the plt entries just aren't being detected properly?

from ghidra-switch-loader.

Usually if there are no plt entries it should already abort here:

The assumption that at least one entry exists after the while loop should probably still be removed. I'm curious what's happening here, I'll try to investigate that later (since that's a great excuse to actually learn more about the format).

from ghidra-switch-loader.

Okay actually I can't figure out much. I don't know enough about how ELF files are structured and how NSO files work.

The only hunch I have is that it might be related to the fact that the sdk binary is almost completely empty.
But I think the more interesting bit might be that the IDA loader assumes the same thing:
https://github.com/Atmosphere-NX/Atmosphere/blob/8b88351cb46afab3907e395f40733854fd8de0cf/utilities/nxo64.py#L420-L422

Since these sections in the Ghidra and the IDA plugin are almost identical, but neither of them are well documented, I'm not sure if this was done intentionally.
I'd also like to know what all these magic numbers mean, but I feel like that's currently still too hard for me to figure out.

from ghidra-switch-loader.