Shannon: Cortex-A Support (e.g S5123)

[yoloygyi]

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?

[mariusmue]

Hi!

Thanks for your interest in FirmWire. Naturally, we would be very interested in also supporting 5G modems.
The main limitation on Samsung's side is that the CP changed from a Cortex-R to a Cortex-A style core - which breaks part of the patterns and emulator-initialization as performed currently. As such, we believe that emulating those cores should be possible in the future. However, the core FirmWire team is currently not working on this, but we would always happily merge in pull requests!

For the quote you are referring to: This initial assessment was purely based on static analysis, and we could confirm that the core structure of the baseband RTOS did not change significantly.

[guysrd]

hi all

I'd be happy to contribute and work together on Cortex-A support, I'll be allocating time for a PoC post-REcon.
I'd be happy to take this offline and talk about it briefly.

[grant-h]

@guysrd awesome! we would be happy to work with you to get this supported. here's a rough list of all of the things off the top of my head that need to be changed to bring Cortex-A support.

• Build panda aarch64 since A series not supported by arm version
• Create aarch64 config for avatar
• Add a condition to the Shannon loader to detect Cortex-A vs R. Do not extract MPU if A series
• Some how extract a tentative memory map without MPU support (is there an MMU table?)
• Most likely need to create a new PCIe CP<->AP peripheral to replace shmem one
• Most likely need a new timer interrupt controller peripheral
• Bring up Cortex-A machine at first instruction in ARM mode (baseband is still 32 bit)
• Begin iterating through the boot process, creating/porting peripherals for a S5XXX SoC definition (longest part)
• Reach pal_init1 banner display
• Reach end of pal_init1 with tasks starting to boot
• Reach majority of tasks booting (except less important crashing ones which can be disabled)
• Reach quiescent baseband state (event/timer driven, non-crashing)
• Investigate and fix OSI support (task struct size/fields, queues, semaphores)

[guysrd]

Hi @grant-h
Thanks for the reply,
I'll keep you updated and probably ask a lot of questions about it : )

see you soon
Guy

[Michel-de-Boer-dev]

Hi!

Any update on this issue? This is something I would like to take a look at as well.

I happily discuss it further.

[HarperMua]

• Bring up Cortex-A machine at first instruction in ARM mode

Hi! Thanks for your hard work!
I want to know the specific implementation. Since I have built panda aarch64 and created aarch64 config for avatar and ran S5123 under aar64 architecture. But under aar64 architecture, the codes are 64 bits, how can I convert it to 32 bits. Besides, if I run S5123 under arm architecture, the firmware can run further. I would like to know the necessary to run under aarch64 architecture.

[grant-h]

• Bring up Cortex-A machine at first instruction in ARM mode

Hi! Thanks for your hard work! I want to know the specific implementation. Since I have built panda aarch64 and created aarch64 config for avatar and ran S5123 under aar64 architecture. But under aar64 architecture, the codes are 64 bits, how can I convert it to 32 bits. Besides, if I run S5123 under arm architecture, the firmware can run further. I would like to know the necessary to run under aarch64 architecture.

The firmware would need to be emulated using aarch64 but in ARM execution mode. I also had the same question regarding starting in ARM mode instead of aarch64. Someone with more panda/qemu experience can likely quickly answer this one

[Michel-de-Boer-dev]

Hi!
I also looked at this. I injected assembly code to go from EL3 A64 execution state to EL1 (Secure System) mode.

Disabling QEMU A64 mode (and thus start in a32) only works with KVM enabled, which is not what we want. (https://qemu-project.gitlab.io/qemu/system/arm/cpu-features.html)

Setting the AA64nAA32 signal did not work in qemu, nor did setting the reset management register and reboot work.

(If you run into gdb showing wrong register values, that can be fixed by synchronizing the A64 QEMU registers with A32 before reading the registers via gdb)

Once I got more time I will continue with the emulation of the S5123

[Gio-1230]

Hi! I also looked at this. I injected assembly code to go from EL3 A64 execution state to EL1 (Secure System) mode.

Disabling QEMU A64 mode (and thus start in a32) only works with KVM enabled, which is not what we want. (https://qemu-project.gitlab.io/qemu/system/arm/cpu-features.html)

Setting the AA64nAA32 signal did not work in qemu, nor did setting the reset management register and reboot work.

(If you run into gdb showing wrong register values, that can be fixed by synchronizing the A64 QEMU registers with A32 before reading the registers via gdb)

Once I got more time I will continue with the emulation of the S5123

Hi! @Michel-de-Boer-dev

Do you have any ideas to solve it?

I also have the same question regarding starting in ARM mode instead of aarch64 on the Cortex-a55.

Please let me know if you have good ideas.

[MustBastani]

Hi, I looked at this issue and would like contribute. AFAIK, the S5123AP is compiled for ARMv8 architecture in AArch32 state. On the other hand, the ARM target in Panda has not been updated since 2021, and as mentioned in other comments above, the most recent QEMU supports AArch32 only when using the KVM accelerator which might not be an option for our purpose. I tried emulating an S5123AP baseband using the current ARM target (I think it supports ARMv7 ISA). The problem is there are some new instructions that the current ARM target cannot translate. For example, here is an undefined instruction in QEMU debug (in_asm) output:

----------------
IN:
0x4142c866:  b580       push    {r7, lr}
0x4142c868:  f241 70fc  movw    r0, #6140       ; 0x17fc
0x4142c86c:  f2c4 40a2  movt    r0, #17570      ; 0x44a2
0x4142c870:  e8d0 0f8f  undefined

Ghidra disassembler (Language: ARM:LE:32:v8):

4142c866 80 b5           push       {r7,lr}
4142c868 41 f2 fc 70     movw       r0,#0x17fc
4142c86c c4 f2 a2 40     movt       r0,#0x44a2
4142c870 d0 e8 8f 0f     ldab       r0,[r0=>DAT_44a217fc]

From what I have seen, the rest of new instructions that cause the emulator (in ARM mode) to raise undefined instruction exception are coprocessor instructions. Do you have any suggestions on how to proceed with this issue? Thanks.

[mariusmue]

Hi,

Sorry for the delay in responding. Great to hear that you are making progress on it! I wonder if changing the Arm Target for avatar/panda could already solve the issue, as it may bring the correct feature flags to the CPU definition used by panda.

Either way, to add additional instruction, you'd need to modify the target/arm/translate.c file. Also note that this translation and the disassembler of QEMU/Panda are two independent modules; Hence, even if in_asm shows undefined, it may be that the instruction is executed under the hood. Right now, I'm unfortunately rather busy and can't look into this myself; nonetheless, is there somewhere a private/public fork I could look at to help once the time has come?

[MustBastani]

@mariusmue thank you. I agree with updating the Arm Target. I have a private fork. I will push my changes in the next few days and let you know.

[Michel-de-Boer-dev]

I did the following:
Change in the dockerfile:
&& ../configure --disable-werror --target-list=aarch64-softmmu,arm-softmmu,mipsel-softmmu \

Add CPU definitions to panda.
Make sure to use correct panda branch when building (feat/aarch64)
Added cpu config/inits to panda.

See also https://github.com/Michel-de-Boer-dev/panda/tree/AArch64, although it is quite a mess.

I am not sure how many ARMv8.x features are used, but porting all instructions seems to be quite a lot of work. Instead,
what I did was boot in AArch64 EL3 then injected some assembly code to go back to EL1 in AArch32 mode. I am currently researching something else, so I am a bit too busy to continue working on this right now.

If you have any questions feel free to send a DM.

[Hackheadache]

I did the following: Change in the dockerfile: && ../configure --disable-werror --target-list=aarch64-softmmu,arm-softmmu,mipsel-softmmu \

Add CPU definitions to panda. Make sure to use correct panda branch when building (feat/aarch64) Added cpu config/inits to panda.

See also https://github.com/Michel-de-Boer-dev/panda/tree/AArch64, although it is quite a mess.

I am not sure how many ARMv8.x features are used, but porting all instructions seems to be quite a lot of work. Instead, what I did was boot in AArch64 EL3 then injected some assembly code to go back to EL1 in AArch32 mode. I am currently researching something else, so I am a bit too busy to continue working on this right now.

If you have any questions feel free to send a DM.

Thx very much for the tips. I am also researching how to make firmwire support S5xxx shannon firmware.
I have understood your approch, but I can‘t figure out the details, such as how to inject the assembly code, and what the AS code is.
How do you find the code which can switch El3 to El1？ I read the code of u-boot. There are some code which implement this function. Is the codes you used for injecting into the Rtos？
Dude, your current work is really awesome. It gives us a clearly direction. I really hope you can discuss this in detail, and would better paste you injected code.

[Michel-de-Boer-dev]

Hi @liuyb1988,

I mostly found it by reading the ARM documentation and applying it myself.

Injection of the assembly code is done in firmwire itself. When initializing Panda/Avatar, I added a new memory range, copy the assembly code there, then set the program counter to that memory.

However, A LOT of work is needed before S5xxx is fully supported. Given the amount of people interested in this, I am planning on continuing developing and researching this topic with a team after I finish my current baseband research.

Yours sincerely,
Michel

[Hackheadache]

@Michel-de-Boer-dev
Thanks for your respond such soon！
I have understood your approch about injecting code. By the way, could you recommand me some Arm documents which you have read or some specific links？
As matter of a fact, I‘m not a professional Arm developer, and I have stucked in the first step(switch the Arm execution status). The awesome security engineers like you gives me hope to process this wonderful project. I really appreciate for your help！

Yours sincerely

[Michel-de-Boer-dev]

Here are some references:

Some official documents:
ARM Cortex A55 core technical reference manual: https://developer.arm.com/documentation/100442/0200
ARM Architecture reference manual for A-profile architecture: https://developer.arm.com/documentation/ddi0487/latest/

[6] Bare-metal boot code for armv8-a processors, 2022. URL: https://developer.arm.com/documentation/dai0527/a/

Some other useful references:

[39] Arm: Rmr el3, reset management register (el3), 2023. URL: https://developer.arm.com/documentation/ddi0595/2021-06/AArch64-Registers/RMR-EL3--Reset-Management-Register--EL3-.

[31] Turning on arm mmu (flat mapping), 2022. URL: https://witekio.com/blog/turning-on-an-arm-mmu-and-living-to-tell-the-tale-the-code/.

[25] Qemu: Tcg emulation - translator internals, 2022. URL: https://www.qemu.org/docs/master/devel/tcg.html.

[22] Qemu detailed study: Chapter 7, 2022. URL: https://lists.gnu.org/archive/html/qemu-devel/2011-04/msg02362.html.

[24] QEMU internals blogpost, 2022. URL: https://github.com/airbus-seclab/qemu_blog.

[11] Exynos modem 5123, 2022. URL: https://semiconductor.samsung.com/processor/modem/exynos-modem-5123/.

[2] AFL user guide, 2022. URL: https://afl-1.readthedocs.io/en/latest/user_guide.html.

[30] Shannon firmware reversing, 2022. URL: https://github.com/grant-h/ShannonBaseband#getting-started-with-shannon-firmware

[29] Samsung’s shannon baseband tool repository build and test shannon-loader, 2022. URL: https://github.com/grant-h/ShannonBaseband#getting-started-with-shannon-firmware

[8] Breaking band: reverse engineering and exploiting the shannon baseband, 2022.
URL: https://comsecuris.com/slides/recon2016-breaking_band.pdf.

[Hackheadache]

@Michel-de-Boer-dev
I'v read your materials, and it makes me clear to this problem.
However, I‘m trying another way to solve this problem. I modified panda-qemu directly to force cortexA in aarch64 run aarch32 fw(S5XXX). It can execute instructions from fw untill mcr was executed, and an exception was triggered. It caused the qemu start to infinity loop.
I‘v researched the qemu code, but have not solve this problem yet. I found a piece of code in arm-power.c, and some comment seems shows that the current qemu do not support booting an aarch64 cpu in aarch32 mode (https://github.com/qemu/qemu/blob/master/target/arm/arm-powerctl.c:150)
I think if inject code can switch execution status, we can solve it by modifying qemu code. Did you ever think about modify qemu？
The last thing I need to comform with you is that did you pay attation to which line in FW you firmwire reached？and is there any exception happend？
Now, I really wonder whether qemu support this feature or not.
I hope you can respond to me soon so I can decide if I need to continue this task.

[n0123maker]

Edit:
It seems these are instructions from the RAS extension, which got partially implemented in qemu lately. They don't seem to be important at the moment, so I just nop'ed them out for now.

Original message:
With my current configuration I can confirm that accessing the Error Record Select Register (ERRSELR) via
mcr p15,0x0,r0,cr5,cr3,0x1 will cause an exception. This happens very early in the boot process and doesn't seem like expected behaviour because the stack pointers are not yet initialized.
Someone with more knowledge of the architecture can hopefully guide us into the right direction with this one.

[Michel-de-Boer-dev]

Awesome work. Switching to Aarch32 by modifying the qemu code seems like a good idea indeed.

I would love to hear more about your research, or discuss possible ways to team up.
Feel free to contact me on michel-de-boer-dev@proton.me.

[RobertHerreraEECS]

How is the progress on this ticket going? -- I'd be happy to help out however I can to help speed things up since I'm interested in using this tool in the near future. Is the main consesus (If I'm understanding correctly) that the newer generation shannon modems run on aarch32 variant that doesnt play nicely with QEMU?

[Michel-de-Boer-dev]

Hi @RobertHerreraEECS,

The current generation indeed uses aarch32, which is supported in upstream QEMU, and already has been ported partly in my fork. Booting in Aarch32 also kind of works, but not all instructions are supported (especially the armv8.2 stuff). A lot of reversing and porting peripherals is still needed.

I am not sure of the progress from @n0123maker and @Hackheadache. I would love to get into contact with them to ensure we can prevent working on the same thing in parallel, doing double work.

For what would you like to use the tool in the near future?

Yours sincerely,
Michel

[RobertHerreraEECS]

Hi @Michel-de-Boer-dev ,

Okay that sounds good. Yeah as soon the the work that has already been done between the three of you has already been identified I'd definitely be interested in helping with porting.

I'm interested in looking at the newer Shannon 5G modems that seem to not be compatible with Firmwire atm. I'm particularly interested in having some runtime introspection as most of my research is centered around static analysis, which is very slow and painstaking.

[n0123maker]

Hi @Michel-de-Boer-dev,

Unfortunately I haven't been able to make some progress lately. I basically made it until the point the Virtual Memory System is being set up in the boot code. I saw you already parsed some structures regarding this topic.
I would be happy to align and help where possible in the future.

Best regards.