ELF Binaries and Relocation Entries
stffrdhrn.github.io
ELF Binaries and Relocation Entries
1–10 of 10 posts
Re: ELF Binaries and Relocation Entries
#2Curiously, OpenRISC support was just added[1] to the radare2 reverse engineering framework.
Re: ELF Binaries and Relocation Entries
#3Curiously, OpenRISC support was just added[1] to the radare2 reverse engineering framework. [1] https://github.com/radareorg/radare2/pull/15515
Thanks for pointing that out. As the OpenRISC maintainer of Linux/GCC etc I didn't even know about this effort. Let alone the tool.
I wrote this article with openrisc examples but it is meant to be easy to transfer to other architectures. In the next article I will use both x86 and openrisc examples.
Re: ELF Binaries and Relocation Entries
#4Curiously, OpenRISC support was just added[1] to the radare2 reverse engineering framework. [1] https://github.com/radareorg/radare2/pull/15515
Re Curiously, I'm guessing that may be useful for reverse engineering the proprietary firmware on the AR100 OpenRISC coprocessor present in Allwinner ARM SoCs:
Re: ELF Binaries and Relocation Entries
#5The author states the following under "Types of Relocations":
>"Addend The addend available in from the relocation entry discussed above"
I'm having trouble parsing this sentence. Should this be "the addend from the relocation entry discussed above" or 'in the form of"? I feel like this an important part of the article but there's a typo. Where and how is the "addend" obtained exactly? From the program counter?
Re: ELF Binaries and Relocation Entries
#6The author states the following under "Types of Relocations": >"Addend The addend available in from the relocation entry discussed above" I'm having trouble parsing this sentence. Should this be "the addend from the relocation entry discussed above" or 'in the form of"? I feel like this an important part of the article but there's a typo. Where and how is the "addend" obtained exactly? From the program counter?
Thanks for your feedback, it was a typo (I am pretty bad with those). I changed it to say "The addend from the relocation entry discussed above in the Listing Relocation Entries section".
Addend is actually usually 0 and important as a optimization for directly accessing indexed array values. It is not usually explained very well so I hope its clear now.
If there is anything else that could use clarification I am happy to update the article or answer questions.
Re: ELF Binaries and Relocation Entries
#7The author states the following under "Types of Relocations": >"Addend The addend available in from the relocation entry discussed above" I'm having trouble parsing this sentence. Should this be "the addend from the relocation entry discussed above" or 'in the form of"? I feel like this an important part of the article but there's a typo. Where and how is the "addend" obtained exactly? From the program counter?
Thanks for your feedback, it was a typo (I am pretty bad with those). I changed it to say "The addend from the relocation entry discussed above in the Listing Relocation Entries section". Addend is actually usually 0 and important as a optimization for directly accessing indexed array values. It is not usually explained very well so I hope its clear now. If there is anything else that could use clarification I am hap…
Thank you. Yes now I think I understand. I had a follow up question. You state:
">As we saw above, a simple program resulted in 2 different relocation entries just to compose the address of 1 variable. We saw:
R_OR1K_AHI16 R_OR1K_LO_16_IN_INSN"
Can you say why two relocations are needed? I understand the address of x is not known until link time however what would the second relocation be for?
Also is there a good reference for deciphering the relocation names?
Re: ELF Binaries and Relocation Entries
#8Earlier quoted context omitted.
Thanks for your feedback, it was a typo (I am pretty bad with those). I changed it to say "The addend from the relocation entry discussed above in the Listing Relocation Entries section". Addend is actually usually 0 and important as a optimization for directly accessing indexed array values. It is not usually explained very well so I hope its clear now. If there is anything else that could use clarification I am hap…
Thank you. Yes now I think I understand. I had a follow up question. You state: ">As we saw above, a simple program resulted in 2 different relocation entries just to compose the address of 1 variable. We saw: R_OR1K_AHI16 R_OR1K_LO_16_IN_INSN" Can you say why two relocations are needed? I understand the address of x is not known until link time however what would the second relocation be for? Also is there a good re…
Hello, There are 2 relocations because the series of instructions that needs to create a 32-bit memory address requires HI16 and LO_16 relocations. The 2 relocations sure 16-bit high and low bitfields to compose the 32-bit address.
For a full list of relocation types see the list in the last few links of the article. Note, the OpenRISC relocations are not all well documented.
Re: ELF Binaries and Relocation Entries
#9Earlier quoted context omitted.
Thank you. Yes now I think I understand. I had a follow up question. You state: ">As we saw above, a simple program resulted in 2 different relocation entries just to compose the address of 1 variable. We saw: R_OR1K_AHI16 R_OR1K_LO_16_IN_INSN" Can you say why two relocations are needed? I understand the address of x is not known until link time however what would the second relocation be for? Also is there a good re…
Hello, There are 2 relocations because the series of instructions that needs to create a 32-bit memory address requires HI16 and LO_16 relocations. The 2 relocations sure 16-bit high and low bitfields to compose the 32-bit address. For a full list of relocation types see the list in the last few links of the article. Note, the OpenRISC relocations are not all well documented.
I see, the relocations happen in pairs then - lower order and high order bits. Is that correct?
Re: ELF Binaries and Relocation Entries
#10Earlier quoted context omitted.
Hello, There are 2 relocations because the series of instructions that needs to create a 32-bit memory address requires HI16 and LO_16 relocations. The 2 relocations sure 16-bit high and low bitfields to compose the 32-bit address. For a full list of relocation types see the list in the last few links of the article. Note, the OpenRISC relocations are not all well documented.
I see, the relocations happen in pairs then - lower order and high order bits. Is that correct?
Yes, for OpenRISC as there are no instructions with a 32-bit immediate so we use 2 high and low order relocations. However, on machines like x86 they have variable width instructions and support 32-bit relocations, they can get by with a single relocation entry.