1 Introduction↩︎

Deep neural networks (DNNs) have become a foundational component of modern computing systems, enabling a wide range of applications such as computer vision [1], natural language processing [2], and edge intelligence [3]. These models often embody significant intellectual property, as their development requires substantial investment in data collection, model design, and large-scale training [4]. In practice, DNN models are increasingly compiled into executable binaries and deployed locally, which is similar to traditional software distribution, to avoid the latency, communication overhead, and potential privacy leakage associated with remote inference [5]–[10]. However, the deployment paradigm also exposes DNN binaries to adversaries, who can leverage reverse engineering techniques to recover valuable model assets, including architectures and parameters, leading to serious model theft risks [11]–[13]. Therefore, protecting the proprietary assets embedded in DNN binaries has become a critical problem.

To this end, recent research has adopted code obfuscation techniques to prevent DNN binaries from reverse engineering. On one hand, ModelObfuscator [14] and NeuroShield [15] achieve the protection by modifying model representations and structures, such as operator renaming, operator fusion, operator computation reconstruction, leaving the data and operations exposed during the runtime. Thus, they are vulnerable to information extraction by dynamic analysis. On the other hand, DynaMO [16] obfuscates linear operations at the beginning of inference, after which the DNN computation is performed on the protected information during execution, and the results are then recovered at the end. Although it improves resilience to dynamic analysis, the method can only protect linear operations, which are guaranteed to be invertible for recovery, whereas non-linear operations are pervasive in modern DNNs, e.g., Sigmoid and Softmax. More fundamentally, the two kinds of methods largely focus on transforming program representation and execution structures rather than protecting the underlying numerical computation. Namely, they offer limited protection against analysis techniques that reason about computation semantics (e.g., black-box deobfuscation [17]), and do not provide dedicated protection for floating-point operations, which constitute the core of DNN execution.

In this paper, we propose FLOB¹, an obfuscation framework to protect floating-point computations in deployed DNN binaries. The key insight of this work is that floating-point computation can be lifted into a higher-precision representation space, where values can be scaled into integers. The transformation enables bitwise operations over the resulting representation, making mixed boolean-arithmetic (MBA) applicable while preserving the original numerical semantics. Specifically, FLOBfirst lifts floating-point values into a higher-precision binary representation, applies MBA transformations at the representation level, and performs the entire computation in this transformed domain. Only the final results are projected back to the target precision. In this way, the computation preserves the original semantics without introducing additional numerical error. As a result, FLOBdirectly protects floating-point computation and is not restricted to specific operator types. This enables it to provide robust protection against reverse engineering attacks [12], dynamic analysis [11], [13], and black-box deobfuscation [17].

We evaluate FLOBon seven real-world DNN models, spanning five CV and two NLP models. The results show that it effectively increases the difficulty for existing reverse engineering and deobfuscation techniques to extract sensitive information from DNN binaries, outperforming state-of-the-art obfuscation schemes. Meanwhile, it introduces no additional numerical error, preserving the computation correctness, and enables flexible trade-off between protection and performance. In particular, FLOBreduces the operator recovery rate of BTD, a representative reverse engineering analyzer, to 4.51%, achieving a reduction of more than 30 percentage points relative to NeuroShield, a state-of-the-art obfuscator for DNN binaries.

In summary, the paper makes the following contributions:

• We propose FLOB, an obfuscation scheme to protect floating-point computations in DNN binaries with MBA obfuscation. It reinterprets floating-point numbers in a higher-precision representation space, which enables bitwise transformations without violating numerical semantics.

• FLOBperforms computation in a lifted domain and restores results only at the end, preserving correctness without introducing additional numerical error.

• We have implemented a prototype of FLOBand evaluated it on real-world DNN models. The results show that it improves resistance against state-of-the-art reverse engineering and deobfuscation techniques while preserving computational correctness and allowing flexible trade-off between protection and performance.

2 Background and Motivation↩︎

In this section, we first review the representation and arithmetic properties of floating-point numbers under the IEEE-754 standard, which form the basis of DNN computation, and introduce mixed boolean-arithmetic (MBA) transformations, a class of equivalence-preserving techniques widely used for obfuscating integer computations. We then discuss the limitations of directly applying MBA to floating-point computation, highlighting the inherent gap between numerical semantics and representation-level operations.

2.1 IEEE-754 Floating-Point Numbers↩︎

The IEEE-754 is a technical standard that defines how real-valued numbers are represented and computed in modern computing systems [18]. It is designed to provide a finite-precision approximation of real numbers while ensuring well-defined and consistent numerical semantics across different platforms. Such a representation is fundamental to DNN computation, where most operations are performed using floating-point formats.

Under IEEE-754, a floating-point number is encoded using three components: a sign bit \(S\) to indicate the sign of the number, an exponent \(E\) to determine the scaling factor, and a mantissa \(M\) to encode the significant bits of the number. Then, a normalized single-precision (FP32) number is represented as: \[FPN_{32} = (-1)^S \times (1.M) \times 2^{E-127}, \label{eq:fpn32}\tag{1}\] where the constant \(127\) denotes the exponent bias for FP32. Figure 1 shows an example of 32-bit floating-point number. It can be decomposed into a sign bit \(S=0\), an exponent field \(E=01111100\), and a mantissa field of \(M=010\ldots0\). The corresponding value is: \((-1)^0 \times (1.01)_2 \times 2^{124-127} = (1.01)_2 \times 2^{-3} = (0.00101)_2\), i.e., \(0.15625\).

Notably, IEEE-754 represents real values using finite precision, and many decimal numbers, e.g., \(0.1\) or \(0.2\), cannot be represented exactly in binary form. Arithmetic operations are therefore subject to rounding, introducing small numerical deviations depending on precision and evaluation order. Despite this, the standard ensures consistent numerical semantics for floating-point computation.

2.2 Bitwise Operations and MBA Obfuscation↩︎

Bitwise operations manipulate data at the level of individual bits and form the basis of many low-level program transformations. Common operators include AND, OR, and XOR, which operate at the bit level and follow basic Boolean logic.

Mixed boolean-arithmetic (MBA) [19] transformations combine bitwise and arithmetic operations to construct expressions that are functionally equivalent but syntactically more complex. For instance:

. Such transformations preserve the original computation semantics while significantly altering the structure of the expression, making them widely used in code obfuscation, i.e, MBA obfuscation.

From a perspective of software protection, obfuscation aims to increase the cost of reverse engineering rather than prevent program understanding entirely. Although advanced deobfuscation techniques, such as solver- and synthesis-based simplification [20]–[22], are able to simplify such expressions in principle, MBA obfuscation typically incurs substantial computational and manual effort for these approaches, making large-scale and automated recovery less practical in real-world scenarios.

It is worth noting that the correctness of MBA transformations depends on a close alignment between representation-level operations and numerical semantics, which naturally holds for integer computation. However, as discussed next, this alignment does not directly extend to IEEE-754 floating-point computation, where the relationship between bit-level representation and numerical semantics is more intricate.

2.3 MBA for Floating-Point Numbers↩︎

Despite its effectiveness in software protection, MBA obfuscation cannot be extended to IEEE-754 floating-point numbers. The limitation stems from the fundamental differences between bitwise computation and floating-point computation.

1. Mismatched Semantics: In IEEE-754, the bit pattern of a floating-point number does not directly correspond to its numerical value. As shown in Figure 1, a number is composed of structured fields, including Sign, Exponent, and Mantissa, and its value is determined through exponent scaling and normalization. Consequently, bitwise operations on the fields lead to unpredictable changes in the underlying value, breaking the numerical semantics required by correct obfuscation.

2. Rounding Errors: Floating-point arithmetic in IEEE-754 is inherently approximate due to finite precision and rounding. As a result, the numerical outcomes vary with evaluation order and precision. This imprecision breaks the deterministic and semantics-preserving equivalence across different expressions, which is required by MBA obfuscation.

To address the above limitations, FLOBlifts floating-point values into a higher-precision representation space, where computations are performed while preserving numerical semantics, and only the final results are projected back to the target precision. Therefore, it not only aligns representation-level operations with numerical semantics, but also maintains sufficient precision throughout the computation, eliminating intermediate rounding effects and preserving deterministic equivalence, thereby enabling MBA obfuscation for floating-point numbers.

3 Design↩︎

In this paper, FLOBis designed to be integrated into the model compilation pipeline to protect sensitive computation before deployment. It is intended for use by model developers, applying obfuscation to IEEE-754 floating-point computations at compilation time. The resulting binary is then distributed for inference, serving as the deployment artifact without requiring any modification at runtime. Notably, FLOBmaintains separate representations for values that would otherwise be indistinguishable under IEEE-754 rounding at the native precision, and special cases, e.g., signed zeros and NaNs, are handled explicitly to preserve well-defined semantics.

Figure 4 illustrates the overall workflow of FLOB. Starting from model source code, FLOBfirst lowers the computations into intermediate representation (IR), and then decomposes original complex operations into reduced IR via Operation Reduction (§3.1). It subsequently replaces selected operations with semantically equivalent MBA expressions to achieve Floating-Point Computation Obfuscation (§3.2). To this end, FLOBmaintains a repository of pre-constructed expressions and reuses them whenever they satisfy the transformation requirements. Otherwise, it generates new expressions through Term Generation and Coefficient Solving, and incorporates them into the repository for future reuse. Finally, the obfuscated IR code is compiled into binary code for deployment.

3.1 Operation Reduction↩︎

After lowering model code into IR, floating-point computations are expressed as a mixture of operations with different algebraic properties. In particular, many of them are inherently non-linear and cannot be directly transformed using MBA-based techniques, which rely on compositions of bitwise and linear arithmetic operations. Therefore, to enable MBA obfuscation, FLOBreduces non-linear operations, i.e., multiplication and division between variables, into sequences of linear ones.

Algorithm 5 presents the process to carry out reduced floating-point multiplication. It first decomposes the two operands \(P\) and \(Q\) into their sign, exponent, and mantissa components (§2.1), where the mantissas are recovered together with the hidden bit (Line [alg:mul-reduce:opnd-dec-0]-[alg:mul-reduce:opnd-dec-1]). The sign and exponent of the result are then derived from those of the two operands (Line [alg:mul-reduce:se]). The mantissa multiplication is reduced using the shift-and-add procedure [23]. The multiplier mantissa \(m_q\) is scanned bit by bit, and whenever its least significant bit is \(1\), the current multiplicand mantissa \(m_p\) is accumulated into the running result \(m_r\) (Line [alg:mul-reduce:acc]). After each iteration, \(m_p\) and \(m_q\) are shifted separately, until all bits of \(m_q\) have been processed (Line [alg:mul-reduce:mp-shift]-[alg:mul-reduce:mq-shift]). Finally, the resulting floating-point value is reconstructed from the computed sign, exponent, and mantissa (Line [alg:mul-reduce:res]).

The reduction of floating-point division follows the same principle. The sign is still determined by the two operand signs, and the exponent is obtained by exponent subtraction, while the mantissa of the result is computed through the restoring-division method [24]. In this way, FLOBgenerates semantically equivalent IR code to replace the original floating-point multiplication and division operations in the target IR, providing a uniform basis for later obfuscation.

3.2 Floating-Point Computation Obfuscation↩︎

This section presents the core design of FLOBfor obfuscating floating-point computations. It performs transformations in a lifted representation domain, where floating-point values are manipulated through their binary expansions while preserving numerical semantics (§3.2.1). Based on the representation, FLOBconstructs MBA expressions using bitwise and linear arithmetic operations, then replaces target operations with their obfuscated counterparts. Specifically, the construction consists of two steps:

Finally, a running example is provided to o illustrate the complete obfuscation process (§3.2.4).

3.2.1 Floating-Point Representation in FLOB↩︎

Since the native IEEE-754 encoding is unsuitable for direct manipulation with bitwise operations, FLOBlifts the floating-point values and represents them by the binary expansion. Specifically, a value \(x\) is expressed as a finite sum of scaled binary digits: \[x = \pm (b_mb_{m-1}\cdots b_0 \mathpunct{.} b_{-1}b_{-2}\cdots b_l) = s\cdot\sum_{i=l}^m b_i\cdot 2^i, \label{eq:bitstring}\tag{2}\] where \(b_i\in\{0, 1\}\), \(s\in\{+1,-1\}\) denotes the sign, and \(m\) and \(l\) are determined by the precision of the original value. For special numbers, \(\pm0\) are treated as a single value \(0\), while \(\pm\)Inf and NaN are preserved and processed separately when encountered. Based on the representation, FLOBthen handles arithmetic and bitwise operations as follows.

Arithmetic Operations. FLOBconsiders only addition and scalar multiplication, which form the basis of MBA expressions. Subtraction is treated as addition with negative operand. It follows the general procedure of floating-point arithmetic, where alignment precedes the computation, while operating entirely on the binary expansion without rounding. For addition, operands are first aligned to share the same index range, i.e., that of \(i\) in Equation 2 . The result is then obtained by combining corresponding digits, with carries propagated across positions when necessary. Scalar multiplication is realized as a combination of shifts and additions over the binary expansion. For example, \[11 \cdot 0.11 = (0.11 \ll 1) + 0.11 = 1.1 + 0.11 = 10.01.\]

Bitwise Operations. Bitwise operations are not defined for floating-point number under IEEE-754 standard. Nevertheless, they can be meaningfully interpreted at the representation level by leveraging the binary expansion in Equation 2 . Specifically, given a floating-point value, FLOBreinterprets its fractional expansion under a fixed precision as an integer representation, performs the corresponding bitwise operation on the integer domain, and then projects the result back to the floating-point space with the same scaling factor. In this sense, the computation is purely representation-driven rather than mathematically defined over real numbers. For example, consider the operation \(3.75 \oplus 1.5\), i.e., \(11.11 \oplus 1.1\) in binary expansion form. Under a fixed 5-bit representation with 2 fractional bits, where the sign bit is included, the operands are scaled to integers as \(01111\) and \(00110\), respectively. The computation procedure is as follows: \[11.11 \oplus 1.1 = \frac{01111 \oplus 00110}{2^2} = \frac{01001}{2^2} = 10.01.\] As long as a sufficient precision is provided, the above computation does not introduce additional numerical error, since all operations are performed on exact integer representations and the scaling is deterministic. In practice, the bit-width is chosen to be large enough to cover the representable range of the target floating-point format. For instance, 129 bits are sufficient for single-precision floating-point numbers, if only the maximum magnitude is considered. However, if all IEEE-754 single-precision values, including subnormals, are to be represented exactly under a unified fixed scaling, the representation must also preserve the minimum precision of \(2^{-149}\). In that case, 278 bits are required in total, including one sign bit.

3.2.2 Term Generation↩︎

FLOBgenerates candidate terms that define the structural components of an MBA expression. The generation process is guided by configurable obfuscation requirements, including the number of operators within each term and the number of auxiliary variables to introduce redundancy. These constraints control the complexity and diversity of the generated terms, providing a flexible trade-off between complexity and overhead.

The process of the generation is described in Algorithm 7. FLOBfirst generates a set of auxiliary variables of size \(N_a\), which specifies the number of such variables in a term (Line  [alg:term-gen:av-gen]). It then initializes the term \(T_c\) by randomly sampling a variable from the union of variables in the target IR statement \(S\) and the auxiliary variable set (Line [alg:term-gen:var-sel]). Afterwards, FLOBincrementally constructs the term through a sequence of operator applications. In each iteration, an operator is randomly sampled from the available operator set \(O\), and applied to the current term (Lines [alg:term-gen:op-sel]–[alg:term-gen:update-1]). If the selected operator is binary, an additional variable is sampled from the same variable pool and incorporated into the term (Lines [alg:term-gen:if-cond]-[alg:term-gen:update-2]). This process continues until the number of applied operators reaches the required bound \(N_o\) (Line [alg:term-gen:loop-cond]). At last, the candidate term \(T_c\) is returned (Line [alg:term-gen:ret]), which serves as a building block for subsequent MBA expression construction.

Example. Figure 6 presents an example of FLOBto obfuscate an floating-point addition from a Conv2d computation, which appears in the helper function __tvm_parallel_lambda.116 (Line 3, Figure [fig:design:example:src-ir]). The candidate terms are generated under the configuration of two terms, one auxiliary variable (\(N_a=1\)), and three operators per term (\(N_o=3\)), as shown in Figure [fig:design:example:terms], where the two operands are denoted as \(opnd_0\) and \(opnd_1\), and the auxiliary variable is \(aux\). Taking the first term as an example, FLOBfirst samples \(aux\) to initialize the term. It then iteratively samples operators from \(\{\land, \lor, \lnot, \oplus\}\) to extend the term accordingly. \(\land\) is selected in the example, and since it is binary, \(opnd_0\) is sampled and combined with the current term, yielding \((aux\land opnd_0)\). The term is enclosed in parentheses to preserve the intended evaluation order. The process is repeated until the three operators are introduced, producing the final term \(((aux\land opnd_0)\oplus opnd_1)\lor opnd_0\). The second term, \((\lnot(opnd_1 \oplus opnd_0))\land opnd_1\), is generated in the same manner.

3.2.3 Coefficient Solving↩︎

Given the candidate terms, FLOBnext determines their coefficients so that the resulting linear combination is semantically equivalent to the original target statement. Supposing that the candidate terms are \(t_0, \ldots, t_k\), FLOBseeks coefficients \(c_0, \ldots, c_k\), such that \[\sum_{i=0}^k c_i\cdot t_i \equiv S,\] where \(S\) is the result of the original statement to be obfuscated.

The solving is carried out in the integer domain after floating-point values have been lifted and scaled (§3.2.1). FLOBthen solves the coefficients only over 1-bit operands, because, for linear MBA identifiers, equivalence on 1-bit variables also holds for integers of arbitrary bit width under the same expression form [19], [20]. Therefore, FLOBenumerates the truth table of the generated terms and the target expression in 1-bit space, deriving the corresponding linear constraints, and solves for a valid coefficient vector. The resulting coefficients are then used to instantiate the final MBA expression over the lifted integer representation. Algorithm 8 solves the coefficients of candidate terms through an iterative generate-and-solve procedure. It starts by repeatedly generating candidate terms until the required number of terms \(N_t\) is obtained (Line [alg:solving:loop-cond]-[alg:solving:cnt-update]). FLOBthen constructs the 1-bit truth table of both the target statement \(S\) and the candidate terms (Line [alg:solving:truth-table]), deriving a linear system whose unknowns are the coefficients of the candidate terms, and solves the system accordingly (Line [alg:solving:solve]). The process continues until a valid coefficient set is found (Line 9), which is then returned as the solution for the final MBA expression (Line [alg:solving:ret]).

Example. Given the candidate terms (Figure [fig:design:example:terms]), FLOBenumerates all possible values of \(opnd_0\), \(opnd_1\), and \(aux\) in 1-bit space, thereby constructing the truth table of \(term_0\) and \(term_1\), as shown in Figure [fig:design:example:truth-table]. It then builds the linear equation system as follows, where the left-hand side corresponds to the candidate MBA expression \(c_0\cdot term_0 + c_1\cdot term_1\), and the right-hand side is derived from the target statement \(opnd_0 + opnd_1\). The system is solved to yield the coefficient vector \([1, 1]^{\top}\). \[\begin{bNiceArray}{cc}[first-row] \mathbf{term_0} & \mathbf{term_1} \\ 0 & 0 \\ 0 & 0 \\ 1 & 0 \\ 1 & 0 \\ 1 & 0 \\ 1 & 0 \\ 1 & 1 \\ 1 & 1 \end{bNiceArray} \cdot \begin{bmatrix} c_0 \\ c_1 \end{bmatrix} = \begin{bNiceArray}{cc}[first-row] \mathbf{opnd_0} & \mathbf{opnd_1} \\ 0 & 0 \\ 0 & 0 \\ 0 & 1 \\ 0 & 1 \\ 1 & 0 \\ 1 & 0 \\ 1 & 1 \\ 1 & 1 \end{bNiceArray} \cdot \begin{bmatrix} 1 \\ 1 \end{bmatrix}\]

3.2.4 Running Example↩︎

Figure 6 summarizes the end-to-end obfuscation process of FLOBusing a floating-point addition extracted from a Conv2d computation. Given the addition statement in Figure [fig:design:example:src-ir], it generates candidate terms through randomized sampling (Figure [fig:design:example:terms]), and constructs the 1-bit truth table for coefficient solving (Figure [fig:design:example:truth-table]), obtaining the solution vector \([1, 1]^{\top}\) for the two terms. Figure [fig:design:example:obf-ir] shows the resulting obfuscated IR of the target operation. The original floating-point operands, together with the auxiliary variable, are first lifted into the integer domain with a scaling factor (Line 5-8), where BigNum is the data structure to represent the lifted integers. Then, the two terms are instantiated through the corresponding bitwise and linear arithmetic operations, and combined with their solved coefficients to form the MBA expression (Line 9-16). Finally, the transformed computation is evaluated and projected back to the IEEE-754 format to replace the original floating-point addition (Line 17-20).

4 Implementation↩︎

The prototype of FLOBsupports the obfuscation of double-precision floating-point computation in DNN models on the Linux platform. It adopts TVM [5] as the front-end to transform model files, e.g., ONNX, into LLVM IR. FLOBthen performs obfuscation on the IR code, which is developed in C++ with about 7,400 lines of code. Finally, it leverages the LLVM framework [25] as the back-end to compile the obfuscated IR into binaries.

To handle double-precision numbers, FLOBuses a lifted representation with fixed bounds \(l\) and \(m\), as shown in Equation 2 , allocating sufficient bits for both the integer and fractional parts. Additionally, FLOBprovides three configurable parameters, i.e., the number of terms, the number of operators per term, and the number of auxiliary variables, to control the structure and complexity of generated MBA expressions, as described in Algorithm 8 (§3.2.3).

5 Evaluation↩︎

In this section, we conduct empirical experiments to evaluate the effectiveness and capacity of FLOBwith the following research questions (RQs):

• RQ1: Correctness. Does FLOBpreserve the correctness of the original floating-point computation without introducing additional numerical error?

• RQ2: Effectiveness. How effective is FLOBin resisting existing reverse engineering and deobfuscation techniques?

• RQ3: Performance and Overhead. What is the practical cost of FLOBin terms of obfuscation cost and runtime overhead?

5.1 Evaluation Setup↩︎

FLOBuses \(l=-1120\) and \(m=1119\) in Equation 2 , so that both the integer part and the fractional part are allocated 1120 bits. This range is sufficient to cover the full value range of IEEE-754 double-precision numbers, from the largest finite value on the order of \(2^{1024}\) to the smallest positive subnormal value \(2^{-1074}\), while preserving enough precision for the transformed computation. In addition, unless otherwise specified, FLOBuses the default configuration of \(N_t=4\), \(N_o=4\), and \(N_a=2\) throughout the evaluation to generate MBA expressions, where the three parameters denote the number of terms, operators per term, and auxiliary variables respectively (Algorithm 8 in §3.2.3). This setting is used for all models to ensure consistency.

The evaluation is performed on the machine with AMD Ryzen Threadripper 3970X CPU @ 3.7GHz, 256GB memory, and Ubuntu 22.04.

5.1.1 Model Set and Datasets↩︎

Table ¿tbl:tab:dataset? summarizes the evaluated model set and the corresponding test input datasets. We use seven real-world DNN models, including five CV-CNN models and two NLP-Transformer models. For each model, we use a task-relevant test input dataset as the input source for evaluating the obfuscated binary, so as to evaluate correctness and practical overhead under realistic inference workloads.

The selected models also exhibit a nontrivial proportion of floating-point operations, with FP ratios ranging from 8.7% to 33.9%. The data is collected and measured on the corresponding LLVM IR, indicating that floating-point computation constitutes an important part of real-world DNN binaries, thereby justifying the need to protect floating-point semantics in practice. The last three columns of the table report the pre-obfuscation execution time, runtime memory usage, and executable binary size of each model, which serve as the baseline for quantifying the overhead introduced by FLOBafter obfuscation. In addition, the model set used in NeuroShield [15] is adopted as well in the comparison experiments.

5.1.2 Baseline Methods↩︎

We adopt the state-of-the-art and representative obfuscation schemes, deobfuscation methods, and reverse engineering techniques as baselines, including:

• NeuroShield [15], a state-of-the-art obfuscation framework to protect DNN binaries against reverse engineering.

• XSmir [17], a state-of-the-art black-box deobfuscation tool for recovering the semantics of heavily obfuscated code through program synthesis.

• GAMBA [26], a representative MBA deobfuscation tool based on algebraic rewriting.

• ProMBA [22], a representative MBA deobfuscation tool that combines program synthesis and term rewriting.

• BTD [11], a state-of-the-art reverse engineering method to generally recover operator-level semantics from DNN binaries.

Additionally, we consider several other related methods which are not included in the final evaluation. We further discuss the differences between FLOBand these excluded methods in Section 6.2. Loki [27] is a virtual machine-based obfuscation framework strengthened with extensive MBA transformations, and Tigress [28] is a source-to-source obfuscator for C programs supporting a broad range of anti-analysis transformations, including MBA obfuscation. Since both target traditional software protection over integer computations and control-flow structures, rather than floating-point computation obfuscation, we exclude them from direct comparison.

NeuReduce [29] is a neural-network-based MBA reducer for simplifying obfuscated MBA expressions. MBA-Blast [20] simplifies MBA expressions by exploiting the equivalence between 1-bit and n-bit MBA transformations. MBA-Flatten performs in-place MBA simplification by rewriting bitwise subexpressions into a unified form followed by arithmetic reduction. MBA-Solver [21] simplifies MBA expressions by reducing the mixing degree of bitwise and arithmetic operations for easier solving. Syntia [30] uses program synthesis to recover simplified semantics from obfuscated code, including MBA-obfuscated expressions. As these methods are all representative traditional MBA deobfuscation approaches and their functionality is already covered by the selected baseline GAMBAand ProMBA, they are not included separately in the final evaluation.

ModelObfuscator [14] obfuscates model structure, parameters, and attributes to protect deployed TFLite models on mobile devices, and DynaMO [16] extends this line of work with homomorphic encryption [31] against runtime instrumentation attacks. Since both are developed for on-device TFLite deployments rather than standalone executable binaries, we exclude them from the experimental baselines.

DnD [12] is a DNN decompiler that recovers high-level DNN semantics from compiled binaries through symbolic execution and loop analysis, and NeuroScope [13] is a dynamic-analysis-based framework for reversing DNN binaries on edge devices. Since BTDalready serves as a representative baseline for reversing DNN binaries as DnD, we omit DnDin the evaluation. In addition, the released artifacts of NeuroScopelack sufficient usage and configuration guidance, and its target programs depend on the Glow [9], whose official repository has been archived and is now read-only [32], indicating that it is no longer actively maintained. Therefore, we also exclude NeuroScopefrom the evaluation.

5.2 RQ1: Correctness↩︎

In this section, FLOBis evaluated to determine whether it preserves computation correctness without introducing additional numerical error. The correctness is first examined in transforming basic floating-point operations (§5.2.1), and further in preserving the functional correctness of full DNN models after obfuscation (§5.2.2).

In both cases, the three obfuscation parameters are varied over \([2,6]\), \([2, 6]\), \([0, 4]\) separately, which are centered around the default configuration \((N_t, N_o, N_a) = (4, 4, 2)\), yielding overall \(125\) obfuscation configurations. Then, under each configuration, the target is obfuscated and tested with \(100\) independently sampled inputs, resulting in \(12,500\) tests in total. For each test, the output of the obfuscated target is compared with that of the original one, and it is counted as correct only when the output difference is zero.

5.2.1 Floating-Point Operation Obfuscation↩︎

The results are shown in Figure 9 (a). Across all evaluated operations, a correctness rate of 100% is consistently achieved. This indicates that no additional numerical error is introduced by FLOBduring obfuscation. The reason is that the floating-point values in MBA expressions are represented with higher precision (§3.2.1), so that the transformations can be applied without perturbing the original semantics. Additionally, the results of multiplication and division further show that the operation reduction is also semantics-preserving (§3.1).

5.2.2 DNN Model Obfuscation↩︎

As presented in Figure 9 (b), FLOBachieves a correctness rate of 100% for all evaluated DNN models as well. In this experiment, correctness is determined by comparing the output vectors of the original and obfuscated binaries. Hence, every element in the output vector remains numerically identical after obfuscation, indicating that FLOBpreserves the end-to-end inference behavior of the original models without introducing additional numerical error. Together with the results of operation obfuscation, it is further demonstrated that the correctness of FLOBis maintained not only for individual floating-point operations but also for full DNN execution.

5.3 RQ2: Effectiveness↩︎

In this section, the effectiveness of FLOBis evaluated from the perspective of resistance to deobfuscation and reverse engineering. Since it provides protection at both the floating-point expression level and the DNN binary level, two types of analysis are considered:

5.3.1 MBA Deobfuscation↩︎

Existing MBA deobfuscation methods are primarily designed for integer expressions, such that they cannot be directly applied to analyze full DNN binaries obfuscated by FLOB. Therefore, in this section, the evaluation is performed at the expression level, by constructing a dedicated test set of obfuscated expressions extracted from the evaluated DNN models. Specifically, 200 target expressions are randomly sampled from the model set, as presented in Table ¿tbl:tab:dataset?. To ensure that the extracted expressions reflect the characteristics of real DNN computation, the sampling ratio is aligned with the proportion of integer and floating-point operations in the corresponding models. Each sampled expression is then obfuscated by FLOBand submitted to the evaluated MBA deobfuscation tools for analysis.

A deobfuscation attempt is regarded as successful only when the returned expression is semantically equivalent to the original one. Otherwise, it is counted as a failure, including not only incorrect simplification results, but also cases where no valid result is returned, such as crashes, runtime errors, or timeouts. For fairness, each deobfuscation task is assigned a timeout according to the default setting of the corresponding deobfuscator, namely 3,600 seconds for GAMBA [26], 4,000 seconds for ProMBA [22], and 60 seconds for XSmir [17]. The success rates of deobfuscation are shown in Figure 10, where round denotes the number of obfuscation iterations applied by FLOB, and the other axis represents the number of operations obfuscated in each round.

Overall, the deobfuscation success rates of all three tools decrease as the FLOBobfuscation becomes stronger, i.e., as more rounds are applied and more operations are obfuscated in each round. This trend is consistently observed for the three deobfuscators, indicating that FLOBeffectively increases the difficulty of automated MBA deobfuscation under progressively stronger protection settings. Even in the mildest configuration of FLOB, the success rates are only 64.7% for GAMBA, 57.1% for ProMBA, and 36.2% for XSmir, which are lower than the average accuracies reported in their original papers, namely 99.7%, 84.4%, and 76.3%, respectively.

The lower success rates of all three tools can be attributed to the difference between their original design scope and the scenarios considered in this paper. Existing MBA deobfuscators are primarily designed for integer-oriented expressions, whereas the expressions produced by FLOBare derived from real-world DNN models with floating-point computations. As a result, all three tools exhibit lower success rates when analyzing code obfuscated by FLOB. XSmirremains relatively stable across different FLOBconfigurations. This is consistent with its black-box design, which attempts to recover expressions from input-output behaviors rather than directly analyzing expression structures. Its performance is therefore less sensitive to changes in the obfuscation configuration of FLOB. Meanwhile, the expressions extracted from real-world models are complex and often involve large integers. This further increases the difficulty of synthesis-based recovery, thereby reducing the overall success rate of XSmir.

In contrast, GAMBAand ProMBAare white-box methods that directly analyze expressions. Their results therefore vary more clearly with different configurations of FLOB. Besides, ProMBAis more sensitive to analysis time, because solver-based reasoning is involved in its simplification process. When the target expressions become more complex, it often cannot complete the analysis within the given time, leading to a lower observed success rate. GAMBAis less affected by this issue and thus performs better under the same time budget. This observation is also consistent with the findings reported in the XSmirpaper [17]. ProMBAcan outperform GAMBAwhen sufficient time is available, whereas its advantage diminishes when the time budget is limited.

5.3.2 DNN Reverse Engineering↩︎

Figure 11 presents the function reconstruction rates of BTDon original and obfuscated DNN binaries. NeuroShieldand BTDare the state-of-the-art obfuscation scheme and reverse engineering technique for DNN binaries. Therefore, we follow the evaluation configuration of NeuroShieldand reuse its model set as well for the comparison. Specifically, the target models are obfuscated by FLOBand then analyzed by BTD, and the ratio of successfully reconstructed functions is measured as the metric. As a reference, Original shows the result on models without obfuscation, where BTDachieves a function reconstruction rate of 100.0%. The results of NeuroShield, Tigress, and Lokiare taken from the paper of NeuroShield [15]. In particular, the value reported for NeuroShieldcorresponds to the average reconstruction rate over both CV and NLP models. Under the same evaluation setting, FLOBreduces the function reconstruction rate to only 4.51%, which is substantially lower than those of other work.

These results indicate that FLOBprovides stronger protection against DNN binary reverse engineering than the compared obfuscation methods. Unlike existing methods that mainly obfuscate code structure or conventional integer-oriented logic, FLOBdirectly protects floating-point computations that are central to DNN execution. As a result, the operator semantics and function behaviors required by BTDfor reconstruction become much harder to recover.

5.4 RQ3: Performance and Overhead↩︎

In this section, the practical performance and overhead of FLOBare evaluated. The analysis covers both the processing time incurred during the obfuscation (§5.4.1) and the overhead introduced to the protected DNN binaries (§5.4.2).

5.4.1 Processing Time↩︎

The processing time of FLOBis shown in Figure 13. For each model, two settings are evaluated, namely obfuscating 10% of the floating-point operations and all operations. The dashed line simultaneously shows the number of floating-point operations in each model. Overall, the processing time increases with the number of floating-point operations to be protected. That is consistent with the design of FLOB, i.e., more obfuscation instances leading to more term generation and coefficient solving during the process.

Figure 12 further explains the major source of FLOB’s processing cost. In this experiment, ResNet18 is used as the target model, and the success rate of coefficient solving is evaluated under different FLOBparameter settings. Each solving attempt is given a timeout of 3,600 seconds, and timed-out cases are counted as failures. In practice, most of the time is spent in coefficient solving, because terms are generated via sampling (Algorithm 7). The sampled terms may not always yield a solvable coefficient system, and the generation-and-solving procedure must then be repeated until a valid solution is found (Algorithm 8). Therefore, the overall processing time is heavily influenced by the success rate of coefficient solving.

Across all 432 (\(=9\times 8\times 6\)) parameter settings, the general trend is that the solving success rate decreases as the obfuscation parameters increase, i.e., as the obfuscation becomes stronger, indicating that stronger settings generally make coefficient solving harder, which in turn increases the total processing time. Meanwhile, Figure 12 (a) shows a different trend, where the success rate reaches its peak when the number of terms is 4. This pattern arises because the success of coefficient solving is affected by two competing effects. When the number of terms is smaller than 4, increasing it provides more possible combinations among the generated terms, thereby increasing the chance of obtaining a solvable system. Once the number of terms exceeds 4, however, the coefficient system becomes progressively harder to solve, and the success rate correspondingly declines. The peak at 2 in Figure 12 (b) follows the same intuition, as a small increase in the number of operators per term initially enriches the space of candidate terms and improves solvability, whereas further increases make the generated expressions more complex and reduce the solving success rate.

Although the solving success rate affects processing efficiency to some extent, this cost is largely incurred only once in the current design of FLOB. Successfully solved MBA expressions are stored in an expression database for later reuse (as shown in Figure 4), which reduces repeated solving in subsequent obfuscation tasks and improves practical efficiency over time.

5.4.2 Obfuscation Overhead↩︎

The overhead introduced by FLOBis shown in Figure 14, including execution time, runtime memory usage, and executable binary size under the settings of obfuscating 10% of floating-point operations and all the operations, respectively. Overall, stronger obfuscation consistently leads to higher overhead.

Execution time is the dominant overhead introduced by FLOB, which is expected because its protection is achieved by deliberately complicating the original computation. Under 10% obfuscation, the execution-time overhead ranges from 2x to 62x, with an average of about 40x. Under complete obfuscation, the range further increases to 10x to 133x, with an average of about 62x. These results show a clear increase in runtime cost as more floating-point operations are protected. At the same time, this overhead remains competitive when compared with traditional MBA-based obfuscation methods. According to the NeuroShieldresults [15], Lokiincurs an execution-time overhead of up to 1700x on MNIST, while Tigressreaches 194x-258x on MNIST, ResNet, and MobileNet. By contrast, under complete obfuscation, the corresponding overhead of FLOBon these models stays within 97x-134x, suggesting that it remains more efficient than prior MBA-oriented obfuscation tools in terms of execution-time overhead, while still providing strong protection.

In addition, runtime memory overhead and binary size overhead remain comparatively moderate. Across the evaluated models, the increase in runtime memory usage is generally small, while the binary-size overhead also stays within a limited range. MobileNet is observed to exhibit larger memory and binary-size overhead than most other models. This may be related to its comparatively fine-grained and deeper model structure, which can produce more distributed obfuscation targets in the compiled binary, thereby introducing more transformed code and auxiliary data after obfuscation.

6 Discussion and Future Work↩︎

6.1 General-Purpose Implementation↩︎

The current prototype of FLOBis implemented on top of TVM [5], but the design itself is not tied to TVM. In particular, TVM is used to obtain the LLVM IR of target models. The core design of FLOB, however, is platform-independent. It operates on floating-point computations at the IR level and is not tied to a specific front-end framework or compiler stack. Therefore, it is applicable to other compiler toolchains that expose comparable IR representations.

6.2 Comparison with Related Work↩︎

ModelObfuscator [14] is similar to NeuroShield, as protection is largely achieved by complicating code structure and integer-oriented computation. Since FLOBalready shows stronger resistance to reverse engineering than NeuroShield (§5.3.2), it can be inferred that FLOBis unlikely to be weaker than ModelObfuscatorin this aspect. DynaMO [16] is not naturally applicable to all nonlinear operations. By contrast, FLOBdirectly protects floating-point computation at the IR level, giving it a broader applicability across operator types and deployment scenarios. NeuroScope [13] relies on precise identification of memory regions and access patterns to recover information from DNN binaries, whereas the increased complexity of memory accesses introduced by FLOBwould make such analysis less effective.

6.3 Efficiency and Optimization↩︎

The evaluation shows that FLOBincurs noticeable runtime overhead, which is expected because protection is achieved by transforming original floating-point computations into more complex obfuscated forms. Improving efficiency is therefore an important direction for future work. One possibility is to reduce the precision used in the lifted integer representation. While the current design reserves sufficient precision to avoid additional numerical error, DNN inference often tolerates limited numerical inaccuracy without affecting final prediction behavior, suggesting room for a more efficient accuracy-efficiency trade-off. Another direction is to develop obfuscation methods for floating-point vector operations directly. The current reduction of multiplication and division partially disrupts the original parallelism of vectorized computation, and a vector-aware design may reduce this cost.

6.4 Quantification of Obfuscation↩︎

Conventionally, it is an open problem to quantify the strength of software obfuscation, because protection usually targets control flow and data flow, whose resistance is hard to measure precisely. In contrast, FLOBtargets floating-point operations through MBA-based transformations, which may enable a more structured notion of protection strength, for example in terms of added computation or transformed instructions. The definition of such metrics and their connection to practical resistance against automated analysis remain unclear, and are left for future work.

7 Related Work↩︎

Code Obfuscation. Software obfuscation techniques aim to protect software intellectual property and hinder reverse engineering by transforming program code while preserving its functionality. General obfuscation schemes include opaque predicates [33], control flow flattening (CFF) [34], virtualization (VM) [35], [36], and Mixed Boolean-Arithmetic (MBA) [19]. While frameworks like Loki [27] leverage these techniques for general software protection—and others, such as Obelix [37], utilize hardware-based trusted execution environments—these approaches often fall short when applied to Deep Neural Network (DNN) binaries. Opaque predicates and control flow flattening are less effective for DNN binaries as they have simple control flow and are dominated by linear algebra computations. Virtualization-based obfuscation can introduce significant overhead for DNN inference, while MBA-based obfuscation can be easily simplified by existing deobfuscation techniques, such as MBA-Blast [20].

Code Deobfuscation. Recent deobfuscation efforts tackle complex software protections through structural and binary restoration. For instance, DeFFai [38] mitigates Control Flow Flattening (CFF) via Abstract Interpretation, while QSynth [39] combines Dynamic Symbolic Execution (DSE) and program synthesis to recover binary semantics. However, MBA obfuscation remains a primary bottleneck. To overcome the high performance overhead of early bit-blasting tools like MBA-Blast [20], advanced white-box solutions have emerged: SiMBA [40] and GaMBA [26] employ algebraic rewriting to simplify MBAs without complete bit-level decomposition, while ProMBA [22] integrates program synthesis with term rewriting. Additionally, MBA-Solver [21] utilizes truth-table-derived signature vectors to safely reduce bitwise-arithmetic mixing. To overcome the exponential memory scaling issues of such table-based methods on multi-variable expressions, MBA-Flatten [41] introduces an in-place transformation that directly unifies bitwise operations into an arithmetic form without requiring precomputed tables. To bypass the syntactic limitations of these white-box methods, novel paradigms have shifted towards black-box and AI-driven approaches. XSmir [17] utilizes I/O-guided program synthesis with local inference rules to simplify custom MBAs, while NeuReduce [29] frames MBA simplification as a data-driven "machine translation" task using a Seq2Seq model, drastically accelerating deobfuscation over traditional symbolic solvers.

DNN Protection. DNN protection has attracted significant attention as models are increasingly deployed in untrusted environments. Prior work can be broadly categorized into three directions:

These efforts collectively highlight the trade-offs between security guarantees, computational overhead, and model utility in safeguarding DNN assets.

DNN Binary Reverse Engineering. Reverse engineering threats against deployed DNNs have rapidly escalated from software decompilation to physical hardware exploitation. At the software level, tools like BTD [11] and DnD [12] rely on static or dynamic analysis to decompile x86 and cross-architecture DNN binaries, recovering high-level model semantics. To bypass the heavy overhead of static analysis on IoT edge devices, NeuroScope [13] leverages dynamic memory tracing for efficient model extraction. Beyond software, system-level and physical attacks present severe risks: the Hermes Attack [53] achieves lossless extraction by intercepting unencrypted PCIe traffic, while power side-channel analysis [54] can reverse-engineer even closed-source, encrypted hardware accelerators (e.g., FPGAs) and their executing parameters. Together, these vectors thoroughly compromise model confidentiality and intellectual property.

8 Conclusion↩︎

We propose FLOB, a DNN obfuscation framework that protects floating-point computations in deployed binaries. By lifting floating-point values into a higher-precision representation domain, it enables MBA-based obfuscation while preserving the original computation semantics. It further supports multiplication and division through operation reduction, allowing a wider range of floating-point operations to be protected. The evaluation shows that FLOBpreserves exact correctness without introducing additional numerical error, while effectively reducing the success of existing MBA deobfuscation and DNN reverse-engineering methods. In addition, it achieves a practical trade-off between protection strength and efficiency, with lower execution-time overhead than existing MBA-based obfuscation methods.

References↩︎

---

1. FLOB: FLoating-point computation OBfuscator↩︎