search

NationalSecurityAgency / ghidra

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

Ability to specify PowerPC VLE flag value to be used with dynamically generated code #6799

Open PTDreamer opened 1 month ago

PTDreamer commented 1 month ago

Is your feature request related to a problem? Please describe. I'm using the GUI emulator to emulate a PowerPC:BE:64 binary. At some point a function is copied from flash to ram and run from there. The problem is that the new ram code is considered non vle ("set register value" does not work) and not properly disassembled (as seen on the dynamic window). Additionally the "decompile" window is not populated while this dynamically generated code is running.

Describe the solution you'd like The vle value should be kept when "jumping" from static to dynamic code and the decompile window should refresh and "capture" the new assembly.

Describe alternatives you've considered Alternatively the set register value menu could work on the dinamic window.

ghidra1 commented 1 month ago

There is a dedicated VLE disassembly action. Alternatively you can set the VLE context over a memory region. The register value editor can be used to do this. The API can also be used to set the context programmatically.

Unclear how this would help with your emulation scenario. Typically this would be under target software control if not done at the time of loading. The ELF Loader does set VLE context during import where needed.

nsadeveloper789 commented 1 month ago

To be clear, what the Dynamic Listing displays is not necessarily the same as what the Emulator is going to decode. That said, if they disagree, that is a point of concern, since I'd like the Listing to show what the Emulator will do.

To see what the Emulator is actually decoding, turn on the DebuggerPcodeStepperPlugin. (Use File → Configure → Configure All Plugins — in the top right.) This should add a new pane. If it's not obvious where it is, use Window → Debugger → Pcode Stepper. That pane will have "Emulate p-code tick" buttons instead of "Step Instruction" buttons. Step one p-code tick forward to have the Emulator decode an instruction. The Stepper panel should display the decoded instruction right above the table of ops. Check whether that's the VLE instruction or non-VLE. If VLE, then the Emulator is doing as you expected, and you can try manually disassembling.

In the Dynamic Listing, right-click the first instruction of the copied function and select Disassemble as .... One of the options ought to be the VLE instructions. Again, I concur that it should just agree with the Emulator, but at least that'll get the Listing displaying the expected instruction set.

The Decompiler is intentionally left bound only to the Program database. There have been brief discussions about binding it to the Dynamic Listing (i.e., the Trace database), but the underlying Trace database does not completely implement all of the interfaces required to support decompilation. We had aimed for this as we were first developing it, but it proved too costly compared to alternatives. Instead, we allow the user to manually (deliberately) capture dynamic data back into the Program database, which can then be decompiled (not to mention analyzed, marked up, and shared) as usual. To do this, select the portion in the Dynamic Listing you'd like to capture. Then, in the menus, select Debugger → Copy Into Current Program.

PTDreamer commented 4 weeks ago

To be clear, what the Dynamic Listing displays is not necessarily the same as what the Emulator is going to decode. That said, if they disagree, that is a point of concern, since I'd like the Listing to show what the Emulator will do.

It appears they do disagree (using auto-disassembly). After enabling the PCode Stepper it seems that the emulator is in fact using VLE but the dinamic listing shows non VLE opcodes. ghidra

In the Dynamic Listing, right-click the first instruction of the copied function and select Disassemble as .... One of the options ought to be the VLE instructions. Again, I concur that it should just agree with the Emulator, but at least that'll get the Listing displaying the expected instruction set.

Doesn't seem to work, the dinamic listing remains the same (un-disassembled/assembled) using "disassemble" or "disassemble as".

The Decompiler is intentionally left bound only to the Program database. There have been brief discussions about binding it to the Dynamic Listing (i.e., the Trace database), but the underlying Trace database does not completely implement all of the interfaces required to support decompilation. We had aimed for this as we were first developing it, but it proved too costly compared to alternatives. Instead, we allow the user to manually (deliberately) capture dynamic data back into the Program database, which can then be decompiled (not to mention analyzed, marked up, and shared) as usual. To do this, select the portion in the Dynamic Listing you'd like to capture. Then, in the menus, select Debugger → Copy Into Current Program.

I understand the reasoning and the workaround for static analysis , but it would be nice to follow a decompiled listing while stepping the emulator.

nsadeveloper789 commented 4 weeks ago

I understand the reasoning and the workaround for static analysis , but it would be nice to follow a decompiled listing while stepping the emulator.

I'll follow-up a bit: Once the bytes are copied in, the static listing should still follow the dynamic one, and so you'll have the decompiler following along while you step through the copied function, too.