Cryptanalytic NN extraction without a known architecture (arXiv 2609.14379)

What happened on this date

On 2026-09-13 (UTC), Yantian Shen, Yi Chen, Anyu Wang, Hongbo Yu and Xiaoyun Wang submitted v1 of this paper to arXiv (v2 followed on 2026-09-19). Cryptanalytic model extraction aims to rebuild a functionally equivalent copy of a victim model through black-box queries, and earlier attacks typically assumed the architecture was known and recovered only parameters. For ReLU fully connected networks, the paper proposes a guess-and-determine framework that recovers both architecture, meaning depth and hidden-layer dimensions, and parameters. The authors identify two architecture-dependent artifacts in differential extraction: a run of zeros at the end of merged weight vectors from signature recovery, whose length indicates a hidden layer's dimension, and an equality pattern in preimage-based sign recovery that appears only at the true dimension. They also give methods for identifying the second-to-last layer and its dimension, and demonstrate end-to-end attacks on expansive and non-expansive ReLU networks, claiming the first such practical demonstration on deep networks.

Why it matters for protecting app logic

More apps treat models as core assets, either shipped on-device in the package or served through an inference API. A common intuition is that exposing only queries while hiding the architecture is enough to protect a model. This paper targets exactly that intuition: within its scope, hiding the architecture is no longer a necessary barrier. The boundary must be stated precisely: the paper studies ReLU fully connected networks, we draw no conclusions about other model types, and the abstract gives no cost figures such as query counts. For model files shipped inside an app the issue is more direct: they already sit on the other party's device and should be treated as obtainable, so protection should focus on the data, workflows and server capabilities around the model.

Checks you can run

First, inventory every model in your app: which ship in the package, which are served through an API, and how much business value each carries. Second, plan for packaged models to be obtainable, and keep high-value models or their key parts on the server. Third, review how much information your inference API returns, for example whether it needs to return full numeric outputs or could return only what the product needs. Fourth, configure rate limits and anomalous-query monitoring on inference endpoints, and prohibit model extraction explicitly in your terms of service.

Your checklist

• Inventory packaged and API-served models and their value
• Treat packaged models as obtainable; keep high-value parts server-side
• Review inference API output detail and add rate limits