New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MIPS PLT Offset off by one entry #4776
Comments
@elbee-cyber could you please share a binary so that we can better reproduce it? |
The following are some MIPS binaries from a device I was doing research on |
A quick look doesn't show any sections with "plt" in the name either if that's required?
|
This was previously fixed in #3267 and I am definitely seeing an issue on 3.6.4671-dev with the supplied files: This is from This has also been reported by an Enterprise customer on MIPS64 binaries. |
We've had a discussion internally about this and come to a few conclusions. First, yup, there's still a bug with the improved recognition that we need to fix. Ironically, for this particular binary (not sure about others) though you shouldn't ever need these to be fixed since the PLT isn't used at all. Instead, the cross-references (which are presumably what matters here) are all going to be directly off the GOT entry itself. The bigger issue is probably that when you want to find the cross-references for an import you should be navigating to the GOT entry. This means if you search, say, "memcpy" in the sidebar, you'd want to hit the second entry, not the first one. Likewise, if you use "g" to navigate to the right function, you'd want to navigate to the one in the .got section (which is shown in the drop-down). We're discussing some ways we can improve the default behavior so you're less likely to run into this in the first place, but let me know if either of those work for you! |
Oh I've not had issues following cross references. (I can just click an imported symbol as it appears in the IL pane and follow the references) It's not too impactful of a bug, I just thought I'd report it anyway. It only makes following cross references via the plt a bit wonkey which is what my and I'm sure some other people's brains default to when they want to just follow some imported symbol off rip via the plt. |
That makes sense, just making sure it wasn't blocking anything. |
Note dump before I forget stuff: The enhancements that corrected the the previous issue were activated here, but the type of our Since it's not in a section, it doesn't adopt the
I learned it is not necessary to have sections at all. You can just have program headers (segments) instruct the loader to map the necessary bits of the file to memory, and then you can communicate the location of important parts via the program header types and their contents. For example, the location of the GOT is communicated with a program header with type When the GOT is specified this way, Binja synthesizes the ".got_recovered_XXX" section. Note the address in |
Minor correction: view-elf was calculating recovered GOT section by collecting all relocations and inferring a sort of bounding box around them. This would miss the very first pointer in the GOT, where The area shown in the screenshot by fuzyll now looks like: Fixed in: Vector35/view-elf@5823606 and https://github.com/Vector35/binaryninja/commit/ca11e60e10d878a86a5cb6248a7d043fca580e82 |
There's still a problem with typing there - those RTL_Resolve calls should just be resolved to extern calls, otherwise every external function takes 0 parameters and doesn't return. RTL_Resolve is part of the loading process and provided by the loader, it's not actually runtime-dynamic even though it looks that way. If I remember correctly the symbol index there is the index into the dynamic symbols table, which you could use to statically resolve which extern it should call. |
For mipsel binaries there seems to be an issue with loading only the plt (the rest of the binary seems fine) where plt entries resolve by the entry adjacent.
Tested on 3.5.4526 Personal and 3.6.4665-dev
The text was updated successfully, but these errors were encountered: