How Attackers Can Steal AI Models from NVIDIA Jetson Devices?

07 Jul 2026 By Marwane El Hani
technical

Introduction

In this article, we are going to show you how we managed to extract an encrypted model from an inference pipeline on TensorRT on a NVIDIA Jetson Orin.

TensorRT and NVIDIA Jetson Orin

Running AI models requires significant computing power, which is often difficult to achieve on embedded devices. That is why specialized boards such as NVIDIA’s Jetson Orin are used, in conjunction with their dedicated inference engine: TensorRT. TensorRT takes a source representation of a model (in our example, ONNX) and compiles the model (into a binary engine file) to optimize inference time and memory consumption, at the cost of a partial loss of information about the model’s structure.

compilation example

Figure 1: TensorRT Processing Pipeline.

The Attack Scenario

To put ourselves in the attacker’s shoes, here are the initial assumptions:

  • The attacker can execute the compiled inference code (i.e., run an inference)
  • The attacker does not have access to the compilation pipeline or the original ONNX model

compilation example

Figure 2: Attack context.

Demonstration

For this demonstration, we will play the roles of both the attacker and the victim. We therefore need to set up a victim model; we will use a resnet50 torchvision model. Now, it’s very important to understand that we’re not going to break any encryption algorithm; we’re going to exploit the fact that TensorRT cannot natively support encryption and, therefore, the model is inevitably decrypted in the inference environment, before being forwarded to TensorRT. No matter how this encryption was implemented, once an inference is launched, the engine (and therefore the model) is loaded in plaintext. It is precisely this window of opportunity that we’re going to try to exploit.

compilation example

Figure 3: TensorRT Runtime Execution.

Hooking with LD_PRELOAD

LD_PRELOAD is a standard Linux environment variable that allows us to force the operating system to load a custom shared library before any others. This provides a simple yet powerful mechanism to intercept and modify function calls made by an application.

Since TensorRT must deserialize the model in memory before passing it to the GPU, we can use LD_PRELOAD to “hook” or hijack the specific API function responsible for this step (such as deserializeCudaEngine).

Because we are exploiting the memory state rather than the file state, the process is straightforward:

  • Interception: We create a small, custom shared library containing a function with the exact same name and signature as the targeted TensorRT deserialization function.

  • Extraction: When the victim application initiates inference, LD_PRELOAD tricks it into routing the plaintext model data through our custom function first. We simply copy this decrypted engine file.

  • Resumption: To ensure the application does not crash and raise suspicion, our script silently forwards the execution back to the original, legitimate TensorRT function.

The victim’s inference runs perfectly normally, completely unaware that a memory attack just occurred. By targeting the window where the model must exist in plaintext RAM.

compilation example

Figure 4: Hooking schema.

Are you vulnerable?

If you are using encryption to protect your on-device or on-premise AI model you are.

In this article, we demonstrate that encryption by itself is not sufficient to protect AI models. An attacker with a physical access to the device can bypass this protection with only a few lines of code, making model extraction scalable. Although our demonstration targets TensorRT, the same attack principle applies to many other AI deployment frameworks, including OpenVINO and ONNX Runtime.

The AI protection of Skyld bridge this gap, protecting the parameters of your AI model (weights) against extraction before and during the model execution, using mathematical transformations to keep the model weights confidential.

Share on: