A method and system for fuzz testing satellite network protocols

Abstract

The application relates to a satellite network protocol-oriented fuzzy testing method and system, and the method comprises the following steps: constructing a white-box knowledge base covering a remote control uplink instruction link according to protocol specifications of a CCSDS protocol and core flight system flight software source code; generating a multi-dimensional seed set and a priority score according to the white-box knowledge base; constructing a remote control uplink instruction of the CCSDS protocol to perform fuzzy testing, synchronously performing EVS event coverage tracking and gcov basic block coverage tracking to obtain double-track coverage; selecting a seed from a seed corpus, traversing a function code space, and constructing a test case through random walk according to the white-box knowledge base, calculating corresponding double-track coverage through fuzzy testing to update the priority score of the seed, thereby generating a new seed through genetic variation; and monitoring a running state to generate a structured test report. Compared with the prior art, the application improves vulnerability discovery efficiency and code coverage.

Description

Technical Field

[0001] This invention relates to the field of network protocol testing technology, and in particular to a fuzz testing method and system for satellite network protocols. Background Technology

[0002] The CCSDS protocol is a family of international standard protocols for space communications developed by the Advisory Committee on Space Data Systems. Since its inception in 1982, it has been widely adopted by major space agencies worldwide, including NASA and the European Space Agency. The CCSDS protocol family covers core specifications such as space packet transmission, remote control uplink, telemetry downlink, and advanced on-orbit systems. The CCSDS 133.0-B-2 blue book defines the frame structure and field layout of the space packet protocol, including strict data length calculation, application process identification routing, and XOR checksum verification mechanisms. The security and reliability of the CCSDS protocol are directly related to the success or failure of satellite missions; therefore, systematic security testing of its protocol implementation is of great significance.

[0003] Fuzzing is an important method for discovering software security vulnerabilities. It involves sending a large number of random or semi-random inputs to a target system to trigger abnormal behavior and uncover potential vulnerabilities. However, existing general-purpose fuzzing tools have the following shortcomings: (1) Lack of protocol awareness: General fuzzing tools do not understand the CCSDS protocol structure, resulting in a large number of invalid test cases. It is difficult to enter the deep code logic through the cFS protocol parsing layer, resulting in low testing efficiency. The CCSDS protocol has strict frame structure constraints, including precise data length calculation, XOR checksum verification, etc. Most randomly generated data packets are discarded at the protocol entry point.

[0004] (2) Lack of multi-service path coverage: Existing testing of aerospace software usually only focuses on one link in the command interface or telemetry interface, failing to achieve systematic coverage of multiple APIDs, multi-function codes, and multiple device driver interfaces. The cFS architecture contains core services and a large number of mission applications, each using independent APIDs, which need to be tested separately.

[0005] (3) Lack of coverage feedback: Existing black-box fuzzing methods cannot know the code coverage of test cases, cannot distinguish between high-value inputs and low-value inputs, and have low test resource utilization. Coverage-guided gray-box or white-box fuzzing has been proven to be significantly better than blind random testing in general software testing, but it has not yet been effectively applied to the security testing of the CCSDS protocol stack.

[0006] (4) Lack of adaptation to the protocol simulation environment: NOS3 provides a high-fidelity satellite software simulation platform that supports comprehensive testing of the CCSDS protocol implementation in flight software on the ground. However, existing fuzz testing methods fail to fully utilize the unique technical conditions provided by the NOS3 simulation environment, such as Docker containerized deployment, gcov code instrumentation interface, and EVS event bus, and cannot systematically conduct security assessments of the CCSDS protocol implementation during the simulation phase.

[0007] The invention disclosed in patent announcement number CN114610640B presents a fuzz testing method and system for Trusted Execution Environments (TEEs) in the Internet of Things (IoT). By analyzing standard and custom TEE documents, it constructs test case template files and seed files, utilizes a hardware emulator to generate and transmit test cases, achieving efficient testing of the TEE kernel. New test cases are generated by combining scheduling algorithms and mutation operations, and the seed file is updated to improve coverage. However, this solution still suffers from the aforementioned problems of lacking protocol awareness, lacking multi-service path coverage, and lacking coverage feedback.

[0008] Therefore, developing a white-box fuzzy testing method specifically for the CCSDS protocol stack, supporting multi-service path coverage and guided by coverage feedback, is of great significance for improving the safety and quality of aerospace flight software and discovering potential vulnerabilities in advance during the ground simulation phase. Summary of the Invention

[0009] The purpose of this invention is to overcome the shortcomings of the prior art, such as lack of protocol awareness, lack of multi-service path coverage, and lack of coverage feedback, and to provide a fuzzy testing method and system for satellite network protocols.

[0010] The objective of this invention can be achieved through the following technical solutions: A fuzz testing method for satellite network protocols, specifically for testing the CCSDS protocol, includes the following steps: S1: Based on the protocol specifications of the CCSDS protocol and the source code of the core flight system flight software, a white-box knowledge base covering the remote control uplink command link is constructed to cover the protocol layer of the remote control uplink command link. The white-box knowledge base includes an application process identifier mapping table, a function code mapping table, and a protocol frame structure. S2: Based on the white-box knowledge base, generate a multi-dimensional seed set covering the initialization of core flight software services and device driver application process identifiers, as well as priority scores for various sub-subs, to form an initial seed corpus. S3: Construct remote uplink commands for the CCSDS protocol, input them into the small satellite operation simulator for fuzz testing, and simultaneously perform EVS event coverage tracking and gcov basic block coverage tracking during the fuzz testing process to obtain dual-track coverage. The EVS event coverage tracking is based on the telemetry downlink EVS messages of the CCSDS protocol to calculate the coverage. The gcov basic block coverage tracking is performed by instrumenting the cFS executable file of the Docker container in the small satellite operation simulator to obtain the gcno file, and the coverage is calculated based on the change in the number of newly added covered basic blocks in the gcno file during the fuzz testing process. S4: Select seeds from the seed corpus, traverse the function code space of the CCSDS protocol, and construct test cases by performing random walks based on the white-box knowledge base. Perform fuzz testing through step S3 and calculate the corresponding dual-track coverage rate to update the priority score of the seeds, thereby generating new seeds through genetic mutation. S5: During the fuzz test, monitor the operating status of the small satellite operation simulator and generate a structured test report containing coverage, crash records, and high-value seeds. The high-value seeds are selected based on priority scores and execution counts.

[0011] Furthermore, the application process identifier mapping table includes instruction receivers including: core cFS service link, ground interface link, flight application link, and device driver link; The core cFS service chain includes the CFE_ES module, which is responsible for cFS system initialization, application management and system resource control; the CFE_EVS module, which is responsible for publishing and filtering cFS system event messages; the CFE_SB module, which is responsible for inter-application message routing; the CFE_TBL module, which is responsible for parameter table management and annotation; and the CFE_TIME module, which is responsible for cFS system time synchronization and management. The ground interface link includes a telemetry downlink interface and a command uplink interface; The flight application link includes a mission scheduler, a limit checker, a storage instruction management module, and a data storage module; The device drive chain includes a global positioning system, an inertial measurement unit, and a power supply system.

[0012] Furthermore, the protocol frame structure includes a main header, an instruction auxiliary header, and a variable-length payload; The process of constructing the protocol frame structure includes: Construct the main header, which includes the version number, package type, auxiliary header flags, application process identifier, sequence flag, sequence count, and data length; Construct an instruction helper header, which includes a function code field and a checksum field; A variable-length payload is constructed and concatenated with the main header and the instruction auxiliary header to obtain the protocol frame structure; Perform an XOR operation on all bytes of the protocol frame structure in sequence, fill the result into the checksum field of the instruction auxiliary header, and make the XOR value of all bytes of the protocol frame structure equal to 0xFF.

[0013] Furthermore, the initial seed corpus contains seed types including normal function seeds, boundary condition seeds, and protocol activation seeds; The normal function seed contains NOOP instructions for each application process identifier, serving as a benchmark for testing the normality of system response. The boundary condition seeds include an empty load seed for testing the processing logic of zero-length data, an all-zero load seed for testing boundary null value processing, an all-0xFF load seed for testing maximum value processing, and a maximum function code boundary seed for testing the function code space boundary. The protocol activation seed includes a telemetry downlink interface enable command, which includes a target IP address string and a UDP port number, and is used to activate the telemetry downlink.

[0014] Furthermore, the EVS event coverage tracking process includes: Listen to the telemetry downlink EVS messages of the CCSDS protocol, parse the application name field and event identifier in the telemetry downlink EVS messages obtained by listening, and form a tuple as the overlay point; The coverage point constructed based on the telemetry downlink EVS message obtained from each monitoring is compared with the existing set of coverage points. If it is a new coverage point, it is added to the set of coverage points and the coverage count is increased, thereby calculating the corresponding dual-track coverage rate.

[0015] Furthermore, the gcov basic block coverage tracing process includes a compile-time instrumentation stage and a runtime acquisition stage. The compile-time instrumentation stage includes: injecting compilation identifiers into the Docker container in the small satellite operation simulator, recompiling to generate a cFS executable file carrying instrumentation, which is used as a gcno file; the gcno file is generated based on each basic block during compilation and records the control flow graph between each basic block. The runtime data collection phase includes: after executing a preset number of test cases, searching for newly generated gcno files during fuzz testing, parsing the execution counters of each basic block in the newly generated gcno files, and performing a differential comparison with the previous snapshot value of the corresponding execution counter. Basic blocks whose execution count changes from zero to non-zero are regarded as newly covered basic blocks, and the corresponding dual-track coverage rate is calculated based on the total number of newly covered basic blocks.

[0016] Furthermore, the processing in step S4 includes a deterministic mutation stage, a random walk stage, and a corpus genetic mutation stage; The process of the deterministic mutation stage includes: selecting seeds from the seed corpus, traversing the function code space of the CCSDS protocol, constructing test cases for each function code value in the function code space and sending them to the small satellite operation simulator to perform fuzz testing through step S3, obtaining the corresponding dual-track coverage rate, and then updating the priority score of the seeds. The random walk phase includes: randomly selecting application process identifiers from the application process identifiers and the random application process identifier extension space of the white-box knowledge base to randomly generate function codes and payloads, constructing test cases, and sending them to the small satellite operation simulator to perform fuzz testing through step S3. If a new coverage is triggered, a seed is constructed according to the corresponding test cases and added to the seed corpus. The processing steps of the genetic mutation stage of the corpus include: calculating seed weights based on the priority scores of various sub-seeds in the seed corpus; using the proportion of each sub-seed weight in the total weight of all seeds in the seed corpus as the sampling probability, and determining the parent seed by sampling through the cumulative distribution function; performing genetic mutation operations based on the parent seed to generate offspring seeds, adding them to the seed corpus, and increasing the priority score of the parent seed.

[0017] Furthermore, the genetic mutation operation includes: randomly selecting a mutation operator based on the parent seed to perform mutation and generate offspring seeds; The mutation operator includes: Bit flipping is used to randomly select a bit of a byte in the payload and invert it; Byte flipping is used to randomly select a byte in the payload and replace it with a random value. Byte insertion, used to insert 1 to 8 random bytes at random positions; Byte deletion, used to randomly delete 1 to 4 consecutive bytes from the payload; PID Mutation: Used to replace the application process identifier with a known application process identifier in the white-box knowledge base, a low-order XOR variant of the current application process identifier, or a random value; Function code mutation: Replaces the function code with a protocol reserved value, an XOR variant of the current function code, or a random value; High-intensity mutation: Perform 2 to 8 cascade mutations on the remaining mutation operators in random combinations.

[0018] Furthermore, the update rule for the priority score of the seed includes: If new EVS event coverage or gcov basic block coverage is generated after the test cases are built and executed according to the selected seed in step S4, the priority score of the seed is amplified according to the preset amplification factor; if no new EVS event coverage or gcov basic block coverage is generated, the priority score of the seed is reduced according to the preset reduction factor. The structured test report includes the following fields: total number of test executions, total number of new coverage points, EVS event coverage point list, path hash set size, gcov basic block coverage number, total corpus size, crash event record list, high-value seed list, and input records that triggered new coverage.

[0019] The present invention also provides a fuzz testing system for satellite network protocols, including a memory and a processor, wherein the memory stores a computer program, and the processor calls the computer program to execute the steps of the method described above.

[0020] Compared with the prior art, the present invention has the following advantages: (1) Based on the CCSDS 133.0-B-2 blue book and cFS source code, this invention builds a complete protocol white-box knowledge base, realizes systematic coverage of multiple service paths such as TC uplink, TM downlink, core service APID, flight application APID and device driver APID, and significantly expands the attack surface of security testing.

[0021] (2) The dual-track coverage tracking mechanism proposed in this invention organically integrates EVS application event coverage (Track-A) and gcov code basic block coverage (Track-B), which greatly improves the comprehensiveness and accuracy of coverage measurement; Among them, Track-A telemetry downlink EVS messages are used for coverage calculation. The advantage is that there is no need to modify the cFS source code. The TM downlink EVS event stream is converted into the coverage feedback signal of TC command in a non-intrusive manner, which is suitable for the test scenario of production-level flight software. Track-B utilizes the gcov coverage instrumentation mechanism of the GNU compiler suite to perform source code-level basic block coverage tracing on cFS executables, providing more granular code-level coverage information than Track-A.

[0022] (3) The three-stage adaptive fuzzy testing strategy designed in this invention organically combines white-box knowledge-driven deterministic mutation, random walk of random exploration, and corpus mutation in the style of genetic algorithm; In the deterministic mutation phase, the function codes of each application in cFS are usually concentrated in the low value range. Deterministic traversal can systematically trigger the core function paths of each application and avoid omissions of random strategies. The random walk phase can detect edge application process identifiers and unregistered function codes that are not covered by the white-box knowledge table, and discover possible hidden interfaces or implementation errors, thus making up for the limited coverage of the deterministic mutation phase. The corpus genetic mutation stage can perform directed evolution on the discovered high-coverage-value seeds. Through genetic mutation operators, it can efficiently explore the neighborhood space of existing high-value inputs, continuously expanding the code coverage depth with fewer executions, and avoiding the problem of low efficiency of random exploration starting from zero. Compared to fuzzing methods using a single strategy, it can cover more code paths with the same number of executions, significantly increasing the probability of discovering vulnerabilities.

[0023] (4) The seed corpus management mechanism based on genetic algorithm of this invention enables high-value seeds to obtain more mutation opportunities and low-value seeds to be gradually eliminated through dynamic scoring and weighted random selection strategy, effectively avoiding the waste of resources in traditional random testing and greatly improving testing efficiency.

[0024] (5) This invention realizes systematic security testing of the CCSDS remote control uplink command link and guides the direction of fuzzy testing through telemetry downlink EVS feedback, which significantly improves the vulnerability discovery efficiency and code coverage of the CCSDS protocol stack. It is applicable to security assessment in the ground simulation stage of satellite system, regression testing before flight software version upgrade, and protocol consistency verification of new CCSDS applications. It has important practical value for ensuring the software security of aerospace missions. Attached Figure Description

[0025] Figure 1 This is a schematic diagram of the overall process of a fuzz testing method for satellite network protocols provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of a white-box knowledge base structure for the CCSDS protocol provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of a dual-track coverage tracking mechanism provided in an embodiment of the present invention; Figure 4 This is a system deployment architecture diagram in the NOS3 simulation environment provided in an embodiment of the present invention. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0027] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0028] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0029] Example 1 This embodiment provides a fuzz testing method for satellite network protocols, using the CCSDS protocol as the specific test object, such as... Figure 1 As shown. This embodiment uses the CCSDS protocol implementation in the core flight system's flight software as the fuzzy testing target, and implements TC uplink command injection and TM downlink telemetry monitoring through User Datagram Protocol sockets. For verification during the ground phase, this embodiment utilizes... Figure 4 The NOS3 simulation environment shown uses a Docker containerized cFS instance as the test platform.

[0030] Includes the following steps: S1: Based on the protocol specifications of the CCSDS protocol and the source code of the core flight system flight software, a white-box knowledge base covering the remote control uplink command link is constructed to cover the protocol layer of the remote control uplink command link. The white-box knowledge base includes an application process identifier mapping table, a function code mapping table, and a protocol frame structure. The white-box modeling work in this solution is based on the CCSDS 133.0-B-2 space packet protocol blue book, cFS flight software source code, and NOS3 platform adaptation documents, establishing, as follows: Figure 2 The white-box knowledge base of the TC uplink command link is shown. The white-box knowledge base includes an Application Process Identifier (APID) mapping table, a Function Code (FC) mapping table, and a protocol frame structure, covering the protocol layers of the Telecommand (TC) uplink command link.

[0031] In this invention, the TM downlink is only used to read EVS event feedback and is not used as a test target. Therefore, this step also requires parsing the TM downlink EVS message frame format and using it as a coverage feedback channel.

[0032] Specifically, step S1 includes the following sub-steps: S101: Construct APID Link Mapping Table APID is the core identifier used by the CCSDS protocol to distinguish different flight software applications. This invention constructs an APID mapping table covering the following four types of links: The core cFS service chain consists of: CFE_ES (Executive Services), which is responsible for cFS system initialization, application management, and system resource control; CFE_EVS (Event Services), which is responsible for publishing and filtering system event messages; CFE_SB (Software Bus), which is responsible for inter-application message routing; CFE_TBL (Table Services), which is responsible for parameter table management and annotation; and CFE_TIME (Time Services), which is responsible for system time synchronization and management.

[0033] Ground interface link: TO_LAB (Telemetry Output Laboratory) is the telemetry downlink interface application in the NOS3 simulation environment, which is responsible for forwarding messages from the cFS internal software bus to the ground. It needs to be activated by the enable command before the test starts, otherwise it cannot receive telemetry data; CI_LAB (Command Ingest Laboratory) is the command uplink interface, which is responsible for receiving uplink UDP datagrams from the ground and injecting them into the cFS software bus.

[0034] Flight application chain: SCH (Scheduler) is responsible for periodically scheduling mission commands; LC (Limit Checker) is responsible for monitoring parameter limits; SC (Stored Commands) is responsible for managing stored command sequences; DS (Data Storage) is responsible for file storage of telemetry data.

[0035] Device drive chain: Applications of devices such as GPS (Global Positioning System), IMU (Global Positioning System), and EPS (Emergency Power Supply) directly drive satellite payloads and basic hardware.

[0036] S102: Constructing the CCSDS frame structure The CCSDS TC command frame consists of three parts: a primary header (6 bytes), a command secondary header (2 bytes), and a variable-length payload.

[0037] Main header field layout (48 bits in total): Version number (3 bits, fixed at 0), Packet type (1 bit, TC=1), Auxiliary header flag (1 bit, 1 indicates the presence of an auxiliary header), APID (11 bits), Sequence flag (2 bits, 0b11 for independent packets), Sequence count (14 bits, value range 0~16383, incrementing cyclically), Data length (16 bits, its value is equal to the total number of auxiliary header and payload bytes minus 1).

[0038] Instruction auxiliary header (16 bits in total): Function code FC (7 bits, with the high 1 bit reserved), checksum (8 bits). The checksum uses the cFS XOR check algorithm: the check variable chk is initialized to 0xFF, all bytes of the entire packet are XORed sequentially, and the final result is filled into the auxiliary header checksum field, so that the XOR value of the entire packet is equal to 0xFF.

[0039] The TM telemetry frame monitoring focuses on EVS event telemetry messages. These messages have a 20-byte ASCII string representing the application name at offset 14 bytes and a 2-byte event identifier at offset 34 bytes. This invention parses EVS event messages in real-time on the TM downlink UDP port, using them as the data source for Track-A in dual-track coverage tracing.

[0040] S2: Based on the white-box knowledge base, generate a multi-dimensional seed set covering the initialization of core flight software services and device driver application process identifiers, as well as priority scores for various sub-subs, to form the initial seed corpus. Specifically, the initial seed corpus is the starting point for fuzz testing, and its quality directly affects the depth and efficiency of subsequent tests. Based on the white-box knowledge base constructed in step S1, this invention designs the following multi-dimensional initial seed set: Normal function seed: Generates regular function instructions such as NOOP instruction and reset counter instruction for each major APID, carrying a legal payload, as a benchmark for testing the normality of system response, including TO_LAB_NOOP, CFE_ES_NOOP, CFE_EVS_NOOP and CFE_TIME_NOOP.

[0041] Protocol activation seed: The TO_LAB enable command carries a 16-byte target IP address string and a 2-byte UDP port number, for a total payload of 18 bytes. This seed must be sent before the start of the fuzzing main loop to activate the TM downlink telemetry link, so that EVS event messages can be received by the listener and ensure that Track-A coverage tracking works normally.

[0042] Boundary condition seeds: Empty load seed is used to test the processing logic of zero-length data; All-zero load seed (8 bytes 0x00) tests the handling of boundary null values; All-0xFF load seed (32 bytes 0xFF) tests the handling of maximum values; Maximum function code boundary seed (FC 0x7F) tests the function code space boundary.

[0043] Each seed is stored as a data class, containing the fields apid, fc, payload, strategy (generation strategy label), coverage (cumulative coverage contribution), exec_count (number of executions), and score (priority score, initially 1.0). The initial corpus size is 9 seeds.

[0044] S3: Construct remote uplink commands for the CCSDS protocol, input them into the small satellite operation simulator for fuzz testing, and simultaneously perform EVS event coverage tracking and gcov basic block coverage tracking during the fuzz testing process to obtain dual-track coverage. EVS event coverage tracking calculates coverage based on telemetry downlink EVS messages of the CCSDS protocol. gcov basic block coverage tracking compiles the cFS executable file of the Docker container in the small satellite operation simulator using gcov instrumentation to obtain the gcno file, and calculates the coverage based on the change in the number of newly added coverage basic blocks in the gcno file during the fuzz testing process. The EVS event coverage tracing process includes: Listen to the telemetry downlink EVS messages of the CCSDS protocol, parse the application name field and event identifier in the telemetry downlink EVS messages obtained by listening, and form a tuple as the overlay point; The coverage point constructed based on the telemetry downlink EVS messages obtained from each monitoring session is compared with the existing set of coverage points. If it is a new coverage point, it is added to the set of coverage points and the coverage count is increased, thereby calculating the corresponding coverage rate.

[0045] The gcov basic block coverage tracing process includes a compile-time instrumentation stage and a runtime acquisition stage. The compile-time instrumentation stage includes: injecting compilation identifiers into a Docker container in the small satellite operation simulator, recompiling to generate a cFS executable file carrying instrumentation, which is used as a gcno file; the gcno file is generated based on each basic block during compilation and records the control flow graph between each basic block; The runtime data collection phase includes: after executing a preset number of test cases, searching for newly generated gcno files during fuzz testing, parsing the execution counters of each basic block in the newly generated gcno files, and performing a differential comparison with the previous snapshot value of the corresponding execution counter. Basic blocks whose execution count changes from zero to non-zero are considered as newly covered basic blocks, and the corresponding coverage rate is calculated based on the total number of newly covered basic blocks.

[0046] Specifically, the dual-track coverage tracking in this step is the core feedback mechanism of this invention, such as... Figure 3 As shown. The object of testing in this invention is the TC uplink command link; the TM downlink is not used as the attack surface for fuzz testing in this invention, but rather as an observation channel—quantifying the execution depth of each TC test case in the server-side code by monitoring the cFS response output to TC commands. The two feedback tracks complement each other, jointly guiding the evolution direction of the seed corpus.

[0047] Includes the following sub-steps: S301: Track-A: EVS Event Coverage Tracking.

[0048] EVS is the event publishing and subscription mechanism of cFS. Each module of the flight software calls the CFE_EVS_SendEvent() interface to publish event messages on the critical code path. The messages are routed to TO_LAB through the software bus and sent to the ground via UDP port. Each EVS event message carries an application name (AppName) and an event identifier (EventID). Different combinations of (AppName, EventID) correspond to different code paths.

[0049] The implementation logic of Track-A is as follows: A dedicated listening thread is started on the downlink UDP port of TM to continuously receive UDP datagrams; the APID field and data length are checked for each datagram; the 20-byte ASCII application name AppName is extracted from offset 14 bytes, and the 2-byte event identifier EventID is extracted from offset 34 bytes; the (AppName, EventID) tuple is compared with the set of known coverage points, and if it is a new coverage point, it is added to the set and marked as a new addition; at the same time, the sequence window of the most recent EVS events is maintained, and the MD5 hash value of the sequence is taken to record the new path in order to identify different execution paths under the same coverage point.

[0050] The advantage of Track-A is that it can convert the TM downlink EVS event stream into the TC command coverage feedback signal without modifying the cFS source code, making it suitable for production-grade flight software testing scenarios.

[0051] S302: Track-B: gcov basic block coverage tracing.

[0052] Track-B utilizes the gcov coverage instrumentation mechanism of GCC (GNU Compiler Collection) to perform source code-level basic block coverage tracing on cFS executables, providing more granular code-level coverage information than Track-A.

[0053] The implementation of Track-B is divided into two stages: compile-time instrumentation and runtime data collection.

[0054] Compile-time instrumentation: Within the Docker container of the NOS3 simulation environment, the compilation flags fprofile-arcs, ftest-coverage O0-g, and the linker flag lgcov are appended to the cFS CMake toolchain file. cFS is then recompiled to generate an executable file carrying the gcov instrumentation. After compilation, the effectiveness of the instrumentation is verified by counting the number of .gcno files. The .gcno files are generated by GCC for each basic block during compilation and record the control flow graph between basic blocks.

[0055] Runtime data collection: Before the fuzz test starts, the baseline snapshot interface is called to record the initial timestamp. After each number of test cases are executed, a signal (SIGUSR1) is sent to the cFS process to trigger the application-layer registered gcov data refresh callback. Then, the find command is executed in the container via docker exec to find gcda files that are newer than the baseline timestamp (gcda files are generated when the basic block count on the program execution path changes during gcov runtime). The binary counters of newly discovered and known gcda files are read and compared with the counter value of the previous snapshot on a basic block-by-basic block basis. Basic blocks whose execution count changes from zero to non-zero are considered newly covered basic blocks. The total number of newly covered basic blocks is accumulated and used as the coverage gain metric for Track-B.

[0056] The coverage gain of Track-A and Track-B is summarized after each test case is sent. Any new coverage on either track triggers the seed addition and score improvement logic.

[0057] S4: Select seeds from the seed corpus, traverse the function code space of the CCSDS protocol, and construct test cases by performing random walks based on the white-box knowledge base. Perform fuzz testing through step S3 and calculate the corresponding dual-track coverage rate to update the priority score of the seeds, thereby generating new seeds through genetic mutation. It includes a deterministic variation phase, a random walk phase, and a corpus-based genetic variation phase; Specifically, the three-stage adaptive fuzzing main loop is the core execution engine of this invention. The three stages loop in a fixed order, each responsible for a different exploration strategy, working together to achieve efficient coverage, including the following sub-steps: S401: Phase initialization.

[0058] Before the main loop starts, perform the following initialization operations in sequence: start the TM listening thread; set the gcov baseline snapshot; wait 500 milliseconds to make the listening thread ready; send the TO_LAB enable seed to activate the telemetry link; wait 500 milliseconds to confirm the telemetry link activation.

[0059] S402: Deterministic variation stage.

[0060] The deterministic mutation phase is driven by white-box knowledge and systematically traverses the CCSDS function code space. Specifically, it involves: selecting a parent seed from the corpus; fixing the APID and payload of the seed; traversing the function code space from 0x00 to 0x0F, constructing a test case for each function code value; sending CCSDS command frames to the target cFS instance via a UDP socket; collecting dual-track coverage feedback after a preset interval; updating the parent score based on coverage gain; and adding the corresponding test case to the corpus if a function code triggers new coverage.

[0061] The design of this stage is based on the fact that the function codes of each application in cFS are usually concentrated in the low value range (0x00~0x0F). Deterministic traversal can systematically trigger the core function paths of each application and avoid omissions by random strategies.

[0062] S403: Random walk phase.

[0063] The random walk phase expands the APID and function code coverage space of the test through random exploration. Random sampling is performed from the APID selection space: APIDs known in the white-box knowledge table are uniformly randomly selected with a 50% probability; APIDs are also randomly generated within the range of 0x0000 to 0x07FF with a 50% probability. The latter is used to detect unknown APIDs not registered in the white-box knowledge table. Function codes are uniformly randomly generated within the range of 0x00 to 0x7F. The payload length is uniformly randomized between 0 and 32 bytes, and the values ​​of each byte are uniformly randomized between 0 and 255. CCSDS command frames are constructed and sent to collect dual-track coverage feedback; if new coverage is triggered, it is added to the corpus.

[0064] The significance of this phase lies in detecting edge APIDs and unregistered function codes that are not covered by the white-box knowledge table, discovering potential hidden interfaces or implementation errors, and making up for the limited coverage of the deterministic mutation phase.

[0065] S404: Corpus genetic variation stage.

[0066] The corpus genetic mutation stage is similar to the corpus mutation mechanism of AFL (American Fuzzy Lop), using a high-coverage seed as the parent and generating mutated offspring use cases through genetic mutation operators.

[0067] Seed selection employs a weighted random strategy: the effective weight w of each seed in the corpus is calculated. i = score i / (exec count-i + 1), where score iScore the priority of seed i, exec count-i The number of times seed i is used is determined by sampling the proportion of each sub-weight in the total weight, and the parent seed is determined by sampling through the cumulative distribution function, so that high-value seeds (high score, few execution times) have a higher selection probability.

[0068] After selecting the parent, one of the following seven mutation operators is randomly selected to perform mutation and generate offspring seeds: Bit flipping randomly flips a specific bit of a byte in the payload; Byte flipping replaces a specific byte in the payload with a random byte value; Insert 1 to 8 random bytes at random positions to test the length out-of-bounds handling logic; Byte deletion: Randomly delete 1 to 4 consecutive bytes to test the short packet processing logic; APID mutation replaces APID with a known value from the knowledge table, a low-order XOR variant of the current value, or a completely random value. Function code mutation replaces the function code with a protocol reserved value, a low-order XOR variant of the current value, or a random value; High-intensity mutations are randomly combined with the above operators to perform 2 to 8 cascade mutations to explore deep code paths.

[0069] After a child seed is sent, if a new overwrite is triggered, it is added to the corpus, and the parent seed score is multiplied by 1.5 (maximum 100.0); otherwise, the parent seed score is multiplied by 0.95. The corpus size grows dynamically with testing, but all seeds that have triggered a new overwrite are always retained.

[0070] The significance of this stage lies in the directed evolution of the discovered high-coverage-value seeds. By using genetic mutation operators, the code coverage depth can be continuously expanded with fewer executions, avoiding the inefficiency of random exploration starting from scratch.

[0071] S5: During fuzz testing, monitor the operating status of the small satellite operation simulator and generate a structured test report containing coverage, crash records, and high-value seeds. High-value seeds are selected based on priority scores and execution counts.

[0072] Specifically, in this embodiment, every 100 test cases are executed, the docker inspect command is called to check the running status of the target cFS container. If the return value is not "running", the cFS process is determined to have crashed. The number of executions when the crash occurred and the most recently sent test cases (APID, function code, payload hexadecimal string) are recorded as crash trigger samples.

[0073] Upon completion of the test, this invention automatically generates a structured test report, which includes the following core fields: timestamp (test completion timestamp), total_execs (total number of test executions), total_new_cov (total number of new coverage points), evs_coverage (number of EVS event coverage points), path_count (number of unique path hashes), gcov_available (whether gcov instrumentation is available), gcov_coverage (number of new basic blocks added by gcov), corpus_size (final corpus size), crashes (list of crash events), crash_count (total number of crashes), interesting_inputs (the top 100 high-value input records that triggered new coverage, including timestamp, APID, function code, payload hexadecimal, and mutation policy label), top_seeds (the top 5 high-value seeds sorted by coverage contribution), and all_evs_coverage (list of all covered EVS events).

[0074] This invention can significantly improve the coverage and efficiency of aerospace flight software security testing for the CCSDS protocol stack. It is applicable to security assessment during the ground simulation phase of satellite systems, regression testing before flight software version upgrades, and protocol consistency verification of new CCSDS applications. It has important practical value for ensuring the software security of aerospace missions.

[0075] Example 2 This embodiment provides a fuzz testing system for satellite network protocols, including a memory and a processor. The memory stores a computer program, and the processor calls the computer program to execute the steps of a fuzz testing method for satellite network protocols as described in Embodiment 1.

[0076] The preferred embodiments of the present invention have been described in detail above. It should be understood that those skilled in the art can make numerous modifications and variations based on the concept of the present invention without creative effort. Therefore, all technical solutions that can be obtained by those skilled in the art based on the concept of the present invention through logical analysis, reasoning, or limited experimentation on the basis of existing technology should be within the scope of protection defined by the claims.

Claims

1. A fuzz testing method for satellite network protocols, used to test the CCSDS protocol, characterized in that, Includes the following steps: S1: Based on the protocol specifications of the CCSDS protocol and the source code of the core flight system flight software, a white-box knowledge base covering the remote control uplink command link is constructed to cover the protocol layer of the remote control uplink command link. The white-box knowledge base includes an application process identifier mapping table, a function code mapping table, and a protocol frame structure. S2: Based on the white-box knowledge base, generate a multi-dimensional seed set covering the initialization of core flight software services and device driver application process identifiers, as well as priority scores for various sub-subs, to form an initial seed corpus. S3: Construct remote uplink commands for the CCSDS protocol, input them into the small satellite operation simulator for fuzz testing, and simultaneously perform EVS event coverage tracking and gcov basic block coverage tracking during the fuzz testing process to obtain dual-track coverage. The EVS event coverage tracking is based on the telemetry downlink EVS messages of the CCSDS protocol to calculate the coverage. The gcov basic block coverage tracking is performed by instrumenting the cFS executable file of the Docker container in the small satellite operation simulator to obtain the gcno file, and the coverage is calculated based on the change in the number of newly added covered basic blocks in the gcno file during the fuzz testing process. S4: Select seeds from the seed corpus, traverse the function code space of the CCSDS protocol, and construct test cases by performing random walks based on the white-box knowledge base. Perform fuzz testing through step S3 and calculate the corresponding dual-track coverage rate to update the priority score of the seeds, thereby generating new seeds through genetic mutation. S5: During the fuzz test, monitor the operating status of the small satellite operation simulator and generate a structured test report containing coverage, crash records, and high-value seeds. The high-value seeds are selected based on priority scores and execution counts.

2. The fuzz testing method for satellite network protocols according to claim 1, characterized in that, The application process identifier mapping table includes instruction receivers including: core cFS service link, ground interface link, flight application link, and device driver link; The core cFS service chain includes the CFE_ES module, which is responsible for cFS system initialization, application management and system resource control; the CFE_EVS module, which is responsible for publishing and filtering cFS system event messages; the CFE_SB module, which is responsible for inter-application message routing; the CFE_TBL module, which is responsible for parameter table management and annotation; and the CFE_TIME module, which is responsible for cFS system time synchronization and management. The ground interface link includes a telemetry downlink interface and a command uplink interface; The flight application link includes a mission scheduler, a limit checker, a storage instruction management module, and a data storage module; The device drive chain includes a global positioning system, an inertial measurement unit, and a power supply system.

3. The fuzz testing method for satellite network protocols according to claim 1, characterized in that, The protocol frame structure includes a main header, a command auxiliary header, and a variable-length payload. The process of constructing the protocol frame structure includes: Construct the main header, which includes the version number, package type, auxiliary header flags, application process identifier, sequence flag, sequence count, and data length; Construct an instruction helper header, which includes a function code field and a checksum field; A variable-length payload is constructed and concatenated with the main header and the instruction auxiliary header to obtain the protocol frame structure; Perform an XOR operation on all bytes of the protocol frame structure in sequence, fill the result into the checksum field of the instruction auxiliary header, and make the XOR value of all bytes of the protocol frame structure equal to 0xFF.

4. The fuzz testing method for satellite network protocols according to claim 1, characterized in that, The initial seed corpus contains seed types including normal function seeds, boundary condition seeds, and protocol activation seeds. The normal function seed contains NOOP instructions for each application process identifier, serving as a benchmark for testing the normality of system response. The boundary condition seeds include an empty load seed for testing the processing logic of zero-length data, an all-zero load seed for testing boundary null value processing, an all-0xFF load seed for testing maximum value processing, and a maximum function code boundary seed for testing the function code space boundary. The protocol activation seed includes a telemetry downlink interface enable command, which includes a target IP address string and a UDP port number, and is used to activate the telemetry downlink.

5. The fuzz testing method for satellite network protocols according to claim 1, characterized in that, The EVS event coverage tracking process includes: Listen to the telemetry downlink EVS messages of the CCSDS protocol, parse the application name field and event identifier in the telemetry downlink EVS messages obtained by listening, and form a tuple as the overlay point; The coverage point constructed based on the telemetry downlink EVS message obtained from each monitoring is compared with the existing set of coverage points. If it is a new coverage point, it is added to the set of coverage points and the coverage count is increased, thereby calculating the corresponding dual-track coverage rate.

6. The fuzz testing method for satellite network protocols according to claim 1, characterized in that, The gcov basic block coverage tracing process includes a compile-time instrumentation stage and a runtime acquisition stage. The compile-time instrumentation stage includes: injecting compilation identifiers into the Docker container in the small satellite operation simulator, recompiling to generate a cFS executable file carrying instrumentation, which is used as a gcno file; the gcno file is generated based on each basic block during compilation and records the control flow graph between each basic block. The runtime data collection phase includes: after executing a preset number of test cases, searching for newly generated gcno files during fuzz testing, parsing the execution counters of each basic block in the newly generated gcno files, and performing a differential comparison with the previous snapshot value of the corresponding execution counter. Basic blocks whose execution count changes from zero to non-zero are regarded as newly covered basic blocks, and the corresponding dual-track coverage rate is calculated based on the total number of newly covered basic blocks.

7. The fuzz testing method for satellite network protocols according to claim 1, characterized in that, The processing in step S4 includes a deterministic mutation stage, a random walk stage, and a corpus genetic mutation stage; The process of the deterministic mutation stage includes: selecting seeds from the seed corpus, traversing the function code space of the CCSDS protocol, constructing test cases for each function code value in the function code space and sending them to the small satellite operation simulator to perform fuzz testing through step S3, obtaining the corresponding dual-track coverage rate, and then updating the priority score of the seeds. The random walk phase includes: randomly selecting application process identifiers from the application process identifiers and the random application process identifier extension space of the white-box knowledge base to randomly generate function codes and payloads, constructing test cases, and sending them to the small satellite operation simulator to perform fuzz testing through step S3. If a new coverage is triggered, a seed is constructed according to the corresponding test cases and added to the seed corpus. The processing steps of the genetic mutation stage of the corpus include: calculating seed weights based on the priority scores of various sub-seeds in the seed corpus; using the proportion of each sub-seed weight in the total weight of all seeds in the seed corpus as the sampling probability, and determining the parent seed by sampling through the cumulative distribution function; performing genetic mutation operations based on the parent seed to generate offspring seeds, adding them to the seed corpus, and increasing the priority score of the parent seed.

8. The fuzz testing method for satellite network protocols according to claim 7, characterized in that, The genetic mutation operation includes: randomly selecting a mutation operator based on the parent seed to perform mutation and generate offspring seeds; The mutation operator includes: Bit flipping is used to randomly select a bit of a byte in the payload and invert it; Byte flipping is used to randomly select a byte in the payload and replace it with a random value. Byte insertion, used to insert 1 to 8 random bytes at random positions; Byte deletion, used to randomly delete 1 to 4 consecutive bytes from the payload; PID Mutation: Used to replace the application process identifier with a known application process identifier in the white-box knowledge base, a low-order XOR variant of the current application process identifier, or a random value; Function code mutation: Replaces the function code with a protocol reserved value, an XOR variant of the current function code, or a random value; High-intensity mutation: Perform 2 to 8 cascade mutations on the remaining mutation operators in random combinations.

9. A fuzz testing method for satellite network protocols according to claim 1, characterized in that, The update rules for the priority score of the seed include: If new EVS event coverage or gcov basic block coverage is generated after the test cases are built and executed according to the selected seed in step S4, the priority score of the seed is amplified according to the preset amplification factor; if no new EVS event coverage or gcov basic block coverage is generated, the priority score of the seed is reduced according to the preset reduction factor. The structured test report includes the following fields: total number of test executions, total number of new coverage points, EVS event coverage point list, path hash set size, gcov basic block coverage number, total corpus size, crash event record list, high-value seed list, and input records that triggered new coverage.

10. A fuzz testing system for satellite network protocols, characterized in that, It includes a memory and a processor, the memory storing a computer program, and the processor calling the computer program to perform the steps of the method as described in any one of claims 1 to 9.

Images