ris3-lab / dice-dma-emulation Goto Github PK
View Code? Open in Web Editor NEWDICE: Automatic Emulation of DMA Input Channels for Dynamic Firmware Analysis
License: Other
DICE: Automatic Emulation of DMA Input Channels for Dynamic Firmware Analysis
License: Other
./run.py f103 ./Firmware/Binaries-DICE/F103_ADC_SingleConversion_TriggerTimer_DMA.elf ./output
failed
/home/wangfeng/DICE-DMA-Emulation/DICE-Evaluation/ARM/Unit-Test/../DICE-P2IM-Utilities/me.py:44: DeprecationWarning: The SafeConfigParser class has been renamed to ConfigParser in Python 3.2. This alias will be removed in future versions. Use ConfigParser directly instead.
parser = configparser.SafeConfigParser()
***************
./Firmware/Binaries-DICE/F103_ADC_SingleConversion_TriggerTimer_DMA.elf
***************
Change working dir to: 1/
CWD: /home/wangfeng/DICE-DMA-Emulation/DICE-Evaluation/ARM/Unit-Test/1
cmd to launch this script: /home/wangfeng/DICE-DMA-Emulation/DICE-Evaluation/ARM/Unit-Test/../DICE-P2IM-Utilities/me.py -c mi-f103.cfg
args after processing: Namespace(afl_file=None, config='mi-f103.cfg', eval=False, gt=None, model_if=None, print_to_file=False, run_from_fs=False, run_num='1')
configurations after processing: Namespace(board='NUCLEO-F103RB', img='/home/wangfeng/DICE-DMA-Emulation/DICE-Evaluation/ARM/Unit-Test/Firmware/Binaries-DICE/F103_ADC_SingleConversion_TriggerTimer_DMA.elf', log_f='/home/wangfeng/DICE-DMA-Emulation/DICE-Evaluation/ARM/Unit-Test/me.log', mcu='STM32F103RB', objdump='/home/gym/DICE-DMA-Emulation/p2im/gcc-arm-none-eabi-9-2020-q2-update/bin/arm-none-eabi-objdump', peri_addr_range=512, qemu_bin='/home/wangfeng/DICE-DMA-Emulation/DICE-precompiled/ARM_bin/qemu-system-gnuarmeclipse', qemu_log='unimp,guest_errors,int', retry_num=3)
depth 1, stage: SR_R_ID
cmd: /home/wangfeng/DICE-DMA-Emulation/DICE-precompiled/ARM_bin/qemu-system-gnuarmeclipse -verbose -verbose -d unimp,guest_errors,int -nographic -board NUCLEO-F103RB -mcu STM32F103RB -image /home/wangfeng/DICE-DMA-Emulation/DICE-Evaluation/ARM/Unit-Test/Firmware/Binaries-DICE/F103_ADC_SingleConversion_TriggerTimer_DMA.elf -pm-stage 1 -trace trace-depth:1,stage:1.0 -reg-acc reg_acc-depth:1,stage:1.0 -model-output model-depth:1,stage:1.0.json
ret_val: 0x7f
ret_val == 0x7f, re-run it!
ret_val: 0x7f
ret_val == 0x7f, re-run it!
ret_val: 0x7f
ret_val == 0x7f, re-run it!
Traceback (most recent call last):
File "/home/wangfeng/DICE-DMA-Emulation/DICE-Evaluation/ARM/Unit-Test/../DICE-P2IM-Utilities/me.py", line 1158, in <module>
ret_val = stage1()
File "/home/wangfeng/DICE-DMA-Emulation/DICE-Evaluation/ARM/Unit-Test/../DICE-P2IM-Utilities/me.py", line 358, in stage1
ret_val = qemu_run(cmd, cfg.retry_num, stage)
File "/home/wangfeng/DICE-DMA-Emulation/DICE-Evaluation/ARM/Unit-Test/../DICE-P2IM-Utilities/me.py", line 192, in qemu_run
color_print(error_rv[stage][ret_val], "red")
KeyError: 1
['/home/wangfeng/DICE-DMA-Emulation/DICE-precompiled/ARM_bin/qemu-system-gnuarmeclipse', '-verbose', '-verbose', '-d', 'unimp,guest_errors,int', '-nographic', '-board', 'NUCLEO-F103RB', '-mcu', 'STM32F103RB', '-image', '/home/wangfeng/DICE-DMA-Emulation/DICE-Evaluation/ARM/Unit-Test/Firmware/Binaries-DICE/F103_ADC_SingleConversion_TriggerTimer_DMA.elf', '-pm-stage', '1', '-trace', 'trace-depth:1,stage:1.0', '-reg-acc', 'reg_acc-depth:1,stage:1.0', '-model-output', 'model-depth:1,stage:1.0.json']
exit_callback is invoked
Execution time(seconds):
0.06402420997619629
Traceback (most recent call last):
File "/home/wangfeng/DICE-DMA-Emulation/DICE-Evaluation/ARM/Unit-Test/../DICE-P2IM-Utilities/statFp3.py", line 261, in <module>
aux = getStat(sys.argv[1],sys.argv[2],sys.argv[3])
File "/home/wangfeng/DICE-DMA-Emulation/DICE-Evaluation/ARM/Unit-Test/../DICE-P2IM-Utilities/statFp3.py", line 177, in getStat
for intrs in data["interrupts"]:
KeyError: 'interrupts'
From looking at the uploaded source, I see the oscilloscope binary has some changes to introduce canaries around DMA buffers.
One such case being here where the buffer is defined as:
struct Points
{
uint32_t canary1[64];
uint32_t dataPoints32[maxSamples / 2];
uint32_t canary2[64];
};
Points sPoints;
uint32_t *dataPoints32 = (uint32_t *)&sPoints.dataPoints32;
While the original code defines the array as:
uint32_t dataPoints32[maxSamples / 2];
But this changes the type of the dataPoints32 global variable from an array to a pointer. When taking the address and casting to a uint16_t* here this causes a problem.
uint16_t *dataPoints = (uint16_t *)&dataPoints32;
Rather than taking the address of an array, this takes the address of a pointer. Instead of the intended cast from uint32_t* to uint16_t*, it is casting from a uint32_t** to a uint16_t*
Therefore, the dataPoints pointer does not point to the DMA buffer, and the attempts to use it lead to accessing random global variables.
Also, the maxSamples variable in the uploaded code is set to 64, which should be 128 bytes for the dataPoints32 buffer, but the precompiled binary available in this repo does not match this, instead containing a 4096 byte buffer.
The issue happens following./fuzz.py -c ./Configs/Modbus.cfg
[-] Oops, the program crashed with one of the test cases provided. There are
several possible explanations:
- The test case causes known crashes under normal working conditions. If
so, please remove it. The fuzzer should be seeded with interesting
inputs - but not ones that cause an outright crash.
- The current memory limit (2.00 GB) is too low for this program, causing
it to die due to OOM when parsing valid files. To fix this, try
bumping it up with the -m setting in the command line. If in doubt,
try something along the lines of:
( ulimit -Sv $[2047 << 10]; /path/to/binary [...] <testcase )
Tip: you can use http://jwilk.net/software/recidivm to quickly
estimate the required amount of virtual memory for the binary. Also,
if you are using ASAN, see docs/notes_for_asan.txt.
- Least likely, there is a horrible bug in the fuzzer. If other options
fail, poke <[email protected]> for troubleshooting tips.
AFL failed to run because the first test case caused a crash. However, when I changed the memory option to none
, it still failed.
/fuzz.py:46: DeprecationWarning: The SafeConfigParser class has been renamed to ConfigParser in Python 3.2. This alias will be removed in future versions. Use ConfigParser directly instead.
parser = configparser.SafeConfigParser(os.environ)
Change working dir to: /home/wangfeng/FuzzBase/Modbus/1.0
CWD: /home/wangfeng/FuzzBase/Modbus/1.0
try our best to extract model w/o input
model already extracted! No need to do it again
extract model for each seed input
0.input.data.1
run f/w w/ seed input to check if there is aup
cmd_qemu: /home/wangfeng/DICE-DMA-Emulation/p2im/qemu/src/install/debian64/qemu/bin/qemu-system-gnuarmeclipse -nographic -aflFile /home/wangfeng/FuzzBase/Modbus/1.0/inputs/input.data -board NUCLEO_F303RE -mcu STM32F303RE -image /home/wangfeng/DICE-DMA-Emulation/DICE-Evaluation/ARM/Fuzzing/Firmware/Binaries/Modbus.elf -pm-stage 3 -model-input /home/wangfeng/FuzzBase/Modbus/1.0/0/peripheral_model.json -me-bin /home/wangfeng/DICE-DMA-Emulation/DICE-Evaluation/ARM/DICE-P2IM-Utilities/me.py -me-config mi-f303.cfg
No aup, don't run ME
launch fuzzer
cmd_afl: /home/wangfeng/DICE-DMA-Emulation/p2im/afl/afl-fuzz -m none -i /home/wangfeng/FuzzBase/Modbus/1.0/inputs -o /home/wangfeng/FuzzBase/Modbus/1.0/outputs -t 2000+ -QQ -a /home/wangfeng/DICE-DMA-Emulation/DICE-Evaluation/ARM/DICE-P2IM-Utilities/me.py -b mi-f303.cfg -c /home/wangfeng/FuzzBase/Modbus/1.0/0/peripheral_model.json -T Modbus_1.0 -d /home/wangfeng/DICE-DMA-Emulation/p2im/qemu/src/install/debian64/qemu/bin/qemu-system-gnuarmeclipse -nographic -board NUCLEO_F303RE -mcu STM32F303RE -image /home/wangfeng/DICE-DMA-Emulation/DICE-Evaluation/ARM/Fuzzing/Firmware/Binaries/Modbus.elf -pm-stage 3 -aflFile @@
afl-fuzz 2.06b by <[email protected]>
[+] You have 12 CPU cores and 1 runnable tasks (utilization: 8%).
[+] Try parallel jobs - see docs/parallel_fuzzing.txt.
[*] Checking core_pattern...
[*] Checking CPU scaling governor...
[*] Setting up output directories...
[+] Output directory exists but deemed OK to reuse.
[*] Deleting old session data...
[+] Output dir cleanup successful.
[*] Scanning '/home/wangfeng/FuzzBase/Modbus/1.0/inputs'...
[+] No auto-generated dictionary tokens to reuse.
[*] Creating hard links for all input files...
[*] Validating target binary...
[*] Attempting dry run with 'id:000000,orig:input.data'...
[-] Oops, the program crashed with one of the test cases provided. There are
several possible explanations:
- The test case causes known crashes under normal working conditions. If
so, please remove it. The fuzzer should be seeded with interesting
inputs - but not ones that cause an outright crash.
- Least likely, there is a horrible bug in the fuzzer. If other options
fail, poke <[email protected]> for troubleshooting tips.
[-] PROGRAM ABORT : Test case 'id:000000,orig:input.data' results in a crash
Location : perform_dry_run(), afl-fuzz.c:2781
You mentioned that the path of the binary generated by compilation is ./p2im/qemu/src/install/debian64/qemu/bin, but I found that there is no QEMU related binary in this path after compilation。Can you help clarify it.
I wasnt able to run unit tests neither on Ubuntu 18 LTS nor 20 but removing that file actually got it working
currently running on 4.15.0-166-generic will test it on the newer kernel shortly
Hi,
For my thesis I am working with DMA on the Nucleo L152 (re) platform. When I wanted to try some of the firmware I had compiled with DICE, I got some nondescript issues.
ret_val == 0xFF, re-run it!
After three times, the re-run attempt stop and a python trace is produced:
From what I can see the L1521 maps to the F105 platform inside of DICE. Is this an unfortunate name change or is the L152 platform executable when F105 is selected on qemu's side of things?
Screenshot included:
https://cdn.discordapp.com/attachments/783312794367557682/814879611128381454/unknown.png
Thanks for your help and I have run my binary successfully. However, I didn't know the reason why this crash came into being. I mean I have tried to use gdb to analyze the crash but the problem printed by run_fw.py was too vague to analyze. There are two problems listed following.
For the first problem, I have noted comment in memory.c tells it only happens in fuzzing, which makes me confused. For the second one, without analyzing the register information I guess it is a kind of problem related to segmentation fault or array out of bounds. Is that correct?
Thanks for your prompt attention.
Sincerely,
Cr1t
I followed the step in "https://github.com/RiS3-Lab/p2im/blob/master/docs/add_mcu.md" to add mcu stm32f103xe. You could see the mcu details the following.
FLASH_BASE_ADDR: 0x08000000
FLASH_SIZE: 512
RAM_BASE_ADDR: 0x20000000
RAM_SIZE: 64
Then I configured the stm32f103xe.cfg file and imported object.elf to the specific path. However, when I ran the fuzz.py, it crashed with the input test cases. I turned to my input data and found some documents like "model-depth:10, stage:1.0.json" and "depth: 9, stage: 2.0". It seems that it initialized successfully but cannot start the test cases.
Do you have any idea with this problem? Thanks for your prompt attention.
Sincerely,
Cr1t
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.