search

NationalSecurityAgency / ghidra

Ghidra is a software reverse engineering (SRE) framework
https://www.nsa.gov/ghidra
Apache License 2.0
51.82k stars 5.89k forks source link

Overriding RelocationHandler and ElfExtension #1251

Closed astrelsky closed 4 years ago

astrelsky commented 5 years ago

I seem to be having a difficult time overriding these two features. I am directly extending MIPS_ElfRelocationHandler and MIPS_ElfExtension as what I'm dealing with is a MIPS processor but it just has some unusual differences and some things need to be handled differently. The problem is since this is still a MIPS processor, the respective getHandler methods seem to pick up the overriding classes only when it feels like it and returns the default MIPS ones the rest of the time. This is a problem because I don't get the required behavior every single time.

Is there something I can do to ensure that the overriding classes get picked everytime instead of the handler search stopping when the default MIPS handler is found?

It appears this is occurring because the ClassSearcher is returning an unsorted list. Since it is unsorted sometimes the MIPS_RelocationHandler is closer to the start of the list than my implementation which causes my implementation to go unused.

Same thing occurs with extending GnuDemangler.

ryanmkurtz commented 4 years ago

A Ghidra installation has an optional "patch" directory where you can place class files to override default behavior. Other than that, we don't recommend trying to override behavior by hijacking the classpath.

Are you working on a one-off solution for personal use or do you hope to contribute these changes back for others to use?

astrelsky commented 4 years ago

A Ghidra installation has an optional "patch" directory where you can place class files to override default behavior. Other than that, we don't recommend trying to override behavior by hijacking the classpath.

Are you working on a one-off solution for personal use or do you hope to contribute these changes back for others to use?

This would be for a contribution somewhere. I'm just looking to extend the MIPS_RelocationHandler to be used with a specific mips processor.

ryanmkurtz commented 4 years ago

The intended design is for you to create a new subclass of ElfRelocationHandler and override the canRelocate() method with something specific to your processor variant. But it sounds like the existing relocation handler is also hitting on your specific processor?

astrelsky commented 4 years ago

The intended design is for you to create a new subclass of ElfRelocationHandler and override the canRelocate() method with something specific to your processor variant. But it sounds like the existing relocation handler is also hitting on your specific processor?

Yes but only sometimes. I have more details in #1260

ryanmkurtz commented 4 years ago

Ok makes sense. To answer your question in this ticket, you'll have to go into the existing relocation handler and change it to not hit on your MIPS variant. This is the standard solution (ex: X86_32_CoffRelocationHandler vs X86_64_CoffRelocationHandler). The obvious downside to this approach is that they all need to be aware of each other for things to work correctly.

You bring up a good general point though, but we can discuss that in the other ticket.

astrelsky commented 4 years ago

Ok makes sense. To answer your question in this ticket, you'll have to go into the existing relocation handler and change it to not hit on your MIPS variant. This is the standard solution (ex: X86_32_CoffRelocationHandler vs X86_64_CoffRelocationHandler). The obvious downside to this approach is that they all need to be aware of each other for things to work correctly.

You bring up a good general point though, but we can discuss that in the other ticket.

I see. I built a custom loader for it which extends the ElfLoader. So I'll just clear the messageLog to hide the relocation errors and iterate through the relocations to correct them. Thank you.