Closed DavidBuchanan314 closed 10 months ago
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?
Usually if there are no plt entries it should already abort here: https://github.com/Adubbz/Ghidra-Switch-Loader/blob/60e57360238d14c84cdd0c72fd70db59a65c3ecd/src/main/java/adubbz/nx/loader/common/NXProgramBuilder.java#L211-L215
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).
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.
Sorry for the vagueness, I'm down a rabbithole rn so I'll circle back and provide more details later