Reproducible Builds Instructions 😊

[xrviv]

Heya team OneKeyHQ 😊,

Danny here from @WalletScrutiny,

We'd love for the One Key Pro to be tested for reproducible build verification. In this light, may we request for build instructions re: One Key pro?

Sincerely,

Danny

[PatrickChoo]

Thank you for your interest in testing OneKey Pro for reproducible build verification. We would be happy to assist you with this. Please send us an email at hi@onekey.so with your mailing address, and we will arrange for the shipment.

Looking forward to your email. 🙌

[xrviv]

Oh, no, thank you! You are most kind, but we are not asking for a device :)

Although, I am thinking of buying one for myself soon!

But as you can see from our Gitlab , we just need assistance with the script as other versions of the one Key are proven to be reproducible.

The instructions would be sufficient since this is Open Source.

Instructions like:

• bitkey: https://github.com/proto-at-block/bitkey/blob/main/app/verifiable-build/android/README.md
• seedsigner: https://github.com/SeedSigner/seedsigner-os/blob/main/docs/building.md
• foundation devices passportb2: https://github.com/Foundation-Devices/passport2/blob/main/REPRODUCIBILITY.md

That would be really helpful! Thanks

[424778940z]

Building the firmware is very straightforward:

1. install dependencies
2. enable nix environment
3. initialize poetry environment
4. run build commands under poetry
5. check artifacts under core/build/{target} folder

For details of each step, I would suggest take a look at the Github CI task file which is here -> https://github.com/OneKeyHQ/firmware-pro/blob/main/.github/workflows/build-pro.yml

The easiest way will be just fork this repo on Github, then run CI jobs from your own fork. This should be sufficient to prove our release binaries are from our opensource code. Adapt the whole build environment/config/process to Gitlab should be possible, but I could not see the point if the goal is to verify binaries are reproducible.

[keraliss]

Hey guys, keraliss from walletscrutiny here. Thanks for the build instructions! We've created a simple verification script following your guidance and tested the reproducibility of the OneKey Pro firmware.

Here's the script we used:

#!/bin/bash
# Verification script for OneKey Pro firmware
set -e

# Create temp directory
TEMP_DIR="/tmp/onekey-basic"
rm -rf "${TEMP_DIR}"
mkdir -p "${TEMP_DIR}"
cd "${TEMP_DIR}"

# Clone and build
echo "Building firmware..."
git clone --depth 1 https://github.com/OneKeyHQ/firmware-pro.git
cd firmware-pro
git submodule update --init --recursive

# Build the firmware
chmod +x build-docker.sh
./build-docker.sh -f touch || true

# Find built firmware
BUILT_FIRMWARE=$(find . -name "firmware.bin" | grep "touch/firmware" | head -1)
if [ -z "${BUILT_FIRMWARE}" ]; then
  echo "Error: Could not find built firmware"
  exit 1
fi

# Download official firmware 
echo "Downloading firmware..."
wget -O downloaded.bin "https://github.com/OneKeyHQ/firmware-pro/releases/download/v4.12.0/pro.4.12.0-Stable-0225-5379167_thd89_app_PROD_20250221_1.1.5_dfc6ccf_0x10.signed.bin"

# Calculate checksums
echo "Calculating checksums..."
echo "RESULTS=========================================="
echo "Built firmware hash:"
sha256sum "${BUILT_FIRMWARE}"
echo "Downloaded firmware hash:"
sha256sum downloaded.bin
echo "================================================="

Our verification results show that the built firmware hash differs from the downloaded firmware:

Calculating checksums...
RESULTS==========================================
Built firmware hash:
2b8ce9dab486877b78ecfd9b7b5d0579e313197cb92e98f9bec20805072b7cdb  ./build/touch/firmware/firmware.bin
Downloaded firmware hash:
372fdf71a642e1797118fbd04a8df1b8f90c44cb8988f17c1e1ab85e6f0437cc  downloaded.bin
=================================================

We also analyzed the hexdump differences and found significant structural differences in the header and throughout the binary. The build logs show the firmware is built with a test vendor header (ONEKEY,FOR TEST ONLY) and has invalid signatures.

Based on these results, we've marked OneKey Pro as not-verifiable in our current review.

Are there any additional steps or specific build parameters we should use to get a build that would match the released firmware? In particular, we're interested in whether there's a way to reproduce the exact binary, or if certain signature areas need to be zeroed out to achieve a match?

waiting to hear from you!

[424778940z]

Based on these results, we've marked OneKey Pro as not-verifiable in our current review.

Multiple people from walletscrutiny are openning issue in our repos regarding this topic, but none of you guys actually read our dedicate knowledge base article for how to verify the hash, then base on incorrect metholdgy mark our device "not-verifiable", this is not appreciable.

As commn practice for firmware update, our firmware has headers, and our release blob may contain multiple firmware images, hash the whong thing won't give any meaningful result.

No mean to be rude, but if walletscrutiny's goal is to provide trustworthy opensource auditing for hardware wallets, I would suggest at least hire some people knows how to read documents and do things the right way instead of try blindly brute force through it.

[PatrickChoo]

We believe that the current classification of OneKey as “Unreproducible” on the WalletScrutiny website is unwarranted. Honestly, this misleading assessment has already affected our reputation.

May we kindly request your Telegram handle via hi@onekey.so (email us with the walletscrutiny.com mailbox)? We’ll promptly create a group to discuss reproducible builds, and we’re ready to assist in resolving any difficulties regarding the reproducibility of OneKey.

Thank you in advance, and we look forward to hearing from you soon. 🙏

[keraliss]

Hi OneKey team,

Thanks for your response. I might be misunderstanding something, and @xrviv and giszmo are way more knowledged in this, but in my eyes, I see some concerns with your verification approach that don't quite align with what WalletScrutiny considers "reproducible":

If I'm understanding correctly, your verification method requires already owning a OneKey device. This would make it difficult for potential buyers or a third-party reviewer like me to verify your firmware independently before purchasing the device.

The approach also seems to ask users to install the firmware first, then check if it's legitimate. I could be wrong, but this seems to reverse of what we're trying to achieve - verifying firmware before installing it.

From WalletScrutiny's perspective (and I'm open to being corrected here), reproducibility means: Can an independent party take your source code, follow your build instructions, and produce the same binary you distribute? This approach has become standard for many security-critical projects.

When we mark something as "not-verifiable," it doesn't mean your product is bad or malicious - just that the build process doesn't meet this particular standard. Many hardware wallets face similar challenges with signed firmware.

If you'd like to improve the reproducibility rating, we'd need either:
Find a way to build the exact same binary from source, or
A documented process to zero out signature/vendor sections for meaningful comparison

I appreciate your offer to discuss further. I would prefer to keep conversation in this public issue as it might help others who have similar questions, but I'm open to your thoughts on this.

[PatrickChoo]

If I'm understanding correctly, your verification method requires already owning a OneKey device. This would make it difficult for potential buyers or a third-party reviewer like me to verify your firmware independently before purchasing the device.

Thank you for your response.

We kindly ask the WalletScrutiny development team to read this documentation first. It clearly and fully explains how to verify the firmware (and of course doesn’t require installing it beforehand).

Let’s please avoid unnecessary confusion. 🫡

https://help.onekey.so/hc/articles/9695887559823

[424778940z]

If I'm understanding correctly, your verification method requires already owning a OneKey device. This would make it difficult for potential buyers or a third-party reviewer like me to verify your firmware independently before purchasing the device.

This is incorrect, our article provide two methods:

1. How to check currently installed firmware hash on device
2. How to check of a binary file from release or CI

The article suggests checking between installed firmware and a binary file, but there is nothing stopping you from use method 2 to compare two binary file. I can't see how this becomes owning a device is REQUIRED.

If you'd like to improve the reproducibility rating, we'd need either:
Find a way to build the exact same binary from source, or
A documented process to zero out signature/vendor sections for meaningful comparison

First, as stated above long ago, fork this repo, run Github Action, you get the build
Second, as stated above also, our article ALREADY provided a way to skip the header to hash firmware code

I appreciate your offer to discuss further. I would prefer to keep conversation in this public issue as it might help others who have similar questions, but I'm open to your thoughts on this.

We offering telegram as a way of quick response to provide help, not to get the conversation to private, if you don't like it, that's fine.
But still, if WalletScrutiny's goal is to provide trustworthy opensource auditing for hardware wallets, I would suggest learn the skill and knowledge required.

Also, it is important to understand manufacturers have their own preference for design choice, and reduce complexity of the reproducible verification process is important, but likely won't be first/top priority. And we already did what we could, but that won't help people who don't read and think.

[revan-zhang]

Thank you for raising concerns regarding the reproducibility of our OneKey Pro firmware.
To clarify, we have published a complete and verifiable guide demonstrating how to perform a reproducible build from source. This includes:

• Using a clean Ubuntu 24.04 environment (e.g., AWS EC2 instance)
• Installing fixed dependencies via Nix (v2.23.3)
• Building from a tagged release (v4.14.0)
• Extracting and verifying the unsigned firmware binary
• Comparing SHA-256 hashes of the build output and official release (after removing signature headers)

We’ve made this process publicly available here:

• #786

The result: the reproducibly built firmware matches bit-for-bit with the released version (excluding cryptographic signatures), proving the integrity and auditability of our release pipeline.

If there's anything unclear in the process or you'd like to replicate it yourself, feel free to reach out — we’re happy to collaborate to ensure transparency and security in open hardware.