V850 discussion #6
Comments
brainstorm
changed the title
|
Hello! I was unable to reproduce this on Ghidra 10.3 HEAD.
What am I missing? |
|
I did not use that 3rd party V850 extension, but the included V850 support that Ghidra already has. That being said, I closed & reopened Ghidra today and couldn't reproduce either 🤷🏻♂️ So I'm closing this issue, thanks for the fast response! I'm getting the error on the second emulation step though:
The first "Step" on offset 0x00001298 works fine and updates the PC accordingly. I'll need to investigate those options and settings, thanks again for your support! |
|
Thanks for your activity! I still believe that this is not your fault and the error is worth handling. I'll let you know when I've finished my investigation. |
|
This commit successfully fixes this problem. Before you try, don't forget to specify the link register in the Registers View: Be sure to contact if you notice any other strangeness or errors. |
|
Updated to HEAD today and I have a bit more information, namely the error message from the console:
Without squinting at the screenshot, here's what it says in plaintext: Is it possible to make GhidraEmu assume that bytes at that location are uninitialised? Here's the default memory map when importing the binary, if it helps:
|
|
Hi! Take a look at my MemoryMap with the same binary, I guess: As I mentioned before in previous #6 (comment), in V850 I discovered a strange behavior that, when starting emulation, the stackpointer's value is assigned to 0xFFFFFFFF without the knowledge of the plugin (it's a question for the developer of this processor module in Ghidra). Now I made it in c39ba4a so that for V850 processor the stack space will be created according to default 0xFFFFFFFF address. I see in your MemoryMap that you probably didn't reload this Ghidra project (cmciocbl.bin). Try setting the stack ranges manually (0xFFFFE000 - 0xFFFFFFFF), or if circumstances permit, delete this project and create a new one with the same binary. The stack will be automatically allocated to the required addresses in this case. The plugin warning: related to the stack space and I hope my hint will help you deal with it. |
|
Thanks a ton @Nalen98 for the fixes and detailed explanation! I tried both setting the stack/ram manually as suggested and recreating the project. The first didn't work (same issue as before with the new maps), but the recreation worked and I managed to get a bit further on the static emulation, this plugin shows a big promise, well done! Unfortunately, after a few steps, the emulation stopped on a seemingly trivial instruction:
Plus as you can see, most of the stack remains uninitialized, which it shouldn't after offset 0x12A0, where the |
Nalen98
changed the title
|
sp register can be found in the RegistersView (just scroll down a little bit in this window). The start default sp value for v850 is 0xFFFFFFFF. After a few of improvements in 8075d5b I've tried to reproduce this case and here's what I've got:
Emulator stops at address 0x29f8 because it doesn't know about how to deal with non-existing memory space at 0x03ffef7c. This is expected behavior since the emulator is not capable of reading from memory that does not exist. |
On the contrary, that memory space exists and this is where things get interesting and exciting as there's (that I know of) no other FLOSS emulator doing this properly out there :) V850 has a fairly odd memory map that "wraps around" for instruction jump efficiency and some 26-bit oddness too. So the memory is indeed there and must be available as this is a simple bootloader that does not rely on external memory nor a lot of peripherals (perhaps som CSI/UART/SPI port but no complex MMIOs). GhidraEmu needs to know those MCU quirks in order to emulate it properly:
Here's a V850E2-compatible datasheet if you need to check it yourself for MCU NEC μPD703128.pdf EDIT: Actually, I just realised that just setting an appropriate memory map might address the emulator stalling right there, I'll give it a go later. |
|
Thanks for the information.
Yes, add new memory segments to the memory map of your binary in Ghidra according to your CPU memory space. Don't forget to make it initialized to zeros so that the emulator can read bytes from it without problems. Also, according to the screenshot of memory map here esaulenka/ghidra_v850#20 (comment), the section "PERIO_FF" intersects with the emulator stack space. The emulator won't find the "Stack" ranges for this memMap, because the plugin searches for the lowercase "stack" pattern across names of existing memory sections to set suitable as stack. It occurs when you're opening your binary project. At this moment, my record is when emulator stops at 0x2aa6 instruction Please, update GhidraEmu to the latest master, I try to find and fix more and more bugs, thanks. |
|
Thanks for all the fixing and rapid progress on this all the way down to enable interrupts! Are you planning some kind of support for peripheral "hooks" so that we can potentially feed data in and out of say, the CAN bus, ADC or any other peripheral? Since most of them are MMIOs, do you provide some kind of scripting facility/API to manipulate memory in concert with GhidraEmu or Ghidra's API itself is preferred to manipulate GhidraEmu target's memory? I cannot recognise the
<register>
<name>CGSTAT</name>
<description>Clock generator status register</description>
<addressOffset>0xFFFFF824</addressOffset>
<size>8</size>
<access>read-only</access>
<resetValue>0</resetValue>
<resetMask>0xFFFFFFFF</resetMask>
</register>So I would suspect that this is an early stage setup for either the processor's clocking or some serial console's baud rate. If you need a SVD for the datasheet I posted above and start implementing peripheral hook/support in GhidraEmu, I built one myself over here for the V850E2 CA 'Jupiter'. You can expect other MCUs to comply with the CMSIS-SVD spec, so it should be a safe bet for other processors. |
The plugin fully compatible with Ghidra Memory Map ( I've already added this note for users to the README block "Before you start"), if you want to add new memory blocks, the emulator will know about it right away. It doesn't allocate new blocks by itself, and users themselves must deal with such memory allocations if the processor analysis script (
Try to manipulate the project memory before starting the emulation to avoid possible bugs. Also, I think it's a good idea to improve the existing processor module V850 in Ghidra so that after loading the binary (even in the absence of GhidraEmu) you would get the correct allocation of all blocks according to the specification and not do it manually every time. |
|
I am trying to emulate a read and write code through uart on stm32f103 controller |
|
As I can simulate controller in Kiel ide and run the code in simulation, can see the peripheral views, can give input through uart console and also can see the output on uart console |
I also used the SVD loader to reverse one of the public FlashLoaders and found that indeed this script creates new memory blocks for the UART registers and other peripherals in your Ghidra project. But open the Ghidra MemoryMap and pay attention - these memory blocks (although allocated) are not initialized with zeros. And that's what happens in the end - you catch an error when the plugin is running, because the MemoryFaultHandler is triggered on an attempt to read uninitialized memory. To fix this, before start emulation process go to the Ghidra MemoryMap and check the box "Initialized" in front of the memory segment of interest like that:
This will allow the emulator to know for sure that this memory area is initialized and can be read from here. |
|
Thanks
…On Wed, 18 Jan 2023 at 1:04 AM, Helen Sklyarova ***@***.***> wrote:
Now while running the emulation I get error reading from memory address
which are added as peripheral above
Kindly let me know the solution to this that how can I run the emulation
for code and see the uart data register for output and input data
I also used the SVD loader to reverse one of the public FlashLoaders and
found that indeed this script creates new memory blocks for the UART
registers and other peripherals in your Ghidra project.
But open the Ghidra MemoryMap and pay attention - these memory blocks
(although allocated) are not initialized with zeros. And that's what
happens in the end - you catch an error when the plugin is running, because
the MemoryFaultHandler is triggered on an attempt to read uninitialized
memory. To fix this, before start emulation process go to the Ghidra
MemoryMap and check the box "Initialized" in front of the memory segment of
interest like that:
[image: Screenshot from 2023-01-17 22-17-33]
<https://user-images.githubusercontent.com/52778977/212994257-8e188427-f32c-4838-9ece-441dad45ca81.png>
This will allow the emulator to know for sure that this memory area is
initialized and can be read from here.
—
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ARN6CVW45RLT4FOODYMHWETWS3X27ANCNFSM6AAAAAAS4WAZR4>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Can u make some videos for sample firmware using angryghidra also
It would be grt help
…On Wed, 18 Jan 2023 at 1:04 AM, Helen Sklyarova ***@***.***> wrote:
Now while running the emulation I get error reading from memory address
which are added as peripheral above
Kindly let me know the solution to this that how can I run the emulation
for code and see the uart data register for output and input data
I also used the SVD loader to reverse one of the public FlashLoaders and
found that indeed this script creates new memory blocks for the UART
registers and other peripherals in your Ghidra project.
But open the Ghidra MemoryMap and pay attention - these memory blocks
(although allocated) are not initialized with zeros. And that's what
happens in the end - you catch an error when the plugin is running, because
the MemoryFaultHandler is triggered on an attempt to read uninitialized
memory. To fix this, before start emulation process go to the Ghidra
MemoryMap and check the box "Initialized" in front of the memory segment of
interest like that:
[image: Screenshot from 2023-01-17 22-17-33]
<https://user-images.githubusercontent.com/52778977/212994257-8e188427-f32c-4838-9ece-441dad45ca81.png>
This will allow the emulator to know for sure that this memory area is
initialized and can be read from here.
—
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ARN6CVW45RLT4FOODYMHWETWS3X27ANCNFSM6AAAAAAS4WAZR4>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
I need to attach a fuzzer with ghidraemulator
Can u help with that also
On Wed, 18 Jan 2023 at 7:47 AM, parul tiwari ***@***.***>
wrote:
… Can u make some videos for sample firmware using angryghidra also
It would be grt help
On Wed, 18 Jan 2023 at 1:04 AM, Helen Sklyarova ***@***.***>
wrote:
> Now while running the emulation I get error reading from memory address
> which are added as peripheral above
> Kindly let me know the solution to this that how can I run the emulation
> for code and see the uart data register for output and input data
>
> I also used the SVD loader to reverse one of the public FlashLoaders and
> found that indeed this script creates new memory blocks for the UART
> registers and other peripherals in your Ghidra project.
>
> But open the Ghidra MemoryMap and pay attention - these memory blocks
> (although allocated) are not initialized with zeros. And that's what
> happens in the end - you catch an error when the plugin is running, because
> the MemoryFaultHandler is triggered on an attempt to read uninitialized
> memory. To fix this, before start emulation process go to the Ghidra
> MemoryMap and check the box "Initialized" in front of the memory segment of
> interest like that:
>
> [image: Screenshot from 2023-01-17 22-17-33]
> <https://user-images.githubusercontent.com/52778977/212994257-8e188427-f32c-4838-9ece-441dad45ca81.png>
>
> This will allow the emulator to know for sure that this memory area is
> initialized and can be read from here.
>
> —
> Reply to this email directly, view it on GitHub
> <#6 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ARN6CVW45RLT4FOODYMHWETWS3X27ANCNFSM6AAAAAAS4WAZR4>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>
|
The README of this repository contains a detailed enough description of the functionality to get started with plugin. |
Running Ghidra 10.3 from HEAD. The example binary I'm testing this with is this V850 blob
After "Start emulation here", I step once and get the following:
The text was updated successfully, but these errors were encountered: