[BUG] Debug symbols stripped false positive

[didix21]

ENVIRONMENT

OS and Version: macOS Sequoia 15.3.1
Python Version: 3.12.9
MobSF Version: v4.3.0

EXPLANATION OF THE ISSUE

When running a static analysis using the Docker container (as recommended in the documentation), MobSF is reporting false positives for checking if debug symbols are stripped from binaries and dynamic libraries. Upon inspecting the source code at:

Mobile-Security-Framework-MobSF/mobsf/StaticAnalyzer/views/common/binary/macho.py

Line 22 in ae34f7c

# Works only on MacOS

, the comment indicates that the check is intended for MacOS only. It is unclear whether this OS-specific behavior is clearly documented, and if not, it might be worth adding a note in the documentation.

Additionally, if the analyzed framework contains a symbol like:

also reports a false positive. It appears that the code attempts to handle this scenario in a try-catch block (see

Mobile-Security-Framework-MobSF/mobsf/StaticAnalyzer/views/common/binary/macho.py

Line 278 in ae34f7c

stripped_sym = 'radr://5614542'

), but only in cases where an exception is thrown. Is this the expected behavior?

This can be reproduced in master also.

P.D: This issue is related to this: #1917 (comment).

[github-actions]

👋 @didix21
Issues is only for reporting a bug/feature request. For limited support, questions, and discussions, please join MobSF Slack channel
Please include all the requested and relevant information when opening a bug report. Improper reports will be closed without any response.

[nickkhg]

Seeing the same issue, spent hours trying to figure out why my framework symbols weren't stripped only to realise they actually were stripped when checking the frameworks with rabin2. Is this being investigated?

[rustaska]

TL;DR: The fix is quite simple, but first we should agree on what symbols we want to check for. The breaking changes in LIEF did not help to make things better.

There are two problems:

1. The author of the fixed version did not fully understand what a debug symbol is and how it is defined. So the code does now some filtering that is not necessary IF you only want to detect debug symbols. The code does also check for some other symbols, don't know why this was done since we (and OWASP MASTG) are only interested in stripping debug symbols. The problem with stripping symbols is you can have different settings for stripping: only debug symbols, undefined symbols, local symbols etc. But you can also produce a binary that has "no symbols" in the first place. As I already said in issue 1917: First there needs to be a consensus on what should be checked and then implementation can happen. But looking at the commits I see that the "what" has shifted back and forth.
2. LIEF had a breaking change some time ago and the meaning of i.type changed. The code then failed because of this change in LIEF. To counter this, there was a commit to change it to i.type.value. But this does not return the "real" type as it did before, this returns the type defined in N_TYPE of the n_type field but we need the entire n_type field to determine if it's a debug symbol or not (See below why). So the code should use the raw_type and then just apply the bitmask 0xe0 again to determine if it is a debug symbol or not, without all the additional filtering stuff. Why this bitmask? Because this represents the first 3 bits of 8 bits and if you don't believe me than believe Apple https://github.com/apple-oss-distributions/xnu/blob/main/EXTERNAL_HEADERS/mach-o/nlist.h#L117.

To clear things up on debug symbols and justify why the bitmask is enough to determine a debug symbol:
What defines the type of a symbol? Let's look at the macho source code starting at https://github.com/apple-oss-distributions/xnu/blob/main/EXTERNAL_HEADERS/mach-o/nlist.h#L92

The n_type field has the type uint8_t (so it has 8 bits) and contains four fields:

• N_STAB: first 3 bit
• N_PEXT: next 1 bit
• N_TYPE: next 3 bits
• N_EXT: final 1 bit

The confusing part might be that the n_type field has a field in it called N_TYPE, but it is not the same. When reading all this, keep a close eye if I write it in caps or not to understand which field I'm referencing.

• If any of the first 3 bits out of total 8 bits of n_type is set (so any of the N_STAB bits), it is a debug symbol and then all other fields in n_type are ignored. Then the rest of the bits are there to define the type of the debug symbol. The possible values can be found at https://github.com/apple-oss-distributions/xnu/blob/main/EXTERNAL_HEADERS/mach-o/stab.h.

• If none of the first 3 bits out of total 8 bits of n_type are set, the N_TYPE field of n_type is NOT ignored and defines the symbol type. The possible values are then defined in https://github.com/apple-oss-distributions/xnu/blob/main/EXTERNAL_HEADERS/mach-o/nlist.h#L132

[ajinabraham]

Thanks for the detailed summary. There has been a lot of rework and back and forth changes regarding this as you noticed. I will do some research on this and see how this can be addressed when I get some time.