ris3-lab / p2im-real_firmware Goto Github PK

I see that addition of the soldering iron firmware has been noted on the todo list; could this be released to support replicating your results and benchmarking of our fuzzer?

Hello,

Thank you @bofeng17 to share your dataset artifacts, this is a high value.

Experimenting with different approaches in the field of firmware rehosting, I expressed the need to work with a base firmware dataset which I can customise according to the constraints I encounter with the possibility to come back on the original, so I work with sets of custom patch. This approach allows dataset customisation to focus on a set of specific peripheral access, and remove the others.

Since the P2IM "real firmware" dataset is used for comparison in a number of research, I have chosen to use this dataset to start experiments in peripheral emulation targeting ARM Cortex M MCU. However, the artifacts provided on this repository contain original firmware sources code modification partially documented (excessive fuzzing input consumption...) and related to P2iM specific topics. Moreover the need of heavy IDE for some firmware build makes it difficult to customise the dataset in a trivial way.

To address these pitfalls, I started to develop the Open Firmware Dataset Builder (OFDB), this project is a neutral firmware dataset build environment based on the original firmware sources code, and custom scripts and Makefile. P2IM "real firmware" is the first dataset I have integrated in the OFDB project, but completely reviewed to use the original source code of the firmware projects used in the dataset (except for the heat press), without any modification (no AFL code, no I/O code deletion).

I thought posting here might interest anyone using the "P2IM real firmware".

open-firmware-dataset-builder -> p2im-real-firmware

Would you agree to provide a list of all the modifications applied to the original source code of the firmware used in the P2IM research. I would like to add compilation options to the OFDB build environment to produce the P2IM real firmware dataset as close as possible of the images contain in this repository, by applying a patch during firmware source code bootstraps in the environment.

I hope you will accept and take the time to provide these data, thank you in advance.

Hello, I am studying and experimenting on P2IM.
I want to run firmware using P2IM.The error "KeyError:255" occurs in the me.py code. This means that the return value will be 0xff when QEMU is run as subprocess and it is not defined as the rv dictionary of me.py code. This results in an error.
What is the meaning of the return value of the QEMU, 0xff?

If I ignore this error and proceed, there is a myriad of rounds with the phrase "There is aup, run Me." (where the "Stage 2 returned to unexpected reasons!" part indicates a KeyError:255 error, and simply added 0xff to the dictionary not to print errors.)

And at the end, fuzzing does not proceed with the following error.
I proceeded with the firmware that added the mcu and startForkserver part, and I wonder how to solve the error.

There seem to be modifications to many of the firmware that I didn't see mentioned in the paper or documented in the readme/wiki.

Commented changes

Looking at some of the firmware, there are comments specifically referring to fuzzing or P2IM.

Unclear comments

Some comments leave me uncertain as to whether any change was made. Such as:

Uncommented changes

Furthermore, there are some functions that appear to have modifications without any comment explaining them. The return statement added to the start of the following function would significantly affect execution, and is not present in the repository referenced in the P2IM research paper.

Other changes I have observed include the CNC firmware's Makefile, where optimisations were disabled. The original firmware as referenced in the P2IM research paper has optimisations enabled.

Significance

Is there any documentation for a full list of what was changed from the original source? Changes such as the one made to the drone firmware impact fundamental challenges in embedded system fuzzing, as it ties in with timers and interrupts. Given that these firmware are being used in benchmarks for other embedded system fuzzers, such as uEmu, I think it's important to note these changes. Future works that could solve issues mentioned in the comments of these code changes would not see any benefit on these benchmarks if the corresponding code has been commented out.