The format of newer modem.bin of some Samsung devices (e.g. SM-F711U) seems to be changed to the image of a FAT16 file system. Is it still possible to extract an TOC file from it?

For example:

modem.bin: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "MSDOS5.0", Bytes/sector 4096, sectors/cluster 4, root entries 512, Media descriptor 0xf8, sectors/FAT 7, sectors/track 63, heads 255, sectors 56320 (volumes > 32 MB), serial number 0xbc614e, unlabeled, FAT (16 bit)

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?

Does Firmwire support the baseband for this?

[ERROR] firmwire.vendor.mtk.loader: NV data mnt directory is missing  

I didn't use a CP_A136***.tar.md5 from online since the only recent one I could find did not have md1_debuginfo debug symbols. I instead copied it from a phone md1img_a and then compressed it with lz4 and tar.
I get an error mentioning a NV data mnt directory is missing? What is this supposed to be? Looking at the paper and documentation I don't know what is supposed to be there.

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,

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

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.

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.

AT: 0xdeadbeef  -> 0xdeadbeef   -> 0x00000000
V0: 0x0 -> 0x00000000
V1: 0x0 -> 0x00000000
A0: 0x63df642c  -> 0x63df642c   -> 0x00000000
A1: 0x2986174   -> 0x02986174   -> 0x00000001   -> 0x183c0601   -> 0x00000000
A2: 0x0 -> 0x00000000
A3: 0x69100990  -> 0x69100990   -> 0x00000000
T0: 0x0 -> 0x00000000
T1: 0xb2e8      -> 0x0000b2e8   -> 0x2b0eeb8e   -> 0x00000000
T2: 0x0 -> 0x00000000
T3: 0xda79      -> 0x0000da79   -> 0x409a44f0   -> 0x00000000
T4: 0x90bac5e7  -> 0x90bac5e7   -> 0x786a00ea   -> 0x00000000
T5: 0x90db23d4  -> 0x90db23d4   -> 0x00000034   -> 0x00000000
T6: 0x0 -> 0x00000000
T7: 0x3c386ae   -> 0x03c386ae   -> 0x00000000
S0: 0x0 -> 0x00000000
S1: 0x0 -> 0x00000000
S2: 0x2986174   -> 0x02986174   -> 0x00000001   -> 0x183c0601   -> 0x00000000
S3: 0x1 -> 0x00000001   -> 0x183c0601   -> 0x00000000
S4: 0xd0        -> 0x000000d0   -> 0x00000000
S5: 0x0 -> 0x00000000
S6: 0x2 -> 0x00000002   -> 0x0a183c06   -> 0x00000000
S7: 0x0 -> 0x00000000
T8: 0x8 -> 0x00000008   -> 0x00c00008   -> 0xa076f020   -> 0x00000000
T9: 0x691010a0  -> 0x691010a0   -> 0x00000000
K0: 0xdeadbeef  -> 0xdeadbeef   -> 0x00000000
K1: 0xdeadbeef  -> 0xdeadbeef   -> 0x00000000
GP: 0x9f108000  -> 0x9f108000   -> 0xdededede   -> 0x00000000
SP: 0x63df642c  -> 0x63df642c   -> 0x00000000
FP: 0xc8        -> 0x000000c8   -> 0x00000000
RA: 0x90db2598  -> 0x90db2598   -> 0x64faf030   -> 0x00000000
Stack:
[SP+0x00 == 0x63df642c]: 0xdeadbeef00000000     -> 0xdeadbeef00000000   -> 0x3c060157   -> 0x00000000
[SP+0x08 == 0x63df6434]: 0x00000000     -> 0x00000000
[SP+0x10 == 0x63df643c]: 0x298617402986184      -> 0x298617402986184    -> 0x00000000
[SP+0x18 == 0x63df6444]: 0x6910099000000000     -> 0x6910099000000000   -> 0x3c060157   -> 0x00000000
[SP+0x20 == 0x63df644c]: 0xb2e800000000 -> 0xb2e800000000       -> 0x3c060157   -> 0x00000000
[SP+0x28 == 0x63df6454]: 0xda7900000000 -> 0xda7900000000       -> 0x3c060157   -> 0x00000000
[SP+0x30 == 0x63df645c]: 0x90db23d490bac5e7     -> 0x90db23d490bac5e7   -> 0x786a00ea   -> 0x00000000
[SP+0x38 == 0x63df6464]: 0x3c386ae00000000      -> 0x3c386ae00000000    -> 0x3c060157   -> 0x00000000
[ERROR] firmwire.hw.peripheral.PCCIF_Periph.PCCIF0_MD: PCCIF ring no too large (value: 16, is only: 8)
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 "/firmwire/firmwire/vendor/mtk/hw/PCCIFPeripheral.py", line 492, in hw_write
    assert False
AssertionError

May be a dumb question but can I just change the ring size in the peripheral?

Somewhat similar to this #12

I dumped the DB (dimensity-900) and decoded it with your code. It can be decoded as some segments, but no further decoding.

Hi, I am trying to understand the lte_rrc fuzzing modkit code. I am trying to replay a crash input in triage mode and observe the Firmwire console messages. I am able to reproduce the crash from the ndss22 repo using the following command

./firmwire.py -w ./temp_workspace --fuzz-triage lte_rrc --fuzz-input <path_to_crash_inputs>/LTE_RRC_LRRCConnectionReconfiguration_v890_IEs_PREFETCH_ABORT_G973F_CTD1.bin <path_to_modem_files>/CP_G973FXXS5CTD1_CP15661447_CL18242812_QB30535823_REV01_user_low_ship.tar.md5

In the Firmwire output messages, the only messages corresponding to AFL_LTE_RRC task are the task getting inserted and pal_Sleep and pal_MsgSendTo getting called

[INFO] firmwire.vendor.shannon.machine: Injecting task <TaskMod 'AFL_LTE_RRC' base 0x4b000000> -> slot 103
...
[INFO] firmwire.vendor.shannon.machine: TASK103: AFL_LTE_RRC (0x4b000001)
...
[42.95542][AFL_LTE_RRC] 0x4b000025 pal_Sleep(200)
...
[45.34014][AFL_LTE_RRC] 0x4b000167 pal_MsgSendTo(LTERRC (15)) - PALMsg<0x0000, (c3a4) -> PS (0), 16 bytes>

I don't however see any of the uart_puts log messages from the fuzz task code. For example, I can't find this message

uart_puts("[+] Filling the qitem\n");

Where are these messages logged? Can I redirect these messages to the console output?

Thanks in advance

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.

I am trying to replay a crash input using fuzz-triage and then interactively explore using gef-remote. I was able to successfully connect plain gdb remote to the running emulation and set breakpoints and explore the code, but I wanted a convenient view of the program memory (stack and heap), so was trying to connect using gef-remote. It does appear to connect initially but then seems to error out

gef➤ gef-remote localhost 1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
0x00000000 in ?? ()
[!] Command 'gef-remote' failed to execute properly, reason: No session started

On the remote side (the emulation started with -s and -S options), I see the following messages

[INFO] firmwire.vendor.shannon.machine: TASK100: CMMO (0x40f31a49)
[INFO] firmwire.vendor.shannon.machine: TASK101: AFL_GSM_CC (0x4b000001)
[INFO] firmwire: Starting emulator ShannonEMU3334
==> BOOT
==> HALTED
==> WAIT SHUTDOWN
[INFO] avatar2.gdbplugin: Accepted connection from ('127.0.0.1', 33642)
[CRIT] avatar2.gdbplugin: Received not implemented packet: b'Qqemu.sstepbits'

Really appreciate any inputs on this. I am using the Firmwire docker image.

Thanks in advance

I am trying to use glink commands to replicate the modkit fuzzer example gsm_cc for G960 baseband image. I am intending to send the following commands

self.qemu.stop()
self.run_for(10)
gl = self.get_peripheral("glink")
gl.send_queue_op(False, "CC", 0, 0x2a01, b"") # CC_INIT
self.run_for(10)
arr = b"\x03\x05\x1c\xbd\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
gl.send_queue_op(False, "CC", 0x2000aa, 0x2a3c, arr)
self.run_for(10)

glink header limits the message length to 255, however since I need to send much larger messages using glink, I modified the glink source at the following places.
In firmwire/hw/glink.py, changed Line 140 to

return struct.pack("<BH", cmd_type, len)

and in modkit/shannon/glink.c, changed Line 25 to

uint16_t len;

and then rebuilt modkit

Unfortunately since doing these changes my emulation seems to be crashing with an out of memory error for any send_queue_op, even the init message which has an empty payload. This is the crashing output

[ERROR] firmwire.vendor.shannon.hooks: FATAL ERROR (INTERACTIVE): from 0x404d0575 [pal_PlatformMisc.c:146 - Fatal error: PAL_MEM_OUT_OF_MEMORY_ERR
../../../PALCommon/Platform_EV/PAL/MemoryInterface/src/pal_MemInterface.c Line 3]

Any suggestions on what I am doing incorrectly? Or a better way of sending larger messages?

Thanks in advance

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 #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

Hello team, thanks for your awesome work, together with my colleague Eduardo we are about to publish a book which also has some fuzz tests with FirmWire. This follows the lines of the B.Sc of Adrian Hacar Sobrino and Marina Garcia Caro at UC3M Madrid. In principle in the book we bring the user to this point https://twitter.com/adrihacar/status/1412383100580122625 providing a neutral (non-vulnerable) setup message and the code Adrian used for his OTA PoC.

The book will be published by Packt Publishing and the final TOC is the following:

Chapter 1, Who This Book Is For
Chapter 2, History of Emulation
Chapter 3, Qemu From the Ground
Chapter 4, Qemu Execution Modes and Fuzzing
Chapter 5, A Famous Refrain: AFL+QEMU = CVEs
Chapter 6, Modifying QEMU for basic instrumentation
Chapter 7, Real-life Case Study: Samsung Exynos Baseband, dives into the CVE-2020-25279
Chapter 8, Case Study: OpenWRT full system fuzzing
Chapter 9, Case Study: OpenWRT System Fuzzing for ARM,
Chapter 10, Finally Here: iOS Full System Fuzzing
Chapter 11, Deus Ex Machina: Fuzzing Android Libraries

please note that we are not sure on the CVE number cause there was one zero-day and one n-day for anomalous SETUP messages, anyways FirmWire harness is explained in detail and we make a walkthrough of the SETUP phase.

I already tagged Marius and Grant on social media.

hello i have a modem binary that is aarch32 and I can load it in ghidra with your script but I cannot use it with Firmwire - I get an error message about not finding a loader for it. On the wiki it mentions that there is a language for extending the emulator but I don't know how to extend it.

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

Can it support router firmware?I just want to simulate router operation.Look forward to your reply.

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 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.

I'm going to attempt to add a new SOC, unfortunately I wasn't expecting to hit this.

Any direction would be greatly appreciated.

              ___            __      _
-.     .-.   | __|(+) _ _ _ _\ \    / /(+) _ _ ___    .-.     .-
  \   /   \  | _|  | | '_| '  \ \/\/ /  | | '_/ -_)  /   \   /
   '-'     '-|_|   | |_| |_|_|_\_/\_/   | |_| \___|-'     '-'
             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~   v1.1.0
                A  baseband  analysis  platform
                   https://github.com/FirmWire

[INFO] firmwire.loader: Reading firmware using MTKLoader (mtk) and args {'nv_data': PurePosixPath('mnt')}
[INFO] firmwire.vendor.mtk.loader: Found new file md1rom at 0x0/0x0 with length 0x1446cd0
[INFO] firmwire.vendor.mtk.loader: Found new file cert1 at 0x1446ed0/0x12345678 with length 0x6ad
[INFO] firmwire.vendor.mtk.loader: Found new file cert2 at 0x1447780/0x12345678 with length 0x3bd
[INFO] firmwire.vendor.mtk.loader: Found new file md1drdi at 0x1447d40/0x0 with length 0xe6200
[INFO] firmwire.vendor.mtk.loader: Found new file cert1 at 0x152e140/0x12345678 with length 0x6ad
[INFO] firmwire.vendor.mtk.loader: Found new file cert2 at 0x152e9f0/0x12345678 with length 0x3bd
[INFO] firmwire.vendor.mtk.loader: Found new file md1dsp at 0x152efb0/0x0 with length 0x68411c
Traceback (most recent call last):
  File "./firmwire.py", line 312, in <module>
    sys.exit(main())
  File "./firmwire.py", line 228, in main
    loader = firmwire.loader.load_any(
  File "/firmwire/firmwire/loader.py", line 142, in load_any
    obj = _do_load(loader_cls, path, workspace, **loader_args)
  File "/firmwire/firmwire/loader.py", line 184, in _do_load
    if obj.try_load():
  File "/firmwire/firmwire/vendor/mtk/loader.py", line 103, in try_load
    self.sections = {s.name: s for s in self.iter_section_info()}
  File "/firmwire/firmwire/vendor/mtk/loader.py", line 103, in <dictcomp>
    self.sections = {s.name: s for s in self.iter_section_info()}
  File "/firmwire/firmwire/vendor/mtk/loader.py", line 329, in iter_section_info
    name = contents[2][
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc2 in position 0: invalid continuation byte

panda is here:
commit 01c9989b835535f78f5bffec165a39462c361a9c
Merge: b265e4c305 e8c177eca7
Author: Marius Muench [email protected]
Date: Wed Mar 8 11:27:28 2023 +0100

main repo is:
commit 8b540a6
Author: Grant Hernandez [email protected]
Date: Wed Aug 16 10:06:43 2023 -0400

Hi,
I am trying to utilize interactive exploration using gdb remote. In particular, I am hoping to replay a crash input using fuzz-triage option and then use gdb-remote to explore the program state at the instant the crash occurs. Unfortunately, gdb-remote disconnects as soon as the crash error is hit (Fatal Error: PAL_MEM_GUARD_CORRUPTION).

Here is what I am trying to do. I start my replay session with the crash input and the -S and -s flags. When the CPU stops after initialization, I connect through gdb-multiarch using target remote command, and then continue from gdb hoping for it to catch some signal and pause when the fatal error occurs. Unfortunately, emulation aborts when error occurs and gdb remote just disconnects.

I might be doing something terribly wrong, would really appreciate any inputs on this.

Thanks in advance.

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

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

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.

Getting "SOC not supported" error when running firmwire:

Can I help you to add support for this SOC? It would be grateful if this tool would support it. Thanks

We're getting a lot of annoying build warnings in CI:

Warning: The `save-state` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

It's time to upgrade to the latest actions.

This issue should be in the Firmwire Panda repository; however, issues cannot be generated in that repository. Please forgive that I am posting here.

When encountering a MIPSe16 movtz instruction, the output does not appear correct. In the MIPS16e2 spec, there are two different combinations for movtz, one where the rb register is moved and another when rb bits are zero, then the zero register is used. When the zero register is supposed to be used, it appears the s0 register is moved into the destination instead. See code below. Upon additional testing, I also noticed errors when movtz was used with non-zero rb values, for a register to register movtz (e.g. movtz a2, a3; raw bytes 0x27 0xf0 0x16 0x36). I noticed in the source, translate.c "MOVTZ is untested" which is my starting point to trying to fix this issue. If you are able to fix first, great. If not, please advise on how I can solve this issue. Thank you for your time.

Sample Code:
cmpi v0,0x61 (raw bytes: 0x61 0x72)
li v0,0x8 (raw bytes: 0x08, 0x6a)
movtz v0,zero (raw bytes: 0x00 0xf0 0x16 0x32)

Expected output
When v0 is 0x61, v0 should be 0x0.
When v0 is not 0x61, v0 should be 0x8.

Current output:
When v0 is 0x61, v0 becomes s0.
When v0 is not 0x61, v0 becomes 0x8

References:
MIPS16e2 Application-Specific Extension Technical Reference Manual
https://www.mips.com/products/architectures/ase/ase16e/ (pg 56 and 57)

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.

When starting firmware with --console cannot kernel*.json file not created

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!

I am reading the fuzz task for LTE RRC, and I have some questions about the queue item structure used in this fuzzer.

1. What are the possible valid values for the field pdu_type?
2. Does the field asn_pl follows the following ASN1 format from RRCConnectionReconfiguration payload? source

RRCConnectionReconfiguration ::= SEQUENCE {
rrc-TransactionIdentifier RRC-TransactionIdentifier,
criticalExtensions CHOICE {
c1 CHOICE{
rrcConnectionReconfiguration-r8 RRCConnectionReconfiguration-r8-IEs,
spare7 NULL,
spare6 NULL, spare5 NULL, spare4 NULL,
spare3 NULL, spare2 NULL, spare1 NULL
},
criticalExtensionsFuture SEQUENCE {}
}
}

Can you provide an example queue item?

Hello, we are trying to use FirmWire for fuzzing. Based on the docker image provided, we also compile AFL++ with unicorn mode enabled as shown below.

RUN apt-get -y install gdb lz4 cmake
RUN git clone https://github.com/AFLplusplus/AFLplusplus.git /AFLplusplus && \
  cd /AFLplusplus && make clean all && cd unicorn_mode && ./build_unicorn_support.sh

However, running command /AFLplusplus/afl-fuzz -i in/ -o /tmp/out -U -- ./firmwire.py --fuzz gsm_cc --fuzz-input @@ ./modem/modem.bin according to documentation with large AFL_FORKSRV_INIT_TMOUT gets stuck in forkserver initialization for more than 12 hours. I would like to know how such situation can be solved.

Thank you very much.