Thumbs Up on Broadcom Wi-Fi RAM State Snapshots

[Jiska Classen]

Hi,

I've been using the Thumbs Up script a lot these days and most of the time it worked perfectly :) I definitely owe you a thank you fax.

Now I tried running the script on a Broadcom Wi-Fi state snapshot and couldn't get it working at all. I think Broadcom Wi-Fi is an ARM Cortex R. The ROM is mapped to 0x0, however, for that specific chip I didn't extract it yet. The RAM holds a major part of the chip's code and is loaded by the operating system driver. For example, it redefines if that chip is running in access point or in station mode. Whenever a crash happens, recent operating systems generate a crash log that contains a full copy of the RAM region. The RAM starts at 0x170000.

To get some of the functions in it recognized at all, I ran idc.plan_and_wait(0x170000,0x300000). When I correctly mark the whole region as RWX RAM section, Thumbs Up doesn't start at all. Thus, I divided it in ROM (despite not being ROM) from 0x170000-0x1fffff and RAM for the remaining part. Then, I get the following output:

[10/06/2020 11:02:26] - Thumbs Up Logger - INFO: Segments, as marked by the disassembler:
[10/06/2020 11:02:26] - Thumbs Up Logger - INFO: Code Segment: 0x170000 - 0x200000
[10/06/2020 11:02:26] - Thumbs Up Logger - INFO: Data Segment: 0x200000 - 0x300000
[10/06/2020 11:02:26] - Thumbs Up Logger - INFO: Processor: ARM, 32bit
[10/06/2020 11:02:26] - Thumbs Up Logger - INFO: Supported ARM code types:
[10/06/2020 11:02:26] - Thumbs Up Logger - INFO: 0 - ARM
[10/06/2020 11:02:26] - Thumbs Up Logger - INFO: 1 - THUMB
[10/06/2020 11:02:26] - Thumbs Up Logger - INFO: Starting the analysis
[10/06/2020 11:02:26] - Thumbs Up Logger - INFO: Phase #1
[10/06/2020 11:02:26] - Thumbs Up Logger - INFO: Tell IDA to analyze all of the code segments
[10/06/2020 11:02:26] - Thumbs Up Logger - INFO: Re-Analyzing code segment: 0x170000 - 0x200000
[10/06/2020 11:02:36] - Thumbs Up Logger - INFO: Phase #2
[10/06/2020 11:02:36] - Thumbs Up Logger - INFO: Observe all code patterns from the initial analysis
[10/06/2020 11:02:36] - Thumbs Up Logger - INFO: There are 7 scoped functions for code type 0
[10/06/2020 11:02:37] - Thumbs Up Logger - INFO: Calibration: Function Prologue Accuracy: 40.00%
[10/06/2020 11:02:37] - Thumbs Up Logger - INFO: Calibration: Function Epilogue Accuracy: 50.00%
[10/06/2020 11:02:37] - Thumbs Up Logger - INFO: Calibration: Function Prologue/Epilogue Accuracy: 40.00%
[10/06/2020 11:02:37] - Thumbs Up Logger - INFO: Testing: Function Prologue Accuracy: 40.00%
[10/06/2020 11:02:37] - Thumbs Up Logger - ERROR: Function Prologue Accuracy is too low, can't continue: 40.00% < 75.00%
[10/06/2020 11:02:37] - Thumbs Up Logger - ERROR: Failed during intelligence gathering, exiting
[10/06/2020 11:02:37] - Thumbs Up Logger - ERROR: Encountered an error during the analysis

Is there any chance to force the script running nonetheless? Do you think the results were still meaningful or is the whole setup of code in RAM mixed with data (yes, lol...) just not what Thumbs Up was made for?

What you can see here is how it looks like after loading it into IDA, with the marker being set to the border between what I defined as "ROM" (actually also being RWX) and RAM.

If you want to test it on your own, I also added the binary :) It's from a BCM4377.
SoC_RAM.bin.zip

[Eyal Itkin]

Hi,

Thanks for the kind words and for the very detailed bug report. I've recreated the issue in my setup and just pushed a fix to it in pull request #49. There are actually 2 different topics here.

Bug Fix - Properly disabling a given code type:

The vast majority of the code is in Thumbs mode (code type 1), but IDA still recognized a few ARM code snippets (code type 0). Since there are only a few of them, I can't analyze them correctly to estimate how a proper ARM function should start/end. The python code that handles disabling the logic for this code type had a bug, and it stopped the entire analysis, instead of continuing on only with logic for Thumb mode.

This bug was fixed, and it should now work properly, as I've tested it on my setup.

Mixed code and data:

At the current moment, Thumbs Up deploys different logic for code segments and data segments, as using IDA's idc.plan_and_wait on mixed code segments produces poor results. This also enables better decision making about global strings and function pointers, that one would mainly expect to appear in data segments.

My experience from a MIPS binary that had data at the end of its code segment, is that the quality of the analysis will be damaged. Hence, working on mixed code/data segments is a current limitation of Thumbs-Up, and would only be solved if an additional estimator will be added to predict if the current code lines are "code" or "data", which will significantly complicate the code.

Conclusion

The fix was now merged to master, and it should solve the bug you've reported. If the issue persists, feel free to re-open this ticket.