5.1 Firmware collection and unpacking

Typically, IoT firmware can be downloaded from vendor websites, captured during OTA updates, extracted from hardware, or obtained from third-party archives [27]. We successfully collected 12,893 firmware samples from 11 vendors through web crawling.

To conserve storage space, vendors compress firmware images in various formats (e.g., .BIN, .ZIP). We use binwalk [49] to unpack firmware images and extract their file systems. However, there is an issue of incomplete extraction when binwalk extracts the JFFS2 and SquashFS file systems. Referring to the solutions proposed in FirmSec [44], we use Jefferson and Sasquatch to replace jffsdump and unsquashfs, respectively, in binwalk, thereby achieving complete extraction of the JFFS2 and SquashFS file systems.

We successfully extracted 8,192 file systems from the 12,893 IoT firmware collected.

5.2 Border binary collection

When IoT firmware interacts with the outside world, it relies on various network protocols. Therefore, we analyzed the typical protocols used by IoT firmware, including UPnP, RTMP, SMTP, PPP, SOAP, HNAP, SSDP, CWMP, HTTP, MQTT, and DAAP. By analyzing known network parsing functions massively in border binaries, we found that border binaries usually have the following characteristics:

• Border binaries usually call specific APIs to receive and parse user input data, such as the examples of RECV_API in Table 1;
• Border binaries usually use specific strings that are correlated with the protocol type, such as the examples of COMM_STR in Table 1;
• Border binaries use many APIs related to string comparison, string search, and string conversion to call the corresponding APIs, such as the examples of STR_API in Table 1.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Table 1. List of features and their examples.

https://doi.org/10.1371/journal.pone.0329469.t001

Based on the analysis of border binary features, we integrated the network-encoding strings (refer to the COMM_STR examples in Table 1) related to these protocols into Karonte’s list of network-encoding strings. Additionally, border binaries often call special APIs to process external input data. Therefore, we collected a list of such APIs (refer to the RECV_API examples in Table 1). Given that Karonte does not use the RECV_API feature, we also optimized Karonte’s feature extraction process to successfully introduce the RECV_API examples. Finally, we modified the calculation score ps_j of the network parsing function in Karonte [11], and the new score newps_j calculation is shown as:

(1)

Through the optimized Karonte, we obtained many candidate network parsing functions from 8,192 firmware samples and then determined whether the binary executables in which they are located are border binaries on the basis of the candidate network parsing functions.

To maximize the accuracy of the samples, we rigorously screened and confirmed each border binary by reverse engineering. Our analysis revealed three primary issues:

• Similarity across firmware versions and series. The binary executables in most firmware samples of the same models and different versions were roughly the same (e.g., D-Link DCS930l_v109 and D-Link DCS930l_v111), and even some firmware samples of the same series and different models were also largely similar (e.g., D-Link DIR-890L and D-Link DIR-895L).
• False positives. According to the verification results, some candidate border binaries were false positives that did not meet the definition of border binaries.
• False negatives. Through empirical analysis, we identified several other border binaries in addition to candidates. There is no obvious network parsing functionality in these border binaries, which are implemented by multiple functions (For example, the network parsing functionality of the binary upnp in Linksys E800-v1.01.004 firmware consists of several functions such as parse_uri, parse_csghdr, soap_comtrol, soaps_process, etc).

Finally, by removing duplicate and false-positive candidate functions and adding various manually confirmed network parsing functions, a total of 1,307 network parsing functions were selected from 320 representative firmware samples from 67 different device series from 10 vendors over three months. These network parsing functions correspond to 1,103 different border binaries. Notably, some border binaries contain more than one network parsing function.

5.3 MDFM

In the process of constructing the border binary dataset, we have summarized two viewpoints regarding border binary features: Firstly, network parsing functions are crucial features of border binaries, and binaries that possess network parsing functions can be essentially identified as border binaries. Secondly, a few border binaries lack specific network parsing functions, as some binaries do not have relatively independent network parsing functions and instead depend on a combination of multiple functions to fulfill network parsing, which is less common.

Based on the aforementioned insights, we believe that an effective feature model for border binary should have the following descriptive abilities:

• The ability to characterize network parsing functions, in order to better characterize border binary features containing explicit network parsing functions.
• The ability to characterize the overall binary features, while also considering the border binary features without obvious network parsing functions.
• The feature weight of network parsing functions should be heavier than the features of the overall binary, in order to reflect the situation where the probability of border binary without explicit network parsing functions is relatively small.

On the basis of the above three guiding strategies, we constructed a multidimensional feature model (MDFM) for comprehensively characterizing border binaries. MDFM = []. The MDFM is composed of 15-dimensional vectors, which include program-level behavioral features () and semantic features (), as well as function-level structural features (, ), behavioral features (), and semantic features ().

The feature selection of MDFM is grounded in two perspectives. First, the network parsing function serves as a key feature of the border binaries, as it directly reflects the interaction behavior between the binaries and the external network. Second, while some border binaries may lack explicit network parsing functions, they often depend on multiple functions to collectively achieve network parsing functionality. As a result, MDFM characterizes border binaries from multiple dimensions through program-level and function-level features, ensuring the model comprehensively covers all possible border binaries.

The 15-dimensional features characterize border binaries from different perspectives and exhibit the following complementary relationships:

• Program-level features ( and ) provide a global perspective, aiding in identifying the binary’s overall behavior and semantics. For example, can preliminarily assess whether the binary may be a border binary by counting the number of APIs related to external input in the function import table.
• Function-level features () provide a localized perspective, aiding in identifying specific network parsing functions.
• Feature weight allocation. In the feature of border binaries, function-level features are assigned higher weights, reflecting the importance of network parsing functions in border binaries, while program-level features act as supplementary components to ensure that the model encompasses all possible border binaries.

By utilizing the complementary design of multidimensional features, MDFM accurately and comprehensively characterizes border binary features, enhancing the accuracy and robustness of border binary detection. A detailed list of the feature vectors and their corresponding descriptions is provided in Table 2.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Table 2. Feature vectors of the MDFM and their corresponding descriptions.

https://doi.org/10.1371/journal.pone.0329469.t002

: Number of APIs in binaries related to receiving external input (RECV_API). Since APIs related to receiving external input serve as direct credentials for border binaries to interact with external networks, we analyzed the function import table of border binaries and discovered that they typically call specific APIs when receiving and processing external input data. Therefore, we present examples of RECV_API, as shown in Table 1.

: Number of strings in binaries related to network communication (COMM_STR). The communication of IoT devices involves four main stages: pairing, binding, authentication, and control [50]. The communication-related strings (such as HTTP, MQTT, etc.) are important indicators of the border binaries. When border binaries interact with the outside world, they usually need to match various hardcoded strings related to communication to process requests accurately. Therefore, we provide examples of COMM_STR, as illustrated in Table 1.

: Number of basic blocks in the function. Due to the fact that network parsing functions are responsible for handling data received from external sources. Their internal workings are usually complex, comprising many control flows and jump operations. Therefore, if the number of basic blocks in a function is within a certain threshold range, then the function is likely to be a network parsing function of the border binary to implement processing functionality.

: Number of branches in the function. Conditional branch statements are commonly used to address branching logic and loop logic, which represent the control flow complexity of a function. Since network parsing functions are typically implemented as the protocol’s state machines and must adhere to the communication rules of network services to influence control flow decisions, they are expected to contain a certain number of conditional branch statements. Therefore, we consider the number of conditional branch statements in a function as a structural feature of border binaries.

: Number of APIs in the function related to receiving external input (NET_API, I/O_API, and ENV_API). Considering that network parsing functions call APIs related to processing inputs from external sources when handling external data. Therefore, we consider the number of APIs that receive external input in the function as behavioral features of the border binary. Furthermore, inspired by SDCFM [32], we classified RECV_API to better characterize the functionality of these functions. The number of network communication-related APIs (NET_API) is denoted as . The number of standard I/O-related APIs (I/O_API) is denoted as . The number of environment-related APIs (ENV_API) is denoted as . Examples of NET_API, I/O_API, and ENV_API are given in Table 1.

: Number of APIs in the function related to manipulating strings (STRCMP_API, STROP_API, STRSEARCH_API, and STRCONVER_API). When border binaries interact with the outside world, network parsing functions need to validate the input data (for example, check the length, type, and range), which involves data format conversion, string splitting, merging, matching, and replacing operations. Therefore, we consider the number of APIs related to string operations in the function as a behavioral feature of the border binary. The number of string comparison-related APIs (STRCMP_API) is denoted as . The number of string operation-related APIs (STROP_API) is denoted as . The number of string search-related APIs (STRSEARCH_API) is denoted as . The number of string conversion-related APIs (STRCONVER_API) is denoted as . Examples of STRCMP_API, STROP_API, STRSEARCH_API, and STRCONVER_API are given in Table 1.

: Number of strings in the function related to network communication (AUTH_STR, HTTP_STR, MQTT_STR, and CONN_STR). In border binaries, network parsing functions compare the received data with a preset list of network-encoding strings stored in memory, according to the requirements of the relevant protocol. Therefore, we take the number of communication-related strings in the function as a semantic feature of the border binary. The number of authentication-related strings (AUTH_STR) is denoted as . The number of HTTP request-related strings (HTTP_STR) is denoted as . The number of MQTT request-related strings (MQTT_STR) is denoted as . The number of Client/Server connection-related strings (CONN_STR) is denoted as . Examples of AUTH_STR, HTTP_STR, MQTT_STR, and CONN_STR are given in Table 1.

We utilized the reverse engineering tool Radare2 [51] to extract corresponding features from the control flow and data flow of the binary. The code for feature extraction is shown in Algorithm 1. Suppose that binary set B contains the number of b is n, the average number of functions in each binary b is m, and k is the average number of feature extraction operations in each function f. The time complexity of Algorithm 1 mainly consists of the following parts: (1) outer loop: traversing each binary b in binary set B, with time complexity of O(n); (2) Inner loop: Traversing each function f in each binary b, with time complexity of O(m); (3) Internal operation: performing feature extraction on each function f, including counting the number of basic blocks, branch statements, API calls, and string matches. Assuming the average number of these operations in each function f is a constant k, the time complexity of the internal operations is O(k). Therefore, the total time complexity of Algorithm 1 is .

Algorithm 1. Feature extraction.

An example. We use the binary httpd and its network parsing function from the firmware RT-AC51U of the ASUS vendor to demonstrate a sample: [asus_RT-AC51U/httpd, main, 18476, 16, 46, 263, 178, 24, 11, 0, 1, 12, 8, 0, 61, 35, 36, 3]. Note that 174088 is the address of the main function. The following values are , and , which represent the feature vectors for the MDFM of the border binary httpd.

5.4 Preprocessing

To prevent any single feature from disproportionately influencing the detection model due to variations in magnitude, proper preprocessing of feature vectors is important [52]. We first check the data type of the feature vectors, convert them into numerical values, and check for any missing values. For missing values, we fill them with 0. Then, we attempted five common preprocessing techniques: StandardScaler, MinMaxScaler, MaxAbsScaler, RobustScaler, and PowerTransformer (abbreviated as PowerTrans).

Table 3 shows the results of applying these five preprocessing methods to the binary httpd and its function main in the ASUS RT-N15U firmware, where PowerTransformer adopts the Yeo–Johnson transform. StandardScaler is sensitive to outliers and transforms the original feature 263 to 0.9, causing extreme values to have a significant effect on the results. MinMaxScaler and MaxAbsScaler change both the original features 46 and 1 to 0.01, losing the original range of the data. The reason why MinMaxScaler and MaxAbsScaler yield the same result is that when all values in the dataset are nonnegative, the maximum absolute value is the maximum value, and the denominators of the two calculation methods are the same. RobustScaler scales the original feature 263 to 2.60 using the median and interquartile range (IQR) to reduce the impact of outliers on the data distribution, however some data remain unchanged. PowerTransformer can transform nonnormally distributed data into a form closer to a normal distribution, improving the distribution characteristics of the data.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Table 3. Preprocessing results of a feature vector for httpd in the ASUS RT_N15U firmware.

https://doi.org/10.1371/journal.pone.0329469.t003

Therefore, we used the Yeo-Johnson transformation in PowerTransformer [18] to standardize the representation feature vectors. Yeo–Johnson transformation can handle various forms of data, is not affected by extreme values, and allows the adjustment of parameters to find the most suitable transformation form for specific data. The Yeo–Johnson equation is shown as:

(2)

(3)

(4)

(5)

where X represents the original data, Y represents the transformed data, and λ is the transformation coefficient. The Yeo–Johnson method can be applied to automatically select an appropriate value of λ according to the features of the data. This transformation method not only adjust the data distribution characteristics but also improve the data analyzability and stability of the model to provide higher-quality feature representation for subsequent machine learning model processing.

5.5 Detection model construction

Ensemble learning (EL), as an advanced strategy in machine learning, integrates multiple methods through three main techniques: bagging, stacking, and boosting. Compared with a single model, ensemble learning methods can often achieve better performance and stronger adaptability in practical applications [53]. In our research, we trained and validated 13 typical machine learning algorithms: logistic regression (LR), SVM, decision tree (DT), RF, adaptive boosting (AdaBoost), XGBoost, K-nearest neighbors (KNN), multilayer perceptron (MLP), ridge regression (Ridge), LightGBM, CatBoost, gradient boosting decision tree (GBDT), and naive Bayes (NB). By training and validating these 13 typical machine learning algorithms, we aimed to find the optimal ensemble learning method.

To accurately identify border binaries in the firmware, we adopted stacking technology. This EL method combines the prediction results of base learners and increases the model prediction accuracy and robustness through meta-learner retraining. We found that XGBoost, LightGBM, CatBoost, and RF achieved the best prediction performance among the 13 machine learning algorithms that we trained and validated (see the corresponding test RQ2 in Sect 6.6). Therefore, we chose the XGBoost, LightGBM, and CatBoost models as the base learners and the RF model as the meta-learner to output the final XLC-R prediction.

The objective function of the base learner XGBoost consists of a loss function and a regularization term, as shown in Eq 6. Here, y_i represents the true value of the i-th feature vector, denotes the predicted value of the i-th feature vector, n is the number of feature vectors, is the loss function, and is the regularization term.

(6)

Define , where T is the number of leaf nodes in the tree, and w_j is the weight of leaf node j. For the t-th tree, the optimal split point is determined by Eq 7, where g_i and h_i are the first-order and second-order gradient statistics, respectively.

(7)

The objective function of the base learner LightGBM is similar to , but it uses a histogram-based algorithm to find the optimal split point. The construction of the histogram is shown in Eq 8, where H(b) is the value of the b-th histogram, and g_i is the gradient value of the i-th feature vector.

(8)

The objective function of the base learner CatBoost is also similar to , but it can handle categorical features and use ordered boosting to reduce the model’s sensitivity to the order of training data. CatBoost reduces gradient bias through the ordered boosting strategy. For each feature vector i, its gradient is calculated based on the model predictions of the previous i–1 feature vectors, as shown in Eq 9.

(9)

CatBoost uses target encoding to handle categorical features. For a categorical feature x_j, its encoded value is calculated as shown in Eq 10, where is the indicator function.

(10)

The meta-learner RF constructs multiple decision trees and determines the final prediction through voting. For the prediction of a single tree, given the input feature x_i, the predicted value of a single decision tree is shown in Eq 11, where f_k (x_i) is the predicted value of the k-th tree.

(11)

RF uses Eq 12 to determine the final prediction through majority voting, where K is the number of decision trees.

(12)

The final prediction of XLC-R can be expressed as Eq 13.

(13)

Where , , and represent the predictions made by the XGBoost, LightGBM, and CatBoost models, respectively; denotes the prediction made by the RF model; and is the final prediction result. Notably, we utilized a grid search to determine the optimal settings for XLC-R during training. Please refer to Sect 6.2 for the specific parameter settings.

Algorithm 2 demonstrates the pseudocode for the stacking method applied in XLC-R. XLC-R begins by training each base learner (XGBoost, LightGBM, and CatBoost) on the training data X_train and y_train, which generates the prediction results for the training data (train_pred) and the test data (test_pred). Then, the predictions from the base learners are stacked together to create the meta-features and . Next, the meta-learner RF is trained using the meta-features and the labels y_train. Finally, the trained meta-learner is utilized to predict the meta-features , yielding the final result y_pred.

Algorithm 2. XLC-R Stacking ensemble learning.

6.1 Implementation

First, we developed a crawler tool for obtaining firmware based on the Scrapy framework and implemented firmware file system extraction by extending binwalk [49]. Then, a feature extraction tool was developed based on Radare2 [51] to extract the behavioral and semantic features of binary executables, as well as the structure, semantics, and behavioral features of functions. Finally, the detection model was constructed via the scikit-learn [54], XGBoost [19], LightGBM [20], and CatBoost [21] libraries. The prototype system is implemented in python, with a total of approximately 2,580 lines of code.

6.2 Experimental setup

All experiments were conducted on a server with an Intel^® Xeon(R) Silver 4214 CPU @ 2.2.GHz, 256GB RAM, 5.0TB usable HDD, and two NVIDIA V100S GPUs. The server operating system runs on the Ubuntu 22.04 AMD64 operating system, and the runtime environment includes Python 3.8, Binwalk 2.1.1, and Radare2 5.9.1.

The configuration adopted by XLC-R was as follows: XGBoost used 100 estimators, with an evaluation metric of logloss, a learning rate of 0.1, and a random state of 42; LightGBM used 100 estimators, with a learning rate of 0.1, a maximum depth of -1 and a random state of 42; CatBoost used 100 estimators, with a random state of 42; and RF used 20 estimators, with a maximum depth of 4, and a random state of 42.

6.3 Dataset

Dataset I: We adopted the firmware collection and unpacking method described in Sect 5.1 to obtain 8,192 file systems and utilized the border binary collection method from Sect 5.2 to filter out 320 representative border binaries from 67 different device series across 10 vendors. The specific firmware details are outlined in Table 4, which displays the vendor, device series, number of device series (# Series), average number of files per firmware filesystem (Avg # File), average number of executable binaries per firmware (Avg # Bin), number of firmware models (# FirmType), number of network parsing functions (# NetFunc), and number of collected border binaries (# Border). This dataset serves as a sample set of feature vectors extracted from border and non-border binaries in real-world firmware for training and evaluating the detection model.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Table 4. Details on the firmware details used to build Dataset I.

https://doi.org/10.1371/journal.pone.0329469.t004

For the firmware listed in Table 4, we identified and collected 1,307 network parsing functions (the method is detailed in Sect 5.2. These functions are associated with 1,103 different border binaries. The remaining functions are associated with non-border binaries. Then, we extracted and constructed feature vectors for both border and non-border binaries via the MDFM. Program-level features ( and ) can be obtained through whole binary analysis, but the function-level features differ. The function-level features of the border binaries directly correspond to the feature vectors of any network parsing functions within them. Since a border binary may have multiple parsing functions, its feature vector can match more than one function. Thus, 1,307 feature vectors were constructed from the 1,103 border binaries. The function-level feature of the non-border binaries was constructed by selecting any one of the functions contained in it, and considering the distribution of feature values of the function, 5,814 feature vectors were selected from the feature vectors of all the non-border binaries.

We used 1,307 feature vectors corresponding to the network parsing functions as positive samples, with a label of 1. The selected 5,814 feature vectors were used as negative samples, with a label of −1. This sample setup aligns with the observation that in practice, the number of border binaries is less than the number of non-border binaries. Finally, we constructed Dataset I, which contains 7,121 feature vectors.

Dataset II: A set of 49 firmware images based on Linux OS and sourced from Karonte [11] was used as Dataset II. This dataset was utilized for comparison with the baseline methods Karonte and SaTC. Table 5 provides detailed information in Dataset II, including the vendor, device series, number of firmware images (# Firm), architecture (Arch), number of files in the file system (# File), number of executable binaries (# Bin), and average number of border binaries per executable binary (Avg # Border).

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Table 5. Dataset II.

https://doi.org/10.1371/journal.pone.0329469.t005

6.4 Baseline

We chose Karonte [11] and SaTC [12] as the baseline methods. Karonte represents the first method for identifying border binaries through network parsing functions, whereas SaTC identifies border binaries via front-end string matching. These two methods represent two different technical routes. Furthermore, Karonte and SaTC are commonly used as baselines in border binary detection research [4, 10, 14, 24]. Therefore, we also chose Karonte and SaTC as baseline methods for comparison.

6.5 Evaluation metrics

We evaluated BBDetector via five indicators: precision (), recall (), F1 score (), receiver operating characteristic (ROC), and the area under the ROC curve (AUC), where TN, FN, TP, and FP are the numbers of true-negative, false-negative, true-positive, and false-positive samples, respectively. The reason we chose these five metrics is as follows:

Precision (Pre) refers to the ratio of the number of border binaries identified correctly to the total number of instances predicted as border binaries. A higher precision indicates that the model is more accurate in its predictions regarding border binaries, resulting in a reduced likelihood of false positives. Reducing false positive rates is crucial in security analysis since incorrect predictions can lead to unnecessary resource consumption. Thus, precision is a key metric for evaluating the effectiveness of border binary detection methods.

Recall (R) refers to the proportion of border binaries correctly identified by the model among all border binaries. The higher the recall is, the stronger the performance of the detection model, and the lower the likelihood of false negatives. This is essential for ensuring comprehensive security analysis of border binaries.

F1 score (F1) is the weighted average of precision and recall, providing a balanced metric for evaluating the overall performance of a model. Balancing precision and recall is crucial in practical applications, as a model with high precision but low recall may overlook important cases, while a model with high recall but low precision may produce a significant number of false positives.

The ROC curve is the receiver operating characteristic curve. The closer the ROC curve is to the coordinate (0,1), the better the performance of the learner. The AUC value is the area under the ROC curve, and higher AUC values, the stronger the model’s ability to distinguish between border and non-border binaries.

6.6 Experimental results and discussion

RQ1: Effectiveness of BBDetector.

To verify whether BBDetector can be used to detect border binaries, we trained and validated it in Dataset I. To ensure the effectiveness of the training process and the rationality of the validation process, we selected 80% of the border and non-border binary samples as the training sample set and the remaining 20% of the samples as the validation sample set.

In the training phase, the training sample set is used independently to train three base learners (XGBoost, LightGBM, and CatBoost). After training, each base learner generates its prediction results, which are then combined into a new feature vector and fed into a meta learner (RF) for training, resulting in the final XLC-R model. The goal of the meta-learner is to learn how to effectively integrate the predictions of the three base learners to form a more robust detection model, as described in Sect 5.5. The rationality analysis of the construction for XLC-R is presented in response to RQ2.

To illustrate the improved detection effect of XLC-R over those of the individual base learners, we also evaluated the standalone performance of the base learners. The precision, recall, and F1 score results for the three base learners and XLC-R on the validation set are shown in Table 6. The ROC curve and AUC values are shown in Fig 3.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 3. ROC curves of the three base learners and XLC-R on the validation set.

https://doi.org/10.1371/journal.pone.0329469.g003

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Table 6. Precision, recall, and F1 score results of the base learners and XLC-R on the validation set.

https://doi.org/10.1371/journal.pone.0329469.t006

Table 6 shows that the precision, recall, and F1 score results for XLC-R were 94.98%, 91.02%, and 92.84%, respectively. The results of XLC-R exceed those of the three base learning methods. Therefore, XLC-R substantially outperformed the three base learners in classification. This result is attributed to the stacking method’s ability to reasonably integrate the prediction results of each base learner to achieve better performance.

Fig 3 shows that the ROC curve for XLC-R was closer to the coordinate (0, 1), and that AUC value was 0.99. The AUC values for XGBoost, LightGBM, and CatBoost were 0.96, 0.96, and 0.97, respectively. XLC-R has the highest AUC value, indicating it possesses the strongest ability to distinguish between border and non-border binaries.

The above tests reveal that BBDetector can effectively detect border binaries, with high precision, recall, F1 score, and AUC values.

RQ2: Detection model rationality.

BBDetector uses a stacking method for border binary detection, leveraging model complementarity to enhance the recognition of intricate data patterns. To construct effective stacking models, we assessed 13 known machine learning algorithms (Sect 5.5) in terms of classification efficacy.

In this test, 80% of the border and non-border binaries from Dataset I were allocated to the training set, with the remaining binaries used for validation. Using the default configuration, the precision, recall, and F1 score values of the 13 machine-learning models on the validation set are shown in Fig 4.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 4. Precision, recall, and F1 score values of 13 established machine learning models on the validation set.

https://doi.org/10.1371/journal.pone.0329469.g004

The result reveals that RF, XGBoost, LightGBM, and CatBoost obtain the highest precision and F1 score values among the 13 machine learning models tested. The F1 score values were 86.29%, 89.40%, 88.72%, and 87.33%, respectively. Importantly, the F1 score values for XGBoost, LightGBM, and CatBoost surpass that of RF.

Since the performance of each base classifier directly influences the performance of the meta-classifier, the classification results of the meta-learner are usually better when the classification results of the base classifier are superior classification outcomes. Consequently, the final detection model was constructed based on RF, XGBoost, LightGBM, and CatBoost. XGBoost, LightGBM, and CatBoost, which had the highest F1 scores, were selected as the base learners, whereas RF served as the meta-learner. The effectiveness of XLC-R has been validated in response to RQ1.

RQ3: Feature selection rationality.

The LASSO regression method was used to evaluate the rationality of the 15-dimensional features in MDFM. LASSO regression can automatically identify important features without manual intervention or complex feature selection procedures. Feature selection is achieved by effectively shrinking the coefficients of less important features to zero [55].

We used the LassoCV class in the scikit-learn library, a LASSO regression method with cross-validation, to screen and test the initial 15-dimensional features. Regarding the parameter configuration, we implemented 10-fold cross-validation to optimize the regularization parameter alpha, and set the random state to 42 for obtaining more reliable analysis results.

The inputs of the meta-learner are the prediction results of the base learners rather than a 15-dimensional feature vector. That is, the feature selection process is only used directly in the training processes of the three base learners (XGBoost, LightGBM, and CatBoost). Therefore, we trained and validated the base learners. For Dataset I, the test results are shown in Fig 5.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 5. Feature importance measurements for XGBoost, LightGBM, and CatBoost.

https://doi.org/10.1371/journal.pone.0329469.g005

The results show that none of the 15-dimensional features were eliminated, indicating the significance of each dimensional feature in the MDFM for border binary detection. In XGBoost, the feature weights assigned to , , , and are quite small, whereas and contribute more significantly. In LightGBM, the feature weights assigned to , , and are relatively small, while , , , , and have relatively larger weights. In CatBoost, the feature weights assigned to , , , and are relatively small, while , , and carry relatively larger weights.

The feature weights reflect their effects on model predictions, with higher weights indicating greater influence. The different feature weights reveal that each dimensional feature of the MDFM contributes uniquely to different models. For example, APIs related to string comparison and strings related to HTTP requests contribute significantly, as they are crucial for validating request data through network parsing functions in border binaries. In contrast, the contributions of APIs related to string conversion and strings related to MQTT requests are relatively small, probably because the string conversion-related APIs are used only for auxiliary functionality in the network parsing function, and MQTT request-related strings are involved only in establishing connections rather than in the main part of actually processing the network input. In short, these 15-dimensional features of the MDFM are reasonable.

RQ4: Comparison with existing methods.

To further evaluate the advantages of BBDetector, we compared it to the baseline method in Sect 6.4.

Table 7 shows the detection results of Karonte, SaTC, and BBDetector in Dataset II, along with detailed information regarding the detected firmware, including the device vendor, number of firmware samples (#Firm), number of files in the firmware (#File), number of binaries (#Bin), total number of instances predicted as border binaries (#P), number of border binaries identified correctly (#TP), the ratio of the number of border binaries identified correctly to the total number of instances predicted as border binaries (Pre), and the fraction of the total border binaries that the model can correctly identify as border binaries (R). Because it was not entirely certain whether all border binaries in the firmware were detected, the set of border binaries detected by the three methods was treated as the actual set of border binaries for the corresponding firmware.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Table 7. Details on border binaries detected by Karonte, SaTC, and BBDetector in Dataset II.

https://doi.org/10.1371/journal.pone.0329469.t007

The results show that Karonte, SaTC, and BBDetector identified 57, 83, and 185 border binaries in Dataset II, respectively. BBDetector detected 3.25 times and 2.23 times more border binaries than Karonte and SaTC did, respectively. Moreover, the precision rates of Karonte, SaTC, and BBDetector for 49 firmware were 31.32%, 56.46%, and 57.81%, respectively, and the recall rates were 25.11%, 36.89%, and 81.50%, respectively. Obviously, the precision and recall of BBDetector were the highest. Therefore, BBDetector outperformed Karonte and SaTC in border binary detection.

In Fig 6, we visually compare border binaries detected by Karonte, SaTC, and BBDetector in Dataset II.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 6. Comparison of border binaries detected by BBDetector and the baseline methods in Dataset II.

https://doi.org/10.1371/journal.pone.0329469.g006

As shown in Fig 6, Karonte identified 31 border binaries in D-Link firmware images, 17 in Netgear firmware images, 4 in TP-Link firmware images, and 5 in Tenda firmware images. SaTC identified 10 border binaries in D-Link firmware images, 43 in Netgear firmware images, 21 in TP-Link firmware images, and 9 in Tenda firmware images. BBDetector identified 39 border binaries in D-Link firmware images, 92 in Netgear firmware images, 38 in TP-Link firmware images, and 16 in Tenda firmware images. BBDetector successfully detected the majority of the border binaries found by both Karonte and SaTC. Taking 9 firmware samples of D-Link as an example, compared with Karonte, BBDetector detected 22 border binaries that were detected by Karonte and an additional 17 more border binaries than Karonte. Compared with SaTC, BBDetector detected 8 border binaries detected by SaTC and an additional 31 border binaries. Overall, BBDetector successfully detected 9 border binaries that Karonte and SaTC could not detect.

However, BBDetector outputted some false negatives for the 9 firmware of D-Link, compared with Karonte and SaTC. Karonte detected 9 border binaries that BBDetector missed. This discrepancy may be because Karonte characterizes and detects border binaries only based on the HTTP protocol, whereas BBDetector covers multiple protocol features, which may weaken the feature characterization ability of HTTP protocol-related border binaries, resulting in a lower recognition performance than that of Karonte for HTTP protocol-related border binaries. SaTC identified 2 border binaries that BBDetector missed, possibly because SaTC detects shared strings between the front and back ends, covering all strings in the front end of the firmware. BBDetector uses protocol universal string features, so it is not sensitive to personalized string features, but this design helps ensure its effectiveness.

Table 8 shows the detection results for 8 representative firmware samples, where #TP represents the true number of border binaries and Border Set represents the set of border binaries.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Table 8. Detailed information regarding the border binaries obtained by BBDetector and baseline methods for 8 representative firmware samples.

https://doi.org/10.1371/journal.pone.0329469.t008

As shown in the table, Karonte identified 11 border binaries across 8 firmware images, SaTC identified 13 border binaries, and BBDetector identified 28 border binaries. BBDetector detected 15 more border binaries than SaTC. Notably, Karonte did not detect any border binaries in the D-Link DIR-826L or Tenda WH450 firmware because it is limited by the binary analysis tool angr [56] and cannot analyze some MIPS architecture binaries. In addition, SaTC had a high false-negative rate, mainly because it outputs only the top three binary executables for each firmware as border binaries. In contrast, BBDetector exhibited better performance in detecting border binaries. For example, in the D-Link DIR-826L firmware, Karonte did not identify any border binary, SaTC identified 2 border binaries, and BBDetector identified 3 border binaries.

The superior detection capability of BBDetector stems from two pivotal factors. First, the open-source binary analysis tool Radare2 [51] has cross-architecture analysis capabilities, effectively supporting various architectures. Second, the MDFM effectively characterizes the key features of border binaries, and the stacking method has strong generalizability through training.

BBDetector provides important guidance and support for firmware security analysis. Replacing the border binaries and network parsing functions identified by Karonte and SaTC with the border binaries and network parsing functions detected by BBDetector and performing subsequent security analysis of Karonte and SaTC, firmware vulnerabilities, as shown in Table 9, can be successfully found. SaTC failed to detect the minidlna border binary in the DIR-880LA1-FW107WWb08 firmware and did not detect three security vulnerabilities, namely, CVE-203-39669, CVE-2023-39671, and CVE-2023-39674, in minidlna. Similarly, Karonte failed to detect the ncc border binary in the DIR-826LA1_FW105B13 firmware, resulting in the missed detection of CVE-2021-45382.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Table 9. List of known vulnerabilities found in Dataset II by BBDetector.

https://doi.org/10.1371/journal.pone.0329469.t009