A description language tool for protocol fuzzing

Abstract

The application discloses a description language tool for protocol fuzz testing, comprising a PDL module for defining protocol message structure, session state and inter-field association, an analysis module for analyzing the PDL definition into an intermediate representation, a fuzz testing engine for generating a use case by adopting a three-stage encoding pipeline according to the intermediate representation and session context, and an execution module for sending the use case and receiving a response. The PDL of the tool supports bit-level precision, composite structure and inheritance mechanism, the fuzz testing engine is internally provided with a semantic perception variator, and a single definition is used to realize bidirectional semantics, so that the consistency of use case generation and response analysis is realized. The tool realizes accurate modeling and dynamic simulation of a complex protocol through a unified description language, and significantly improves the efficiency, coverage and maintainability of the fuzz testing.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of protocol fuzzing, and particularly relates to a description language tool for protocol fuzzing. BACKGROUND

[0002] There are various network protocols and binary communication protocols, and many protocols have non-byte-aligned fields, complex nested structures, conditionally appearing fields and dynamically changing lengths. In order to ensure the security and robustness of the protocol implementation, fuzzing is widely used to find implementation defects. However, the main problem of the existing message generation and analysis tools for fuzzing is that the expression ability is limited when dealing with complex protocols, and it is difficult to accurately model messages with non-byte-aligned fields, complex nested structures, conditionally appearing fields and TLV (Tag-Length-Value) structures and other characteristics, resulting in the separation of message definition and specific implementation, and further causing the inconsistency of coding and analysis logic, increasing the development error and maintenance cost.

[0003] At the same time, the description language tool is difficult to express customized protocol field calculation such as length, check, dynamic flag and encryption prefix value under a unified framework. Due to the lack of effective reuse mechanism, the repeated definition of similar messages also increases the maintenance burden. In addition, the existing tools usually cannot be used for both generation (coding) and analysis (decoding) of message definition. The verifiability and playback of fuzzing test cases are affected, and the context association, dynamic calculation and value semantic support of message fields are limited, which is difficult to meet the testing needs of complex protocols, especially those that require specific call order and state management. At the same time, the built-in management and display capability of enumeration values such as function codes is also not conducive to the value variation strategy design of the fuzzing engine and the readability of the analysis result, therefore, a description language tool for protocol fuzzing is needed. SUMMARY

[0004] The present application relates to the technical field of protocol fuzzing, and particularly relates to a description language tool for protocol fuzzing.

[0005] In order to achieve the above-mentioned purpose, the technical scheme adopted by the present application is as follows:

[0006] A description language tool for protocol fuzzing, comprising:

[0007] A protocol description language (PDL) module for defining protocol message structure in text form, the protocol description language (PDL) module being used to define the field type, bit width, default value and composite structure of the protocol message, and being used to define the session state and state transition rules of the protocol to form a state machine model;

[0008] The parsing module is used to parse the protocol message structure and state machine model defined by the PDL into an intermediate representation;

[0009] A fuzzing engine is used to generate fuzzing test cases based on the intermediate representation. The fuzzing engine can dynamically select and generate fuzzing test cases that match the current session state based on the state machine model.

[0010] The execution module is used to send the fuzz test cases to the target program and receive the response from the target program.

[0011] Furthermore, the Protocol Description Language (PDL) module is used to specify association functions in the message field definition, which are used to dynamically calculate field values ​​and to perform verification during parsing.

[0012] Furthermore, the fuzzing engine employs a three-stage coding pipeline when generating the fuzzing test cases, the pipeline including:

[0013] In the first stage, the logical value of the field is calculated by calling the association function;

[0014] In the second stage, the logical value is encoded into a raw byte sequence;

[0015] In the third stage, pluggable custom byte transformations are applied to the byte sequence to implement CRC appending, check permutation, or encryption operations.

[0016] Furthermore, the Protocol Description Language (PDL) module is used to define a context mechanism for storing and managing session-related dynamic data during fuzzing, including but not limited to session IDs, sequence numbers, or tokens.

[0017] Furthermore, after receiving the response from the target program, the execution module is configured such that the parsing module writes the parsed field values ​​from the response into the context by calling the associated function.

[0018] Furthermore, the fuzzing engine generates subsequent fuzzing test cases based on the dynamically updated data in the context, which are used to implement dynamic session simulation and support protocol state association and dynamic session simulation test scenarios.

[0019] Furthermore, the Protocol Description Language (PDL) module is configured with a message inheritance mechanism, which allows child definitions to inherit fields and attributes from parent definitions and to customize differences by overriding or appending fields, thereby reducing maintenance costs.

[0020] Furthermore, the fuzz test engine is configured with a semantic-aware mutant, which is used to maintain or break the semantic association between fields in the message, including maintaining or breaking consistency between the length field and the corresponding data field.

[0021] Furthermore, the Protocol Description Language (PDL) module supports defining bit fields, which are integers with a width of 1 bit to 1024 bits. The bit field module can combine multiple small bit fields into a logical integer or split them bit by bit to express common flag bits and misaligned fields in the protocol.

[0022] Furthermore, the Protocol Description Language (PDL) module supports adding a value enumeration table to integer type fields. The value enumeration table is used to store the integer values ​​and their corresponding names. The fuzzing engine can limit the range of mutations to a preset set of enumerated values ​​based on the value enumeration table.

[0023] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0024] By supporting bit-level (1-1024 bit) integers, TLV, condition fields, lists, and nested blocks, the tool has strong expressive power and can adapt to complex protocols. In addition, the tool also uses unified bidirectional semantics to enable the same message definition to be used for both encoding and parsing, thereby reducing inconsistencies and improving the reliability of test case playback, comparison, and defect confirmation.

[0025] Through a three-stage pipeline and associative function mechanism, users can inject custom logic into each stage such as field value calculation, byte encoding, and byte transformation, thereby achieving high scalability and customizability. This meets the unique computational requirements of the protocol, such as length, CRC, signature, and encryption. Through the built-in semantically aware mutant and bit-level mutation capabilities, fuzzing can generate more semantically relevant or targeted destructive inputs, thereby improving fuzzing efficiency and coverage and triggering potential vulnerabilities faster.

[0026] Furthermore, by supporting inheritance and reuse mechanisms, it allows for rapid modeling of similar protocols / versions, thereby reducing maintenance costs and facilitating long-term maintenance and version evolution. Through its plug-in design, it facilitates integration and automation, enabling integration with existing fuzzing frameworks (such as AFL, libFuzzer, and custom network replayers), supporting automated testing processes, result replay, and minimization. Simultaneously, through intelligent enumeration support, it guides the mutation range, reduces invalid input, and can directly display semantic information during parsing, facilitating problem localization. Moreover, through context-driven dynamic generation, it can realize advanced testing scenarios such as protocol state association and dynamic session simulation, thereby improving the efficiency and accuracy of vulnerability discovery. Attached Figure Description

[0027] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used together with the embodiments of the invention to explain the invention and do not constitute a limitation thereof.

[0028] Figure 1 This is a schematic diagram of the overall system architecture of the description language tool for protocol fuzz testing proposed in this invention;

[0029] Figure 2 This is a flowchart illustrating the three-stage coding pipeline used by the fuzzy testing engine to generate test cases in an embodiment of the present invention.

[0030] Figure 3 This is a schematic diagram of the workflow of dynamic session simulation in an embodiment of the present invention;

[0031] Figure 4 This is an example diagram of the PDL message structure definition in an embodiment of the present invention;

[0032] Figure 5 This is a schematic diagram of the context data flow in an embodiment of the present invention. Detailed Implementation

[0033] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0034] like Figure 1 As shown, this invention provides a description language tool for protocol fuzzing. It is used to uniformly model the protocol message structure, dynamic session state, and field relationships through an extensible description language that supports bit-level precision. The established model is then used to guide a fuzzing engine with a three-stage coding pipeline and context awareness, enabling efficient and intelligent fuzzing of complex protocols.

[0035] In a specific embodiment of the present invention:

[0036] like Figure 1 As shown, a protocol description language tool for fuzzing includes the following main components: a Protocol Description Language (PDL) module, a parsing module, a fuzzing engine, and an execution module, wherein:

[0037] Protocol Description Language (PDL) module: As the system's input layer, it is responsible for receiving protocol definition files written by users in text form. Its purpose is to provide a highly expressive and extensible language for accurately describing the static structure, dynamic behavior, and field relationships of protocols.

[0038] Parsing Module: As the system's intermediate processing layer, it is responsible for parsing the text definitions input from the PDL module into a computer-understandable intermediate representation (IR). Its role is to ensure syntactic correctness and provide a structured, operable data model for the subsequent fuzzing engine.

[0039] The fuzz testing engine, as the core decision-making and generation layer of the system, is responsible for generating fuzz test cases based on the IR (Information Representation) provided by the parsing module. Its role is to integrate multiple mutation strategies and combine them with contextual information to achieve intelligent and efficient test case generation.

[0040] Execution Module: As the system's output and interaction layer, it is responsible for sending the generated fuzz test cases to the target program and receiving its response. Its role is to act as a communication bridge between the fuzz testing tool and the external system under test.

[0041] Context Management Module: As the system's dynamic data layer, it is responsible for storing, updating, and managing all dynamic data (such as session ID, sequence number, status, etc.) throughout the fuzzing session. Its role is to provide the fuzzing engine with stateful, memory-based context information to support dynamic session simulation.

[0042] The division logic of each module follows the functional hierarchy, from user input (PDL) to internal processing (parsing, engine), then to external interaction (execution), and finally to dynamic data maintenance (context management), working together. The overall technical process and the collaborative working method of each module are detailed below.

[0043] Protocol Description Language (PDL) module

[0044] The Protocol Description Language (PDL) module is a text-based declarative language. Its syntax borrows concepts from programming languages ​​such as structs, enumerations, and functions. For example, an IPv4 packet can be defined as a Packet structure containing multiple fields, with the Enum keyword defining the enumerated value of the protocol number and the func function defining the checksum calculation. This allows for precise description of complex protocol packet structures and session logic, including:

[0045] Common field types and composite structures:

[0046] Basic field types: Supports bit-integers, with configurable lengths from 1 bit to 1024 bits to meet the requirements of non-byte alignment protocols. In addition, it also supports basic types such as fixed-length / variable-length strings, bytes, floating-point numbers (IEEE 754), and boolean values.

[0047] Composite field types: Supports Block (ordered collection of fields), TLVBlock (natively supports Tag-Length-Value structure), ConditionalBlock (conditional occurrence based on expression or preceding field value), List / Array (supports fixed and variable length), and embedded descriptions for special fields such as JSON / XML.

[0048] Enumeration support: Integer types can be appended with an enumeration table to store values ​​and their corresponding names, which facilitates the design of mutation strategies in the fuzzing engine and improves the readability of the parsing results.

[0049] See Figure 4 As shown, it graphically displays the PDL definition of a specific protocol message (such as the IPv4 protocol), including the bit width, type, nesting structure, and associated functions of the fields.

[0050] Dynamic session modeling:

[0051] This invention abstracts the protocol session into a state machine model. The PDL supports defining session states and state transition rules. For example, a protocol session can be defined as starting from the INIT (initialization) state and entering the AUTHENTICATED (authenticated) state after sending a Login message, thereby realizing the modeling of complex protocol call sequences.

[0052] Associative functions and context mechanisms:

[0053] Protocol Description Language (PDL) allows specifying associated functions in field definitions for dynamically calculating field values ​​(such as length and checksum) and calling external scripts or library functions (such as calculating CRC and signature). The PDL module also supports:

[0054] The context mechanism allows fields to directly reference existing values ​​in the context during encoding (e.g., referencing the session_id from a previous message), enabling automatic assignment of configuration or associated fields. During decoding, the parsed field values ​​are automatically written into the context for use in subsequent message encoding or functions.

[0055] Inheritance and reuse mechanisms:

[0056] PDL supports message / block inheritance, where child definitions can inherit fields and attributes from parent definitions, and can be customized by overriding or appending fields, thereby significantly reducing the burden of repeatedly defining and maintaining similar messages.

[0057] The parsing module is responsible for performing lexical and parsing analysis on the user-written PDL file, generating an internal Abstract Syntax Tree (AST) or Intermediate Representation (IR). This module ensures the correctness of the PDL syntax rules and transforms the text definition into a program object that the fuzzing engine can understand and execute.

[0058] It should be noted that the parsing module uses an LL(1) parser to parse the PDL file: First, the lexical analyzer segments the PDL text into a series of tokens (such as Packet, bit_integer, name, etc.); then, the parser constructs an abstract syntax tree (AST) from the token stream according to preset syntax rules. After the AST is constructed, the parsing module performs semantic analysis to verify the reference relationships between fields (such as whether the field pointed to by the Length field target exists), the correctness of the association function, etc., and finally converts the AST into an intermediate representation (IR) that can be directly called by the fuzzing engine. This IR can be a tree structure composed of Python or Java objects.

[0059] The fuzzing engine is used to perform fuzzing tests on protocols based on the intermediate representation generated by the parsing module. Its key processes include:

[0060] Dynamic use case generation: The engine selects and generates messages that match the current session state based on the state machine model defined in PDL;

[0061] like Figure 2 As shown, test case generation employs a three-stage coding pipeline, specifically:

[0062] Phase 1 (Value Calculation): Logical values ​​are calculated for message fields. This phase retrieves dynamic values ​​or calculates field values ​​(such as length and sequence number) from the session context by calling the associated functions defined in the PDL.

[0063] The second stage (Value → Bytes) encodes the calculated logical value into a raw byte sequence according to its type and bit width. This stage supports big-endian / little-endian, bit order definitions, and bit packing that is not byte-aligned.

[0064] The third stage (Byte Transform): Apply pluggable custom byte transformation plugins to the generated byte stream, such as adding CRC checksums, performing specific encryption or obfuscation;

[0065] It should be further explained that the three-stage coding pipeline can be formally expressed in the following pseudocode:

[0066] def generate_fuzz_case(packet_ir, session_context):

[0067] #Phase 1: Field Numerical Calculation

[0068] calculated_values=calculate_values(packet_ir, session_context)

[0069] #Phase Two: Numeric to Byte Encoding

[0070] raw_bytes=encode_to_bytes(calculated_values)

[0071] #Phase 3: Byte Transformation

[0072] final_bytes=apply_byte_transformations(raw_bytes, packet_ir) returnfinal_bytes

[0073] The `calculate_values` function iterates through all fields and dynamically calculates the final logical value for each field based on the association functions and context data defined in the PDL. The `encode_to_bytes` function packages these values ​​into a raw byte sequence according to rules such as bit width and byte order. The `apply_byte_transformations` function then calls an external plugin to perform the final transformation on the entire byte sequence.

[0074] Semantic-aware mutation, specifically, involves the engine's built-in semantic-aware mutant, which automatically mutates field values ​​based on field type, constraints, and contextual association functions. The mutant supports the following:

[0075] Value mutation: For Integer or Enum fields, they can be mutated into boundary values, negative values, or preset enumeration values;

[0076] Structural variation: Maintaining or breaking consistency between the length field and the corresponding data field to test the protocol parsing logic;

[0077] It should be noted that the mutant of the invention can selectively obfuscate the semantic relationships between fields in a message. For example, for a message, its length field (L) is related to its data payload (P). The mutant can generate two types of use cases:

[0078] Compliant mutation: Maintaining consistency between L and P. The mutant first performs random mutation on P to obtain a new load P′, and then, according to... The actual length L'$ is used to update the value of the L field, thereby ensuring that the entire message format is compliant.

[0079]

[0080]

[0081]

[0082] Disruptive mutation: Breaks the consistency between L and P. The mutant independently mutates L and P to obtain a new length. and new load However, it is not mandatory for the two to be consistent.

[0083]

[0084]

[0085]

[0086] This targeted mutation strategy can more effectively test the robustness of the target program when handling malformed messages.

[0087] Among them, destructive mutations are used to generate unaligned insertions, truncations, or excessively long / short messages to test the robustness of the protocol implementation;

[0088] Execution and parsing module:

[0089] Single definition, two-way semantics: After the execution module sends the test cases generated by the fuzzing engine to the target program, it receives the response from the target program. The parsing module uses the same PDL definition as the generated test cases to parse the response.

[0090] Context-driven dynamic session simulation: When parsing the response, the parsing module writes the dynamic values ​​(such as the new session_token) parsed from the response into the session context by calling the association function defined in the PDL. The fuzzing engine generates the next message based on this updated context, thereby realizing dynamic simulation and fuzzing of complex session processes (such as login, data transmission, and logout).

[0091] In this embodiment, the data interaction process is as follows:

[0092] The Protocol Description Language (PDL) module connects to the parsing module, passing PDL files via file paths or text streams;

[0093] The parsing module connects to the fuzzing engine. After parsing is complete, the IR is passed to the fuzzing engine through object references in memory.

[0094] After generating a complete binary message, the fuzzing engine passes it to the execution module as a byte array (byte[]).

[0095] The execution module communicates with the target program through network protocols such as TCP / IP and UDP, or application layer protocols such as HTTP / gRPC.

[0096] like Figure 3 As shown, the interaction sequence in the dynamic conversation simulation scenario is as follows:

[0097] Upon system startup, the parsing module first performs lexical, syntactic, and semantic analysis on the user-provided PDL file, transforming it into an intermediate representation (IR) that the fuzzing engine can understand and execute. This IR includes all message structure definitions, field association functions, session states, and state transition rules. Subsequently, the fuzzing engine initializes a session based on this IR and creates a context management module to maintain session data.

[0098] The fuzzing engine starts, parses the PDL file, and creates a new session context. The context management module initializes the SessionContext, setting its initial state to State.INIT;

[0099] The engine recognizes the current state as INIT and generates a LoginRequest message based on the PDL definition. The username field in this message can reference a pre-defined username from the context.

[0100] The execution module sends the LoginRequest to the target program and waits for a response.

[0101] After receiving the response, the execution module passes it to the parsing module. The parsing module uses the same PDL definition to parse the response, for example, to identify the LoginSuccess or LoginFailure message;

[0102] The state and context are updated. If a LoginSuccess message is parsed, the parsing module writes the session_token in the message into the session context and notifies the context management module to update the session state from INIT to LOGGED_IN.

[0103] The state transition logic is predefined in the PDL. When the parsing module identifies a specific message such as LoginSuccess or LoginFailure, it triggers the corresponding transition rules. For example, if the response message type is LoginSuccess, the state machine transitions from the INIT state to the LOGGED_IN state and executes the on_success association function; if it is LoginFailure, it maintains the INIT state or transitions to the ERROR state. The programmable state machine ensures a high degree of consistency between the fuzzing process and the actual protocol logic.

[0104] Once the engine recognizes the new state LOGGED_IN, it will generate a message (such as DataTransferRequest) that matches the state and fill it with the session_token obtained in the previous step from the context, thereby achieving a complete stateful session fuzz test.

[0105] To better understand the technical solution of this invention, the following section uses the tools of this invention to perform fuzz testing on the IPv4 protocol for further explanation.

[0106] Scenario setting: Perform fuzz testing on the IPv4 protocol processing module of an IP router or firewall.

[0107] The steps are as follows:

[0108] S1: Users define the IPv4 packet structure using the Protocol Description Language, including:

[0109] version field (4 bits, fixed value 4);

[0110] The header_length field (4 bits, used by an associative function to calculate the header length);

[0111] The total_length field (16 bits, used by the association function to calculate the total length of the message).

[0112] The header_checksum field (16 bits, checksum calculated using an associative function);

[0113] payload field (variable length);

[0114] See Figure 5 As shown, it uses a flowchart to illustrate how context data is passed and updated between different modules during a dynamic session simulation.

[0115] S2: The fuzzing engine fuzzes the defined IPv4 packets, where:

[0116] The engine's built-in mutant identifies the association between the header_length and total_length fields and the actual data length, generating two types of fuzzy use cases:

[0117] Compliance use case: Keep header_length and total_length consistent with the actual data length, but mutate the payload field to test its ability to process legitimate but abnormal data packets.

[0118] Destructive use cases: Generate messages with header_length or total_length that do not match the actual length to test the robustness of the protocol stack when handling malformed messages, such as potentially triggering a buffer overflow.

[0119] S3: The execution module sends the generated test cases to the target router. Simultaneously, it monitors the router for anomalies in real time using logs or crash monitoring tools.

[0120] S4: If the router crashes due to a specific use case, this tool can replay the generation process of the use case based on the original PDL definition and perform test-case reduction to generate a minimal message that can stably reproduce the vulnerability, making it easier for developers to locate and fix it.

[0121] The fuzzing process will continue to loop until a preset termination condition is met. The termination condition may include, but is not limited to: reaching a preset test time, the number of generated test cases reaching a threshold, or the target program code coverage not significantly improving within a specified time.

[0122] In a preferred implementation: In a multi-task concurrent fuzzing scenario, the fuzzing engine is deployed as a containerized plugin, and a central scheduler is used for task distribution and load balancing. When the plugin load is too high, the scheduler can dynamically create new container replicas for scaling up; when the load decreases, it automatically scales down, thereby further improving the concurrency efficiency and resource utilization of fuzzing, which is particularly suitable for large-scale distributed testing.

[0123] It should be noted that the containerized plugin solution avoids environmental conflicts between different tasks by running each fuzzing task in an independent container environment, thereby solving the problems of complex configuration and high replication cost of existing fuzzing environments, and enabling tasks to run independently without interfering with each other.

[0124] In addition, through load balancing and dynamic scaling mechanisms, when the system load is too high, the scheduler can automatically create new container replicas for scaling; when the load decreases, redundant replicas are removed, ensuring that the system can efficiently utilize resources and effectively complete multiple test tasks with fewer system resources, which is particularly suitable for large-scale distributed testing scenarios.

[0125] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A description language tool for protocol fuzz testing, characterized in that, include: A protocol description language module is used to define the structure of protocol messages in text form. The protocol description language module is used to define the field types, bit widths, default values ​​and composite structures of the protocol messages, and to define the session states and state transition rules of the protocol to form a state machine model. The parsing module is used to parse the protocol message structure and state machine model defined by the protocol description language module into an intermediate representation; A fuzzing engine is used to generate fuzzing test cases based on intermediate representations. The fuzzing engine can dynamically select and generate fuzzing test cases that match the current session state based on the state machine model. And an execution module, used to send fuzz test cases to the target program and receive the response from the target program; The protocol description language module is used to specify association functions in the message field definition. The association functions are used to dynamically calculate field values ​​and to perform verification during parsing. The fuzzing engine employs a three-stage coding pipeline when generating the fuzzing test cases, the pipeline including: In the first stage, the logical value of the field is calculated by calling the association function; The second stage encodes the logical values ​​into raw byte sequences; In the third stage, pluggable custom byte transformations are applied to the byte sequence to implement CRC appending, check permutation, or encryption operations. The protocol description language module is used to define a context mechanism, which is used to store and manage session-related dynamic data during fuzzing, including session ID, sequence number, or token. The execution module is used to, after receiving the response from the target program, have the parsing module write the parsed field values ​​from the response into the context by calling the association function; The fuzzing engine generates subsequent fuzzing test cases based on the dynamic data updated in the context, which are used to implement dynamic session simulation and support protocol state association and dynamic session simulation test scenarios.

2. The description language tool for protocol fuzz testing according to claim 1, characterized in that, The protocol description language module is configured with a message inheritance mechanism, which allows sub-definitions to inherit fields and attributes from parent definitions and to customize differences by overriding or appending fields, thereby reducing maintenance costs.

3. The description language tool for protocol fuzz testing according to claim 1, characterized in that, The fuzz test engine is equipped with a semantic-aware mutant, which is used to maintain or break the semantic association between fields in the message, including maintaining or breaking consistency between the length field and the corresponding data field.

4. The description language tool for protocol fuzz testing according to claim 3, characterized in that, The protocol description language module is configured with a bit field module for defining bit fields, wherein the bit field width is an integer ranging from 1 bit to 1024 bits. The bit field module can combine multiple small bit fields into a logical integer or split them bit by bit to express common flag bits and misaligned fields in the protocol.

5. The description language tool for protocol fuzz testing according to claim 4, characterized in that, The protocol description language module supports adding a value enumeration table to integer type fields. The value enumeration table is used to store integer values ​​and their corresponding names. The fuzzing engine can limit the range of variation to a preset set of enumeration values ​​based on the value enumeration table.

Images