search

mumbel / ghidra

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

improvements #21

Open mumbel opened 4 years ago

mumbel commented 4 years ago

@esaulenka @bagasu @rolandh @DarrylC03 I started a new branch to maybe add a few improvements. The patterns thing seems pretty nice already though to help find code (feedback on bad/additional/better patterns would be great, still figuring out the capabilities of patterns though) and ELF relocations (probably not of use to you, but will hopefully help with other analysis/code/testing).

https://github.com/mumbel/ghidra/tree/tricoreanalyzer

not sure how much more/often I'll work on it, but at least letting you know about the patterns feature

DarrylC03 commented 4 years ago

@mumbel should I report issues here with the tricore processor? I am using the December public release but will try and get the build to work for the latest release on W10 as well. No priority as I can get most of what I need by using a combo of IDA and Ghidra. There are still missing code between compiler generated functions: image which should be decoded as: image As well as these type of "off by 1" failure to decode correctly: image image Which Ghidra does quite a bit with the last jump statements in a jump table.
image

You can see from this image that IDA also does analysis of the stack variables as well. I like the Ghidra choice here but others may prefer what IDA does especially in this case where the function cannot be decompiled to C (unknown error)

mumbel commented 4 years ago

Hey, @DarrylC03 , I don't mind looking at bug reports here, but you might eventually get attention from the Ghidra devs if you post an issue there. A lot of stuff, unless an actual instruction decoding bug (for the most part this is all I think I could promise to reasonably help/fix), I just don't know enough fix in most cases.

The last screenshot does seem kind of surprising, I do have a10 listed as the stack pointer, so not sure what to do about that, seems auto analysis would pick that up. The first two are a change in code flow that I'm not sure how Ghidra decides to keep disassembling by address or continue with code flow, I'd think it would attempt to disassemble in those examples too.

One area I'd really like to get some time to spend on is the decompiler, but just haven't yet. things like bad switches and the resulting disconnected code flow and low-level messages like yours are super frustrating, I get those on other processors too. I really don't know if that's some issue with the SLEIGH I implemented as-is for each instruction or just instructions that regardless of the implementation the decompiler would choke on due to complexity.

DarrylC03 commented 4 years ago

Thanks Mumbel,

I will put a link to these comments on the tricore enhancements thread and start adding the requests there.

Awesome work BTW.

Regards, Darryl.

On Mon, 17 Feb 2020 at 14:00, mumbel notifications@github.com wrote:

Hey, @DarrylC03 https://github.com/DarrylC03 , I don't mind looking at bug reports here, but you might eventually get attention from the Ghidra devs if you post an issue there. A lot of stuff, unless an actual instruction decoding bug (for the most part this is all I think I could promise to reasonably help/fix), I just don't know enough fix in most cases.

The last screenshot does seem kind of surprising, I do have a10 listed as the stack pointer, so not sure what to do about that, seems auto analysis would pick that up. The first two are a change in code flow that I'm not sure how Ghidra decides to keep disassembling by address or continue with code flow, I'd think it would attempt to disassemble in those examples too.

One area I'd really like to get some time to spend on is the decompiler, but just haven't yet. things like bad switches and the resulting disconnected code flow and low-level messages like yours are super frustrating, I get those on other processors too. I really don't know if that's some issue with the SLEIGH I implemented as-is for each instruction or just instructions that regardless of the implementation the decompiler would choke on due to complexity.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mumbel/ghidra/issues/21?email_source=notifications&email_token=AGEX7WGDO57R2FFKVT2FEDTRDH4WHA5CNFSM4KCJMIUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL45FFY#issuecomment-586797719, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGEX7WHFCS5YKH5CMXBHDOLRDH4WHANCNFSM4KCJMIUA .