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.

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.

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!

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.

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?

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

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

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

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

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!

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.

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.

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
[email protected]:/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.

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
[ERROR] 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

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?