Why 5G Baseband NAS Is Hard to Test

▶ Watch (01:56)

Samsung and Pixel basebands run millions of lines of C and C++ on a dedicated processor, parsing 5G packets from the nearest tower with no ASLR and no source code. A fake base station can send malicious over-the-air messages that trigger buffer overflows or remote code execution, escalating into the main OS.

The NAS layer sits behind encryption and integrity checks. Prior tools like BasiFi needed hours of manual hook setup per firmware. Tools that ignored protocol state had test inputs rejected before they reached any meaningful code. Neither approach works for stateful, C++-heavy 5G Shannon binaries.

Building Loris: Full-System Emulation for Shannon Basebands

▶ Watch (07:43)

Loris is a full-system emulator built on Firmwire and extended for Samsung Shannon 5G basebands. Give it a binary and it resolves memory layout from TTBR0 page table instructions, emulates the Shannon and Exynos multicore timers, and spins up RTOS tasks automatically. No manual hook setup. The Cortex-R to Cortex-A transition in Samsung’s first 5G phones required new address translation handling since Cortex-A uses an MMU instead of a memory protection unit. The team also wrote Ghidra scripts to recover C++ vtables and inject resolved function names into the decompiled view, turning pointer-heavy C++ into something readable.

Harnessing the NAS Task and Bypassing Security Checks

▶ Watch (13:55)

Finding the NAS task meant scanning the RTOS task array for NASOT, then string-searching for known NAS message names. The string “data IND” pointed to the handler that delivers over-the-air payloads from the RRC layer to NAS. But test messages still got rejected: NAS expects encrypted, integrity-protected inputs. Hooking security checks was fragile. A prior Black Hat authentication bypass worked until Samsung patched it. The durable fix was an NVM flag: setting it causes the baseband to skip all security checks automatically, letting fuzz inputs through on any firmware version.

Iterative Symbolic Analysis: Solving the State Explosion Problem

▶ Watch (20:25)

State variables gate every NAS message. In 5G Shannon firmware they live in heap-allocated objects behind chains of virtual method calls, with no fixed global addresses to patch. Making all 100-plus state variables symbolic at once caused a path explosion: after four hours, execution was running 9,000 concurrent paths and had consumed over a terabyte of RAM. The solution was iterative symbolic analysis. Each run starts with no symbolic state variables, adds one per iteration, and reuses results from the prior run to fast-track past already-resolved branches. Coverage more than doubled compared to prior tools.

Seven Crashes, Five CVEs, and Exploit Potential

▶ Watch (31:14)

Fuzzing the Galaxy S21 and Pixel 6 NAS tasks produced seven unique crashes, all triggerable over the air on real devices, earning five CVEs. The team validated each one using a USRP B210 as a base station with an Open5GS core. The Galaxy S21 baseband crash over the air (32:29) shows a malicious registration accept message crashing the baseband mid-registration, forcing a reboot into debug mode. The 5G Shannon baseband has no RWX regions, but the stack canary lives in a writable global memory page. A heap overflow gives write-what-where, which can overwrite the canary and chain into ROP for full remote code execution.

Notable Quotes

memory unsafe languages mostly C or C++ Ali Ranjbar · ▶ 4:26

obvious that this is not a scalable, Chen Yang · ▶ 20:57

complexity doesn’t mean better Chen Yang · ▶ 38:24

Key Takeaways

  • Loris finds more than double the NAS code coverage of prior tools with fully automated state initialization.
  • Seven exploitable over-the-air crashes found in Galaxy S21 and Pixel 6 basebands, earning five CVEs.
  • Baseband stack canaries can be bypassed via heap overflow write-what-where against the canary’s writable global memory page.