FirmWire is a full-system baseband firmware emulation platform for fuzzing, debugging, and root-cause analysis of smartphone baseband firmwares

Last update: Dec 25, 2022

Related tags

Deep Learning mediatek emulation qemu introspection fuzzing samsung baseband

Overview

              ___            __      __                         
-.     .-.   | __|(+) _ _ _ _\ \    / /(+) _ _ ___    .-.     .-
  \   /   \  | _|  | | '_| '  \ \/\/ /  | | '_/ -_)  /   \   /  
   '-'     '-|_|   | |_| |_|_|_\_/\_/   | |_| \___|-'     '-'   
             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

FirmWire

FirmWire is a full-system baseband firmware analysis platform that supports Samsung and MediaTek. It enables fuzzing, root-cause analysis, and debugging of baseband firmware images. See the FirmWire documentation to get started!

Experiments & Missing Parts?

Upon a vendor's request, the current public release of FirmWire is a preview version omitting some of the functionality described in the paper. We will publish the full version and automated scripts to replicate our experiments during NDSS'22 (April 24th-28th).

BibTeX

FirmWire is the result of a multi-year, cross university research effort. See the paper for more details.

If you are using FirmWire in an academic paper please use this to cite it:

@inproceedings{hernandez_firmwire_2022,
  title = {{FirmWire: Transparent Dynamic Analysis for Cellular Baseband Firmware}},
  shorttitle = {{FirmWire}},
  booktitle = {{ Symposium on Network and Distributed System Security (NDSS) }},
  author = {Hernandez, Grant and Muench, Marius and Maier, Dominik and Milburn, Alyssa and Park, Shinjo and Scharnowski, Tobias and Tucker, Tyler and Traynor, Patrick and Butler, Kevin R. B.},
  year = {2022}
}

FirmWire's License

FirmWire is licensed under BSD-3 and developed by "Team FirmWire", which currently consists of the authors on the NDSS paper unless stated otherwise. We expect FirmWire to be used for commercial purposes (e.g. private baseband vulnerability research, bug bounties, etc.). The license permits this. We (Team FirmWire) request that users in these settings notify us through public (e.g. issues) or private (e.g. email, Signal) means about your use. We are curious! If FirmWire or derived work helped you find a vulnerability, we'd also like to know in order to add it to the FirmWire trophy wall. Finally, one or more members of Team FirmWire may be willing to provide consulting services such as trainings, custom extensions to FirmWire, advice, and the like. Please reach out if interested.

Comments

Libpanda always starts in suspended mode, even in Fuzz mode

Hello,

I don't really understand how this is even possible if I comment out the gdb ports/commands in the different Python files, I have also been checking the version of panda and pypanda, no matter what the only thing I can alter are the port numbers, where exactly the command line is prepared? I always get

[PYPANDA] Panda args: [/usr/local/lib/python3.8/dist-packages/pandare/data/arm-softmmu/libpanda-arm.so -L /usr/local/lib/python3.8/dist-packages/pandare/data/pc-bios -machine configurable -kernel CP_G973FXXU3ASG8_CP13372649_CL16487963_QB24948473_REV01_user_low_ship.tar.md5.lz4_workspace/ShannonEMU_conf.json -gdb tcp::3355 -S -drive if=none,id=drive0,file=CP_G973FXXU3ASG8_CP13372649_CL16487963_QB24948473_REV01_user_low_ship.tar.md5.lz4_workspace/snapshots.qcow2,format=qcow2 -nographic -qmp tcp:127.0.0.1:3335,server,nowait -m 128M -monitor unix:/tmp/pypanda_mc5sbarnc,server,nowait]

hence AFL does not fire cause the forkserver does not start, and if I plug gdb and continue all goes bananas.

opened by jeppojeps 9

MTK NV Data CREATEDIR

When running FirmWire against any MTK images, the --mtk-loader-nv_data parameter is required (or ./mnt/vendor/nvdata needs to exist). If an empty path is supplied (or mkdir -p mnt/vendor/nvdata), then FirmWire crashes when trying to create the NVRAM subdirectory:

[INFO] firmwire.vendor.mtk.machine: Activating SCPCCISM via affinity hook
[1.59030][NO_TASK] 0x90278d4d [CCISMC] =========> ccismc_create  [CCISM_TR_TASK_CREATE]
[1.59286][NO_TASK] 0x90278d4d [EMM RATCHG] >> CEmmRatChg::CEmmRatChg() [EMM_RATCHG_FUNC_constructor]
[1.82042][NO_TASK] 0x90278d4d [CCCI_FS] ===> MD_FS_GetDiskInfo  [CCCIFS_TR_GETDKINFO_IN]
[1.82046] last message matched ban pattern 'CCCI_FS'
[1.82093][NO_TASK] 0x90151a1b [CCCI_FS GetDiskInfo] filename: Z:\
[1.82094] last message matched ban pattern 'CCCI_FS'
[1.93383] 12 total log lines omitted [NO_TASK=12]
[1.93390][NO_TASK] 0x90150fd7 [CCCI_FS GetAttributes] filename: Z:\FAT2E4C5231.log
[1.93391] last message matched ban pattern 'CCCI_FS'
[1.97289] 11 total log lines omitted [NO_TASK=11]
[1.97296][NO_TASK] 0x901509f7 [CCCI_FS Open] filename: Z:\NVRAM
[1.97297] last message matched ban pattern 'CCCI_FS'
[1.98623] 10 total log lines omitted [NO_TASK=10]
[1.98631][NO_TASK] 0x90279111 nvram_init, step=6213dddc, para=62109724 [FUNC_NVRAM_INIT]
[ERROR] firmwire.hw.peripheral.SHM_CCIF_Periph.SharedMemoryCCIF.FSD: Close: invalid handle value 4294967287
[2.09281] 36 total log lines omitted [NO_TASK=36]
[2.09287][NO_TASK] 0x901510b3 [CCCI_FS CreateDir] filename: Z:\NVRAM
[2.09290] last message matched ban pattern 'CCCI_FS'
[ERROR] firmwire.hw.peripheral.SHM_CCIF_Periph.SharedMemoryCCIF.FSD: Unhandled FSD operation 0x1007 (FSCCCIOp.CREATEDIR)
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner
    self.run()
  File "/usr/local/lib/python3.8/dist-packages/avatar2/avatar2.py", line 522, in run
    handler(message)
  File "/usr/local/lib/python3.8/dist-packages/avatar2/watchmen.py", line 78, in watchtrigger
    ret = func(self, *args, **kwargs)
  File "/usr/local/lib/python3.8/dist-packages/avatar2/avatar2.py", line 491, in _handle_remote_memory_write_message
    success = mem_range.forwarded_to.write_memory(
  File "/usr/local/lib/python3.8/dist-packages/avatar2/peripherals/avatar_peripheral.py", line 66, in write_memory
    return intervals.pop().data(offset, size, value, **kwargs)
  File "/root/FirmWire/firmwire/vendor/mtk/hw/PCCIFPeripheral.py", line 500, in hw_write
    self.handleFSPacket(ring, packet)
  File "/root/FirmWire/firmwire/vendor/mtk/hw/PCCIFPeripheral.py", line 605, in _handleFSPacketEmu
    emu_resp = ring.parent.fsd_ctx["emu"].handle_packet(
  File "/root/FirmWire/firmwire/vendor/mtk/hw/FSD.py", line 573, in handle_packet
    resp_packs = self._handle_op(op, packs)
  File "/root/FirmWire/firmwire/vendor/mtk/hw/FSD.py", line 630, in _handle_op
    assert 0
AssertionError

Adding support for the CREATEDIR operation is trivial. Doing so causes the NV initialization routine to execute, which seeds the NV data. This subsequently allows the baseband to fully boot to the [SSIPC][ILM_MSG] waiting msg loop state. While this may not be ideal for all circumstances, it removes a major hurdle to analyze new images without seeding with arbitrary NV data snapshot.

Apart from allowing the init procedures to auto-generate NV data, what's the recommended method for providing seed NV data? Extract from the AP archive, or from a running device? Any idea on the scope of applicability of NV data extracted from one FW/device to different FW builds, builds for different devices, or different chipsets? Unless relying on CREATEDIR seems optimal, I suggest adding some clarification in docs, as it will be helpful to others! If CREATEDIR is optimal, then it make be preferable to just automatically create ./mnt/vendor/nvdata when it is needed, but not present.

I will issue a pull request against this Issue to add support for CREATEDIR. In my testing, this allows images to boot cleanly when given an empty NV data directory.

opened by j4s0n 5

Fuzzing pal_MemFree symbol not found: Examples fuzzing?

Hello!

I am trying to reproduce some of the paper fuzzing results. Unfortunately I have not much luck with getting any fuzzing to work.

AFL++ version v3.13C Running FirmWire inside Docker container.

Using the following command: AFL_DEBUG=1 afl-fuzz -i in -o out -U -- ./firmwire.py --fuzz gsm_cc --fuzz-input @@ ShannonFirmware/modem_files/CP_G973FXXU9FUCD_CP18513696_CL21324211_QB39036441_REV01_user_low_ship.tar.md5.lz4 I get: [ERROR] firmwire.vendor.shannon.machine: Unable to resolve requested dynamic modkit symbol pal_MemFree [ERROR] firmwire.vendor.shannon.machine: Failed to inject task into OS

When checking, it indeed seems like the firmware itself is missing these symbols. I got the firmware from https://github.com/grant-h/ShannonFirmware.

Removing the registration in shanon.h works, but breaks the emulation. (Setting AFL_FORKSRV_INIT_TMOUT very high does not help, it hangs at [INFO] firmwire.hw.peripheral.ShannonSOCPeripheral.SOC: CHIP_ID read: 50000000)

What are the commands used in the paper? Any help would be appreciated.

Thank you very much!

opened by Michel-de-Boer-dev 4

Unexpectedly exited when running the fuzz demo code on Shannon Baseband

Hello, When I run demo code of fuzzing on Shannon baseband, it seems to have just dropped out. The Shannon baseband firmware is downloaded from the test set given in the paper with version CP_G973FXXS3ASJA_CP14156780_CL17063867_QB26713219_REV01.

# AFL_FORKSRV_INIT_TMOUT=10000 AFL_COMPCOV_LEVEL=1 AFL_DEBUG=1 ./AFLplusplus-stable/afl-fuzz -i in -o out -U -- ./firmwire.py --restore-snapshot fuzz_base --fuzz gsm_cc --fuzz-input @@ new_modem.bin
.....
[INFO] firmwire.vendor.shannon.machine: TASK245: hGmcTime [HISR TASK]
[INFO] firmwire.vendor.shannon.machine: TASK246: hWakeUpD [HISR TASK]
[INFO] firmwire.vendor.shannon.machine: TASK247: AFL_GSM_CC (0x4b000001)
[INFO] firmwire: Starting emulator ShannonEMU3334
==> BOOT
Got AFL_COMPCOV_LEVEL 1.
==> WAIT SHUTDOWN

[-] PROGRAM ABORT : Timeout while initializing fork server (setting AFL_FORKSRV_INIT_TMOUT may help)
         Location : afl_fsrv_start(), src/afl-forkserver.c:1033

I try to set AFL_FORKSRV_INIT_TMOUT to a large value but it still fails.I would appreciate it if you could give me some helpful advice.

opened by N3vv 4

Missing functionality

In the README.md, it says:

Upon a vendor's request, the current public release of FirmWire is a preview version omitting some of the functionality described in the paper. We will publish the full version and automated scripts to replicate our experiments during NDSS'22 (April 24th-28th).

Which functionality is currently missing, that will be published near the end of April?

opened by ghost 4
Fatal error FRPKSIG - Dev Assert DSP PSQ overflow

hello,

I have been running though your Quick Start and grabbed a Shannon firmware to emulate (CP_G930FXXS5ESF1_CP12893112_CL14843133_QB24085562_REV00_user_low_ship.tar.md5) this was taken from the data set (https://zenodo.org/record/6516030#.YncQV3VByEI) kindly provided on ticket #6 by @mariusmue; I think this was the first Shannon baseband on this list.

I have had success emulating other Shannon basebands but this one causes a FATAL ERROR due to (reason:Dev Assert DSP PSQ overflow) when running under normal emulation, I have attached a log of the output that dumps stack and register state. To understand more about your tool, I attempted to debug this problem dynamically using GDB watchpoints, however this is causing an exception in /avatar2/plugins/gdbserver.py (I should probably raise a separate issue here?)

My question is - have you seen this DSP PSQ overflow as a common issue whilst developing support for Shannon firmwares? If so can you suggest an approach to fix the crash?

Update - I have tested a large sample of CP_G935F* and CP_G930F* firmwares and they all produce this fatal error after ~1min of emulation, in contrast CP_G973FXXUCFUH3_CP19998134_CL22340597_QB42324606_REV01_user_low_ship.tar seems to run indefinitely ...

firmwire_log.0.txt

opened by lordofthefarts 2

NV data mnt directory is missing with MT6768 SOC

Hello, it is mentioned in the paper that FIRMWIRE supports the simulation of MT6768,but the following errors will be encountered when running it:

[INFO] firmwire.vendor.mtk.loader: Parsing debug info...
[INFO] firmwire.vendor.mtk.loader: SoC <MediaTekSOC MT6768 - 2020/04/22> (automatic)
[INFO] firmwire.vendor.mtk.loader: Loaded MTK image with 19 sections
[INFO] firmwire.vendor.mtk.loader: Loading cached MTK debug database...
[INFO] firmwire.vendor.mtk.loader: Loaded database with 49507 trace entries
[ERROR] firmwire.vendor.mtk.loader: NV data mnt directory is missing
[ERROR] firmwire.loader: Loading failed!
[ERROR] firmwire.loader: No more loaders to try
[ERROR] firmwire: Failed to load firmware

opened by N3vv 2

Best practice of taking snapshots

What is a good address to take a snapshot at to keep the state of the baseband before calling the guest link methods?

I used the address of the INTERACTIVE task in two scenarios, and both failed. First:

./firmwire.py -t glink --console -S modem.bin

In jupyter console:

self.snapshot_state_at_address(0x4b000001, 'interactive')
# Send a message with glink.send_queue_op
self.restore_snapshot('interactive')
# Get segmentation fault in the first terminal

Second:

./firmwire.py -t glink --console -S modem.bin

In jupyter console (after enough time):

self.qemu.stop() 
self.snapshot('interactive')
# Send a message with glink.send_queue_op and see logs from the target task.
self.restore_snapshot('interactive')
# Repeat the previous message with glink.send_queue_op and don't see any logs from the target task.

Test modem.bin

opened by MustBastani 2

Console Logging question.

How do you see debug messages (dhl_print_string messages) from the firmware when running an image in Console mode? I could not find anything in the documentation regarding this. Below is all I see but i'd like to see all the normal debug messages I see when running on none console mode.

[INFO] firmwire.vendor.shannon.machine: TASK233: IRATSRCH [HISR TASK]
[INFO] firmwire.vendor.shannon.machine: TASK234: IRATMEAS [HISR TASK]
[INFO] firmwire.vendor.shannon.machine: TASK235: IRATSRCH [HISR TASK]
[INFO] firmwire.vendor.shannon.machine: TASK236: IRATMEAS [HISR TASK]
[INFO] firmwire.vendor.shannon.machine: TASK237: PdcpStat [HISR TASK]
[INFO] firmwire.vendor.shannon.machine: TASK238: PdcpResu [HISR TASK]
[INFO] firmwire.vendor.shannon.machine: TASK239: EMM_TIME [HISR TASK]
[INFO] firmwire.vendor.shannon.machine: TASK240: EMM_TIME [HISR TASK]
[INFO] firmwire.vendor.shannon.machine: TASK241: hUSIM [HISR TASK]
[INFO] firmwire.vendor.shannon.machine: TASK242: hUsimDet [HISR TASK]
[INFO] firmwire.vendor.shannon.machine: TASK243: xDma [HISR TASK]
[INFO] firmwire.vendor.shannon.machine: TASK244: xDmaRx [HISR TASK]
[INFO] firmwire.vendor.shannon.machine: TASK245: PDA_Acti [HISR TASK]
[INFO] firmwire.vendor.shannon.machine: TASK246: hGmcTime [HISR TASK]
[INFO] firmwire.vendor.shannon.machine: TASK247: hWakeUpD [HISR TASK]
[INFO] firmwire: Starting emulator ShannonEMU3334
==> BOOT
AFL_COMPCOV_LEVEL not set.
==> CONSOLE
(?) Connect on another terminal with `jupyter console --existing`
(?) Use `self` to access the machine!

When I run the example from from https://github.com/FirmWire/FirmWire/issues/2

# change logging to only include relevant parts
self.guest_logger.task_log_disable_all()
self.guest_logger.task_log_enable('LteRrc')

# our variables
asn_pl = b"\x20\x1b\x3f\x80\x00\x00\x00\x01\xa9\x08\x80\x00\x00\x29\x00\x97\x80\x00\x00\x00\x01\x04\x22\x14\x00\xf8\x02\x0a\xc0\x60\x00\xa0\x0c\x80\x42\x02\x9f\x43\x07\xda\xbc\xf8\x4b\x32\x18\x34\xc0\x00\x2d\x68\x08\x5e\x18\x00\x16\x80\x00"
unused = 0
pdu = 0 # You will need to change this. Either static baseband RE, or trying and checking FirmWire's output
op = self.loader.symbol_table.lookup('SYM_LTERRC_INT_MOB_CMD_HO_FROM_IRAT_MSG_ID').address

# create clean working state
self.restore_snapshot('interactive') 
gl = self.get_peripheral('glink')

# we will need a allocated chunk in memory to hold the ASN payload
gl.create_block(len(asn_pl))
self.run_for(1)
block_addr = gl.access
self.qemu.wm(block_addr, 1,  asn_pl, raw=True)

# Create message as described in fuzz task header
pl = struct.pack('<IIII', unused, pdu, len(asn_pl), block_addr)

# Send the message in the right format (which is, a "direct" message whose pl is UNUSED+PDU+LEN+*ASN_PL)
gl.send_queue_op(False, 'LTERRC', op, 0, pl)
gl.set_event('LTE_RRC_') # LTE RRC messages need to have an event set
self.run_for(1)

I expect to see some of the following in the console

[2491.02450] 575 total log lines omitted [Background=104 INTERACTIVE=104 MTI=101 HISR2=54 CDMOT=50 BTL=40 DS_DBG_SAP=30 RLC=29 LTE_TCPIP=24 DBG_SAP=21 ...]
[2491.02462][LteRrc] pal_TaskEntry_LteRrc+0x91 (0x408c193b) 0b100: [../../../CALPSS/LteL3/LteRrc/Code/src/LteRrc_Task.c] - [MAIN]DrxStart: gDrxRrc_Flag 0 gDrxL1_Flag 1 gDrxRrc_SaveL1Flag 1
[2491.02569][LteRrc] LteRrc_ProcRxMsgFn+0x153 (0x40e648e7) 0b101: [../../../CALPSS/LteL3/LteRrc/Code/src/LteRrc_CommDb.c] - [MAIN][LTERRC_INT_MOB_CMD_HO_FROM_IRAT] RegAllocList
[2491.02677][LteRrc] 0x408bf785 0b100: [../../../CALPSS/LteL3/LteRrc/Code/src/LteRrc_Task.c] - [MAIN][RxMsg SelectMsgQ] Select LteRrc_CurMsgQ
[2491.02737][LteRrc] LteRrc_ReceiveMsg+0x8b9 (0x408c04e9) 0b101: [../../../CALPSS/LteL3/LteRrc/Code/src/LteRrc_Task.c] - [MAIN][RxMsg GetMsgDesc] LTERRC_RADIO_MSG_TYPE:: No MsgDesc
[2491.02796][LteRrc] LteRrc_DisplayRxMsg+0x303 (0x408bd01f) 0b11: [../../../CALPSS/LteL3/LteRrc/Code/src/LteRrc_Task.c] - [MAIN][RX][DO] 1. [LTERRC] <== LTERRC_INT_MOB_CMD_HO_FROM_IRAT (0xc3a0)[Init][Wait Msg]
[2491.02859][LteRrc] LteRrcDsds_CheckIsProcStart+0xa9 (0x40904b91) 0b101: [../../../CALPSS/LteL3/LteRrc/Code/src/LteRrc_ProcDsds.c] - [MAIN][LTE RRC DSRC] LteRrcDsds_CheckIsProcStart msgtype(4)
[2491.02919][LteRrc] LteRrcProAsnDecode+0x4f (0x40827b81) 0b101: [../../../../../../CALPSS/LteL3/LteRrc/asn/arm/Code/Rel1510/src/LteRrc_Codec.c] - LteRrcProAsnDecode (pdu: 6)
[2491.02963][LteRrc] AsnMemAlloc+0x5d (0x411e8a8d) 0b10: [..

But all I see is the following

[INFO] firmwire.hw.fifo: SHM cmd_tx_buff[QUEUE] \x03\x04\x39\x00\x00\x00 6
AFL_COMPCOV_LEVEL not set.
[INFO] firmwire.hw.fifo: SHM cmd_tx_buff[QUEUE] \x01\x96\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x4c\x54\x45\x52\x52\x43\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xa3\xc3\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x39\x00\x00\x00\x00\x00\x00\x00 158
[INFO] firmwire.hw.fifo: SHM cmd_tx_buff[QUEUE] \x02\x09\x04\x4c\x54\x45\x5f\x52\x52\x43\x5f\x00 170

opened by helpcomputer1999 1

Console firmware log messages

How do you see debug messages (dhl_print_string messages) from the firmware when running Firmwire in Console mode? I could not find anything in the documentation regarding this. Below is all I see but i'd like to see all the normal debug messages I see when running on none console mode.

[INFO] firmwire.vendor.shannon.machine: TASK233: IRATSRCH [HISR TASK]
[INFO] firmwire.vendor.shannon.machine: TASK234: IRATMEAS [HISR TASK]
[INFO] firmwire.vendor.shannon.machine: TASK235: IRATSRCH [HISR TASK]
[INFO] firmwire.vendor.shannon.machine: TASK236: IRATMEAS [HISR TASK]
[INFO] firmwire.vendor.shannon.machine: TASK237: PdcpStat [HISR TASK]
[INFO] firmwire.vendor.shannon.machine: TASK238: PdcpResu [HISR TASK]
[INFO] firmwire.vendor.shannon.machine: TASK239: EMM_TIME [HISR TASK]
[INFO] firmwire.vendor.shannon.machine: TASK240: EMM_TIME [HISR TASK]
[INFO] firmwire.vendor.shannon.machine: TASK241: hUSIM [HISR TASK]
[INFO] firmwire.vendor.shannon.machine: TASK242: hUsimDet [HISR TASK]
[INFO] firmwire.vendor.shannon.machine: TASK243: xDma [HISR TASK]
[INFO] firmwire.vendor.shannon.machine: TASK244: xDmaRx [HISR TASK]
[INFO] firmwire.vendor.shannon.machine: TASK245: PDA_Acti [HISR TASK]
[INFO] firmwire.vendor.shannon.machine: TASK246: hGmcTime [HISR TASK]
[INFO] firmwire.vendor.shannon.machine: TASK247: hWakeUpD [HISR TASK]
[INFO] firmwire: Starting emulator ShannonEMU3334
==> BOOT
AFL_COMPCOV_LEVEL not set.
==> CONSOLE
(?) Connect on another terminal with `jupyter console --existing`
(?) Use `self` to access the machine!

opened by helpcomputer1999 0

MTK: fix GDB server support

Currently the Avatar GDB server register files are hardcoded to ARM. This wont work for MIPS targets.

Errors like /build/gdb-ktlO15/gdb-9.2/gdb/frame-unwind.c:168: internal-error: frame_unwind_find_by_frame will appear.
enhancement

opened by grant-h 0
MTK: calling kal_sleep_task in injected task leads to hangs or crashes

Using kal_sleep_task in MediaTek modkit code can lead to crashes or hangs. The MTK vendor plugin during task injection will overwrite the 0IDLE task: https://github.com/FirmWire/FirmWire/blob/main/firmwire/vendor/mtk/machine.py#L552-L557

This is bad as if VPE 0 goes idle during a sleep call, idle task behavior would be overwritten. Some additional details were provided by the reporter:

The problem seems to stem from the idle tasks (1IDLE, 2IDLE, and 3IDLE); 1 and 3 crash in DCM_Service_Handler_Slave, which expects to be run on a different CPU core. When 1 and 3 are disabled, 2 (which seems to be the "master" for the DCM service) runs in an infinite loop; when all 3 are disabled, nothing appears to run. In any case, my code never resumes from kal_sleep_task.

bug

opened by grant-h 0

Dockerfile apt dependency gcc-9-multilib does not exist for aarch64 host (Mac M1)

Building the Docker image fails on aarch64 Ubuntu (VM on M1 macbook). Seems at least one package is unavailable for aarch64:

#5 35.68 E: Unable to locate package gcc-9-multilib

I was able to build the image when explicitly requesting the amd64 base image (seems to use some integrated emulation then?).

diff --git a/Dockerfile b/Dockerfile
index 3e6a2d4..e9b4ded 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -1,4 +1,4 @@
-FROM ubuntu:20.04
+FROM amd64/ubuntu:20.04
 LABEL "about"="FirmWire base img"
 
 ARG DEBIAN_FRONTEND=noninteractive

Am I doing something wrong here, or is there an easy fix besides emulation? I'm not sure if the resulting image works 100%, but at least the firmware does seem to come up and do its thing :-)

$ uname -a 
Linux ubuntu-parallels 5.15.0-47-generic #51-Ubuntu SMP Fri Aug 12 08:18:32 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux
$ docker run --rm -it -v $(pwd):/firmwire firmwire
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
root@3630e1d821d9:/firmwire# uname -a
Linux 3630e1d821d9 5.15.0-47-generic #51-Ubuntu SMP Fri Aug 12 08:18:32 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

I thought I'd be best to share this in an issue in case others are trying the same.

opened by mrlnc 1

MTK: CCCI FS NVD_IMEI read fails, causing restore, leading to NVRAM_LOC_BIN_REGION_RESTORE_FAIL assert
I have been experimenting with a known good Mediatek firmware image and nvdata pulled from the compatible phone. At a certain stage in the execution there are a number of NVRAM ASSERT ERROR NVRAM_LOC_BIN_REGION_RESTORE_FAIL warnings, followed by Panda being called to dump the CPU state to screen. hw_write() is then called which asserts false as the value passed to it is equal to the number of offsets in the ring buffer.

Example log lines for NVRAM ASSERT ERROR:

[106.66529][NO_TASK] 0x90be9145 NVRAM ASSERT ERROR NVRAM_LOC_BIN_REGION_RESTORE_FAIL:6 [106.66621][NO_TASK] 0x90be9155 LID:1473, total_records:1, record_size:12290 [106.66681][NO_TASK] 0x90be9161 category:1000, attr:0 [106.66739][NO_TASK] 0x90be9171 fileprefix:FT02, fileverno:000

After the CPU state dump, the following log lines are printed before the exception in hw_write() is thrown:

[DEBUG] firmwire.hw.peripheral.PCCIF_Periph.PCCIF0_MD: PCCIF write TCHNUM 10 [[1;31mERROR[0m] firmwire.hw.peripheral.PCCIF_Periph.PCCIF0_MD: PCCIF ring no too large (value: 16, is only: 16)

I am testing this with the Samsung A41, and I have tested it with a number of the example firmware images you have provided.

I have attached the output log with debug information for PCCIF0_MD. Any hints at what is causing this exception to be thrown? Crash_Log_FirmWire_PCCIF0_MD.txt.txt
bug
opened by theradicalcentrist40 1
Shannon: Cortex-A Support (e.g S5123)

Thanks for your hard work. I could see the below information from your paper, but I couldn't find the suporting S5123 chipset in FirmWire. "Supporting 5G Basebands. During our research, we also performed an initial assessment of Samsung’s 5G modem (the S5123 chipset)."

Do you have any plan to update for supporting S5123 chipset including cortex-A seriese?
enhancement

opened by yoloygyi 5

Releases(v1.0)

v1.0(Mar 11, 2022)

We are proud to finally release FirmWire! Enjoy :)

Before squashing there were approximately 605 commits. The first commit was Fri Sep 6 12:11:20 2019 -0400 by Grant.

Line stats before squashing history (current files only): 9879 author Grant Hernandez 2632 author Marius Muench 952 author Dominik Maier 753 author Alyssa Milburn 678 author Tobias Scharnowski
Source code(tar.gz)
Source code(zip)

Owner

GitHub https://firmwire.github.io/docs/

Piotr - IoT firmware emulation instrumentation for training and research

Piotr: Pythonic IoT exploitation and Research Introduction to Piotr Piotr is an emulation helper for Qemu that provides a convenient way to create, sh

51 Nov 9, 2022

Fuzzing tool (TFuzz): a fuzzing tool based on program transformation

T-Fuzz T-Fuzz consists of 2 components: Fuzzing tool (TFuzz): a fuzzing tool based on program transformation Crash Analyzer (CrashAnalyzer): a tool th

244 Nov 9, 2022

10th place solution for Google Smartphone Decimeter Challenge at kaggle.

Under refactoring 10th place solution for Google Smartphone Decimeter Challenge at kaggle. Google Smartphone Decimeter Challenge Global Navigation Sat

12 Oct 25, 2022

A general and strong 3D object detection codebase that supports more methods, datasets and tools (debugging, recording and analysis).

ALLINONE-Det ALLINONE-Det is a general and strong 3D object detection codebase built on OpenPCDet, which supports more methods, datasets and tools (de

5 Nov 3, 2022

Convert game ISO and archives to CD CHD for emulation on Linux.

tochd Convert game ISO and archives to CD CHD for emulation. Author: Tuncay D. Source: https://github.com/thingsiplay/tochd Releases: https://github.c

20 Jan 2, 2023

[CVPR 2021] Counterfactual VQA: A Cause-Effect Look at Language Bias

Counterfactual VQA (CF-VQA) This repository is the Pytorch implementation of our paper "Counterfactual VQA: A Cause-Effect Look at Language Bias" in C

94 Dec 3, 2022

CAUSE: Causality from AttribUtions on Sequence of Events

21 Dec 1, 2022

Imbalanced Gradients: A Subtle Cause of Overestimated Adversarial Robustness

Imbalanced Gradients: A Subtle Cause of Overestimated Adversarial Robustness Code for Paper "Imbalanced Gradients: A Subtle Cause of Overestimated Adv

11 Nov 30, 2022

Source code for our paper "Improving Empathetic Response Generation by Recognizing Emotion Cause in Conversations"

Source code for our paper "Improving Empathetic Response Generation by Recognizing Emotion Cause in Conversations" this repository is maintained by bo

24 Nov 29, 2022

MAME is a multi-purpose emulation framework.

MAME's purpose is to preserve decades of software history. As electronic technology continues to rush forward, MAME prevents this important "vintage" software from being lost and forgotten.

6 Oct 25, 2020

Full body anonymization - Realistic Full-Body Anonymization with Surface-Guided GANs

Realistic Full-Body Anonymization with Surface-Guided GANs This is the official

30 Nov 18, 2022

Python interface for SmartRF Sniffer 2 Firmware

#TI SmartRF Packet Sniffer 2 Python Interface TI Makes available a nice packet sniffer firmware, which interfaces to Wireshark. You can see this proje

3 May 18, 2021

FIRM-AFL is the first high-throughput greybox fuzzer for IoT firmware.

FIRM-AFL FIRM-AFL is the first high-throughput greybox fuzzer for IoT firmware. FIRM-AFL addresses two fundamental problems in IoT fuzzing. First, it

356 Dec 23, 2022

Square Root Bundle Adjustment for Large-Scale Reconstruction

RootBA: Square Root Bundle Adjustment Project Page | Paper | Poster | Video | Code Table of Contents Citation Dependencies Installing dependencies on

205 Dec 20, 2022

Implementation of fast algorithms for Maximum Spanning Tree (MST) parsing that includes fast ArcMax+Reweighting+Tarjan algorithm for single-root dependency parsing.

Fast MST Algorithm Implementation of fast algorithms for (Maximum Spanning Tree) MST parsing that includes fast ArcMax+Reweighting+Tarjan algorithm fo

11 Oct 14, 2022