keepkey / keepkey-firmware Goto Github PK

View Code? Open in Web Editor NEW

149.0 149.0 103.0 39.54 MB

KeepKey Device Firmware

License: GNU Lesser General Public License v3.0

C 91.61% C++ 4.54% Shell 0.42% Assembly 1.37% GDB 0.01% Pawn 0.03% CMake 1.84% Dockerfile 0.12% Python 0.05%

keepkey-firmware's People

Contributors

Stargazers

Watchers

Forkers

aussiehash btchip talkvip arachnid ifengchao dashpay chaeplin pkhx02 seciot munoz9255 fumecow afg419 ben8288 craig-iam-smith scpham argentumproject bertrand256 martin-key machinecoin-project mcmocoder darkjon errory zhenhanyijiu gowabby turboboost55 limxtec fundacionpesetacoin electracoin-eca maxmelorj touchjet douglaslins1606 anappau fujicoin buzzkillb dalijolijo metaspartan jenova7 groestlcoin langelog linberduan gladcow bithighlander thesin- golden-finger abovyanv adsorptionenthalpy qtumproject ammogcoder nedos hatchpay kerbyrok pinklite34 sidhujag hal0x2328 flurbos zacht1711 saagarjha hollander172 chipo-project sterl ligi amusedbnet omotenashicoin-project manuelsanpedro metaver5o rizal-shahirul nessa-g22 volokitinss aaronwashington ollitsac107 rakhithjk dumie505 linuxvom fds-lab start9labs greatwolf othello1111 markrypt0 smartfridgeiot noealvyss snakies tleong073 cl4sm banging12 baby636 william3johnson inferno-inc kast1450 arosboro mikebobio gima-maya mrnerdhair

keepkey-firmware's Issues

SSH Support Broken

SSH support on the KeepKey was fixed in firmware 5.4.1 (I've been on the rc version), but now on the latest (5.6.1) and the new bootloader, SSH is no longer working.

In Linux, I am seeing the following with keepkey-agent:

Traceback (most recent call last):
  File "/home/nticompass/.local/lib64/python3.5/site-packages/libagent/device/trezor.py", line 151, in sign
    ecdsa_curve_name=curve_name)
  File "/home/nticompass/.local/lib64/python3.5/site-packages/keepkeylib/client.py", line 135, in wrapped_f
    ret = f(*args, **kwargs)
  File "/home/nticompass/.local/lib64/python3.5/site-packages/keepkeylib/client.py", line 690, in sign_identity
    return self.call(proto.SignIdentity(identity=identity, challenge_hidden=challenge_hidden, challenge_visual=challenge_visual, ecdsa_curve_name=ecdsa_curve_name))
  File "/home/nticompass/.local/lib64/python3.5/site-packages/keepkeylib/client.py", line 148, in wrapped_f
    return f(*args, **kwargs)
  File "/home/nticompass/.local/lib64/python3.5/site-packages/keepkeylib/client.py", line 189, in call
    msg = handler(resp)
  File "/home/nticompass/.local/lib64/python3.5/site-packages/keepkeylib/client.py", line 201, in callback_Failure
    raise CallException(msg.code, msg.message)
keepkeylib.client.CallException: (1, 'Unknown message')

In Windows, under TrezorSSHAgent.exe:

[18.07.2018 23:00:59] SEVERE: Sign operation failed
com.trezoragent.exception.SignFailedException: Sign operation failed on HW.
	at com.trezoragent.sshagent.DeviceWrapper.signChallenge(DeviceWrapper.java:123)
	at com.trezoragent.sshagent.SSHAgent.processSignRequest(SSHAgent.java:253)
	at com.trezoragent.sshagent.SSHAgent.answerMessage(SSHAgent.java:170)
	at com.trezoragent.sshagent.SSHAgent.answerIfDevicePresent(SSHAgent.java:224)
	at com.trezoragent.sshagent.SSHAgent.processMessage(SSHAgent.java:149)
	at com.trezoragent.sshagent.SSHAgent.callback(SSHAgent.java:111)
	at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at com.sun.jna.CallbackReference$DefaultCallbackProxy.invokeCallback(CallbackReference.java:485)
	at com.sun.jna.CallbackReference$DefaultCallbackProxy.callback(CallbackReference.java:515)
	at com.sun.jna.Native.invokeInt(Native Method)
	at com.sun.jna.Function.invoke(Function.java:390)
	at com.sun.jna.Function.invoke(Function.java:323)
	at com.sun.jna.Library$Handler.invoke(Library.java:236)
	at com.sun.proxy.$Proxy0.GetMessage(Unknown Source)
	at com.trezoragent.sshagent.SSHAgent.startMainLoop(SSHAgent.java:96)
	at com.trezoragent.gui.TrayProcess.start(TrayProcess.java:96)
	at com.trezoragent.gui.StartAgentGUI.main(StartAgentGUI.java:50)

Stuck on "Preparing for upgrade"

I used keepkeyctl firmware_update to install blupdater.bin from https://github.com/keepkey/keepkey-firmware/releases/download/v6.3.0/binaries.tar.bz2 after reading #165 (comment). The device now says Firmware Update Mode, Bootloader Version: 2.0.0, and the serial number. Now when I try to update the firmware to firmware.keepkey.bin from v6.3.0, after confirming on the device, it shows Preparing for upgrade and an empty progress bar. How long is it supposed to take? Should I try wipeDevice? Keepkey Client Chrome Extension does not recognize the device.

$ go-keepkey getFeatures
Connected to 1 devices
  --
{
        "vendor": "keepkey.com",
        "major_version": 2,
        "minor_version": 0,
        "patch_version": 0,
        "bootloader_mode": true,
        "bootloader_hash": "dA9tSFC+jlVSbKvR7dYeg11FPkS/cjnxHd938oFrMTU=",
        "policies": [
                {
                        "policy_name": "bl_debug_link",
                        "enabled": false
                }
        ],
        "model": "K1-14AM",
        "firmware_hash": "im3CNoWv933AE45UGC9uXIAC0wjfqGsA6iLuFncMm/g="
}
BootloaderHash: 740f6d4850be8e55526cabd1edd61e835d453e44bf7239f11ddf77f2816b3135

ROM size: misc gcc flags

Some misc gcc flags that save around 2k:

diff --git a/cmake/caches/device.cmake b/cmake/caches/device.cmake
index 436a23bc..9f4014b5 100644
--- a/cmake/caches/device.cmake
+++ b/cmake/caches/device.cmake
@@ -22,7 +22,13 @@ set(ARCH_FLAGS
     -msoft-float \
     -ffunction-sections \
     -fdata-sections \
-    -fno-common \
+    -fno-exceptions \
+    -fno-unwind-tables \
+    -fno-math-errno \
+    -fcommon \
+    -fno-zero-initialized-in-bss \
+    -fmerge-constants \
+    -fmerge-all-constants \
     -fstack-protector-all" CACHE STRING "")
 
 set(WARN_FLAGS

TODO: check validity on each of these. -fno-zero-initialized-in-bss could, for example, change behavior if assumptions are violated.

Custom firmware

Is it possible to install custom firmware on a real device with current bootlader?
According to https://www.reddit.com/r/keepkey/comments/99k2x1/when_will_custom_firmware_be_resupported/ it was disabled some time ago. Was it fixed since then?

electron.js app?

When will you offer a electron.js app(Mac OS,Windows & Linux) now when Chrome will restrict their app section to chromebooks only?

Support BSV's extended PAYTOOPRETURN

Your support for this is based on the reduced functionality version in BTC.

In BSV, the canonical form is now OP_FALSE OP_RETURN , and the size of the data is unrestricted, not 80 bytes, so can be pushed with OP_PUSHDATA1, 2 or 4.

Cannot sent to P2SH address (bitcoin)

Recent firmware seems unable to send to a 3-starting P2SH address. The transaction signing fails with "failed to compile output". 1-addresses work fine.

I am using Electrum, but the same thing works fine with Trezor.

Keepkey wallet (not dependent on chrome)

when will you create a desktop app for the keepkey wallet(not dependent of chrome due to chrome apps only being restricted to chromebooks)?

KeepKey stuck on loading accounts and balances

I recently had my broken harddrive in a laptop replaced. I did not notice that the system time had not been set correctly, and I setup a new ETH wallet and received some 22 ETH into it. After checking that it had made it to the wallet, I realised my system time was incorrect so I changed it to automatically adjust the date and time.

Now my KeepKey client will not make it past the "loading accounts" screen after inputting my PIN. have i lost any ETH and what can I do to re-gain access to my wallets?

ROM size: drop KeepKey Client style ERC20 tx support

... and move to only using the data field, instead of supporting both methods.

Saves 1k, and reduces firmware complexity.

Feature request (Testnet support LTC,ETH,BCH)

If possible, please look into adding support for

Litecoin Testnet
Ethereum Testnet
BitcoinCash Testnet

I Could not find a definition for them here:
https://github.com/keepkey/keepkey-firmware/blob/0806bb7eb29df19801e116c964c54a86a0ddd911/include/keepkey/firmware/coins.def

U2F webauthn acts flakey in chrome.

I've reported this issue to the Chromium devs which you can find here: https://bugs.chromium.org/p/chromium/issues/detail?id=942454

Basically the issue is that for some sites that implement U2F it doesn't quite work for Keepkey. The device sees the registration/token request but after pressing the Keepkey button, Chrome does not detect this. What's strange is that if you press it the moment the request shows up on Keepkey then it works. If you delay the press(eg. 1-2+ seconds later) then it doesn't work at all.

This was tested with firmware 6.0.4 alpha and on Win7 64-bit with latest version of Chrome(72.0.3626.121). Also tested this on Linux Mint same Chrome version with same result.

.text section overflows rom region

I've been trying to build the firmware and I've been unable to successfully build a firmware that fits on my device. Building a release firmware gives me an error during the linking step both in the Docker image (with some munging to use the correct set of tools) and on my Mac with a manually-downloaded set of dependencies:

/opt/local/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: ../../bin/firmware.keepkey.elf section `.text' will not fit in region `rom'
/opt/local/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: region `rom' overflowed by 66760 bytes
collect2: error: ld returned 1 exit status
make[2]: *** [bin/firmware.keepkey.elf] Error 1
make[1]: *** [tools/firmware/CMakeFiles/firmware.keepkey.elf.dir/all] Error 2
make: *** [all] Error 2

A non-release build succeeds but does not install because it's "too large". Any ideas as to why this might be happening?

adding segwit(Litecoin) to your wallets?

When will you add Segwit on Litecoin to your wallets now when it´s activated?

SPIKE: support for more generalized input/output scripts

Undefined Behavior in reset.c

page_count is uninitialized when used here.

keepkey-firmware/keepkey/local/baremetal/reset.c

Line 141 in 0b33185

page_count++;

Ethereum Support

Now that trezor is planning to add ethereum support is there any plans for keepkey to add it also?

Since keepkey uses a fork of the firmware it should be relatively easy.

trezor/trezor-common#11

More Coins?

will you add more coins(Digibyte, viacoin, vertcoin,stellar,ripple, NEO)?

what if the UPDATE wipes out my KEEPKEY?

How do I recover if the UPDATE wipes out my keepkey? Do I have the option of not updating? Thanks ,Haik

unable to verify signature on keepkey binary tarballs

The binary tarballs appear to be signed with a key not available on public keyservers. Are the public signing keys published somewhere else?

$ gpg --verify binaries.tar.bz2.sig
gpg: assuming signed data in 'binaries.tar.bz2'
gpg: Signature made Tue 22 May 2018 04:38:13 PM UTC
gpg: using RSA key B4BE6B5BA471354E5D71AC5A1A60E4FE407D43EF
gpg: Can't check signature: No public key

$ gpg --recv-key B4BE6B5BA471354E5D71AC5A1A60E4FE407D43EF
gpg: keyserver receive failed: No data

Merklize the TokenType table, and store off-device

The table of ETH tokens is growing quite dramatically. As a space-saving measure, we need to merklize it so we can store it off-device.

To do this, let's add a protobuf version of TokenType, and construct the table as a merkle tree. We massive space savings, since we'll only need to store a single hash in the firmware. Clients will then have to construct a TokenTypeAck merkle proof in response to a TokenTypeRequest from the device. As an added bonus, we could also support ShapeShift-signed, or even self-signed table entries, allowing for the addition of unlimited tokens at the user's leisure.

One big drawback from this strategy is that clients will need different merkle trees each time we add/remove/change something in the table.

Feature request: configurable discovery gap for small businesses.

I am a consultant for a number of businesses which accept payment, and make payments in crypto.

Right now, there is no HW wallet usable for business. The first HW wallet which supports this will get the whole market. To make your wallet ideal for business is about 1 man day development work.

As a cryptocurrency developer, i am fully aware of the architecture, features and limitations of deterministic wallets. On the plus side, you can generate, regenerate and recover any number of (indexed) addresses for any number of paths. However, in practice, HW wallet developers have crippled this functionality by implementing a fixed discovery gap of 1, rendering HW wallets useless for anyone other than a single person with a single wallet (for each Token)

Small Businesses, sole traders and consultants with multiple customers have the following requirements:

They need to assign an account (or at least an address) for each customer so that payments can be made in parallel. Having one account for multiple customers to pay into violates requirements for customer fund segregation, accounting and audit.
They can't wait for customer A to pay his bill before they create an account/address for customer B.
They need to generate many accounts/addresses up front (e.g. 10 or 100 at a time).
Ideally, they need to have an API to generate these addresses and accounts.
Recovery (e.g. using same seed on a different HW dongle if first fails) does not need to be fully automated. E.g. it's perfectly acceptable to set the discovery gap limit if its not stored anywhere.
It doesn't matter if this device is a bit slow as it has to load 100 accounts. They can live with that, but it should also be very easy to optimise this (e.g. local cache of accounts with a transaction + async loading)
it must be possible to select an individual address to pay out (not from an "account" or "wallet" which selects the address for you. This is where the otherwise excellent Trezor fails.

Each business is currently using either Trezor or Ledger HW dongles, neither of which support multiple accounts. Ledger is the most limiting. Here is what two companies I consult for do:

Every day, they pay someone to do the following:
For each currency (they support 20+)

Check how many free (unassigned to a customer) addresses they have.
If < 5, they create a new address.
Then they transfer 0.00000001 into it (or equivalent)
They wait 1 hour for the transaction to complete.
They transfer the 0.00000001 out.
Now they are "allowed" to create a new address in the wallet SW.

I.e. they employ someone just to fund and create new addresses. When I showed this company a command line call to generate 100 addresses via the trezor api, they were blown away. They had no idea that a wallet could generate multiple addresses without putting the equivalent of 1p into them manually first. Unfortunately, even though the trezor can generate unlimited addresses, it still wont "recognise" them unless you fund them.

I am currently advising my clients to use the Electrum wallet + trezor where possible, as with the Electrum wallet you can set the discovery gap limit e.g to 20, and thus create 20 address in seconds (which again blew away these companies). However this only works for a limited set of tokens.

There are many simple to implement and easy for customers to use ways to handle the discovery gap, e.g:

Make the discovery gap limit configurable like in Electrum. This is easy to use, easy to setup, easy to recover.
Store the discovery gap limit on a shared drive (like Trezor does for the account names).
store the highest index+ paths on a shared drive (like Trezor does for the account names)
Allow manually setting the highest index for easy recovery.
Allow import/ export of paths/indexes for easy recovery.
Simply allow addresses from any paths/indexes to be added manually. Ideally allow export of list of addresses (and names if supported), their paths and indexes to spreadsheet.

I believe that the crippling limitations of the current HW wallet offerings are due to lack of innovation and understanding of basic accounting. Quoting BIPxxx as a justification for the limitations is just lazy and dangerous as the first HW wallet which unleashes the full power of deterministic wallets will capture this market (if it can also support a wide enough range of coin). Recovery happens once a year, but accounts are created every day. To make the one you need to do every day impossible in order to make the one you almost never do very slightly easier makes no sense.

No hardware files

https://www.keepkey.com lists "open source" as one of KeepKey's features. Are the hardware design files (CAD, Gerber, PCB layout, etc) publicly available? If so, where? Or is the hardware closed source?

N.B. Please feel free to close this as an invalid bug, as it isn't strictly related to the firmware. However, it would be great to have an answer. Thanks!

Failed to match source-compiled hash with released binary hash [v.4.0.0]

I Docker compiled the v.4.0.0 source code and got the sha256sum 2500d49fdd8692dca988f2998b6bc658d22ae2187e3f34b2705b635381690193.

The sha256sum (excluding meta/sigs) of the official binary is 6350e95dea44b6e50eed67f95757fd1d543d8b13dc95b5eb38813655165583ab.

Can anyone reproduce these? Or have I done something wrong?

SSH support no longer working

I have a KeepKey and I was on firmware 5.10.2. It was working with the KeepKey client (the Chrome app), Electrum and even SSH via keepkey-agent (either https://github.com/romanz/trezor-agent or https://github.com/martin-lizner/trezor-ssh-agent).

I was curious about updating the KeepKey firmware, but I was worried about losing SSH support. I decided to upgrade to 6.4.0, and unfortunately SSH is not working anymore.

I like using the KeepKey for SSH, so I will probably try to downgrade back to 5.10.2 (or 5.11.0).

When I use keepkey-agent in Linux, I get the following error:

File "/usr/lib/python3.8/site-packages/libagent/device/keepkey_defs.py", line 14, in find_device
    return next(HidTransport(p) for p in HidTransport.enumerate())

It seems the new upgrade may've changed the device's USB ID, or something like that. Is this is an issue with the KeepKey firmware or with keepkey-agent?

can i change the name of my public keys?

Update libopencm3

#190 (comment)

idea: font space savings

There's somewhere on the order of 13k bytes worth of font in libboard. We can reduce that to ~1.6k by encoding everything as bits instead of whole bytes for each pixel. Perhaps even more savings by RLE-encoding them (since we need the decoder for that anyway).

Process to add new coins/tokens

The process to add support for new coins/tokens does not seem to be documented.

Are there any guidelines in place?

Unable to build emulator

I've tried building the emulator with docker however it fails to build.

$ ./scripts/build/docker/emulator/debug.sh 
v7: Pulling from kktech/firmware
Digest: sha256:5fe706d2c9ce9f5c0f6f8f5d1fddfe6d02aedeee5dec088270a3356b19390ced
Status: Image is up to date for kktech/firmware:v7
loading initial cache file /root/keepkey-firmware/cmake/caches/emulator.cmake
-- The C compiler identification is Clang 5.0.0
-- The CXX compiler identification is Clang 5.0.0
-- The ASM compiler identification is Clang
-- Found assembler: /usr/bin/clang
-- Check for working C compiler: /usr/bin/clang
-- Check for working C compiler: /usr/bin/clang -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/clang++
-- Check for working CXX compiler: /usr/bin/clang++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found PythonInterp: /usr/bin/python (found version "2.7.14") 
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - found
-- Found Threads: TRUE  
-- Configuring done
-- Generating done
-- Build files have been written to: /root/build
Scanning dependencies of target kktransport.pb
[  1%] Generating kktransport.pb.stamp, types.pb.c, exchange.pb.c, messages-eos.pb.c, messages.pb.c, ../../include/types.pb.h, ../../include/exchange.pb.h, ../../include/messages-eos.pb.h, ../../include/messages.pb.h
[  1%] Built target kktransport.pb
Scanning dependencies of target kktransport
[  2%] Building C object lib/transport/CMakeFiles/kktransport.dir/pb_encode.c.o
[  2%] Building C object lib/transport/CMakeFiles/kktransport.dir/pb_decode.c.o
[  3%] Building C object lib/transport/CMakeFiles/kktransport.dir/types.pb.c.o
[  4%] Building C object lib/transport/CMakeFiles/kktransport.dir/exchange.pb.c.o
[  4%] Building C object lib/transport/CMakeFiles/kktransport.dir/messages-eos.pb.c.o
[  5%] Building C object lib/transport/CMakeFiles/kktransport.dir/messages.pb.c.o
[  5%] Linking C static library ../libkktransport.a
[  6%] Built target kktransport
Scanning dependencies of target kkboard
[  6%] Building C object lib/board/CMakeFiles/kkboard.dir/check_bootloader.c.o
[  7%] Building C object lib/board/CMakeFiles/kkboard.dir/confirm_sm.c.o
[  8%] Building C object lib/board/CMakeFiles/kkboard.dir/draw.c.o
[  8%] Building C object lib/board/CMakeFiles/kkboard.dir/font.c.o
[  9%] Building C object lib/board/CMakeFiles/kkboard.dir/keepkey_board.c.o
[ 10%] Building C object lib/board/CMakeFiles/kkboard.dir/keepkey_button.c.o
[ 10%] Building C object lib/board/CMakeFiles/kkboard.dir/keepkey_display.c.o
[ 11%] Building C object lib/board/CMakeFiles/kkboard.dir/keepkey_flash.c.o
[ 12%] Building C object lib/board/CMakeFiles/kkboard.dir/keepkey_leds.c.o
[ 12%] Building C object lib/board/CMakeFiles/kkboard.dir/keepkey_usart.c.o
[ 13%] Building C object lib/board/CMakeFiles/kkboard.dir/layout.c.o
[ 14%] Building C object lib/board/CMakeFiles/kkboard.dir/memory.c.o
[ 14%] Building C object lib/board/CMakeFiles/kkboard.dir/mmhusr.c.o
[ 15%] Building C object lib/board/CMakeFiles/kkboard.dir/messages.c.o
[ 15%] Building C object lib/board/CMakeFiles/kkboard.dir/pin.c.o
[ 16%] Building C object lib/board/CMakeFiles/kkboard.dir/resources.c.o
[ 17%] Building C object lib/board/CMakeFiles/kkboard.dir/signatures.c.o
[ 17%] Building C object lib/board/CMakeFiles/kkboard.dir/supervise.c.o
[ 18%] Building C object lib/board/CMakeFiles/kkboard.dir/timer.c.o
[ 19%] Building C object lib/board/CMakeFiles/kkboard.dir/usb.c.o
[ 19%] Building C object lib/board/CMakeFiles/kkboard.dir/util.c.o
[ 20%] Building C object lib/board/CMakeFiles/kkboard.dir/variant.c.o
[ 21%] Building C object lib/board/CMakeFiles/kkboard.dir/udp.c.o
[ 21%] Linking C static library ../libkkboard.a
[ 21%] Built target kkboard
Scanning dependencies of target kkboard.keepkey
[ 22%] Building C object lib/board/CMakeFiles/kkboard.keepkey.dir/variant/keepkey/resources.c.o
[ 23%] Linking C static library ../libkkboard.keepkey.a
[ 23%] Built target kkboard.keepkey
Scanning dependencies of target kkboard.mfr
[ 23%] Building C object lib/board/CMakeFiles/kkboard.mfr.dir/variant/mfr/memory.c.o
[ 24%] Building C object lib/board/CMakeFiles/kkboard.mfr.dir/variant/mfr/resources.c.o
[ 25%] Linking C static library ../libkkboard.mfr.a
[ 25%] Built target kkboard.mfr
Scanning dependencies of target kkemulator
[ 26%] Building C object lib/emulator/CMakeFiles/kkemulator.dir/oled.c.o
[ 26%] Building C object lib/emulator/CMakeFiles/kkemulator.dir/udp.c.o
[ 27%] Building C object lib/emulator/CMakeFiles/kkemulator.dir/setup.c.o
[ 27%] Linking C static library ../libkkemulator.a
[ 27%] Built target kkemulator
Scanning dependencies of target kkfirmware.keepkey
[ 28%] Building C object lib/firmware/CMakeFiles/kkfirmware.keepkey.dir/variant/keepkey/resources.c.o
[ 29%] Linking C static library ../libkkfirmware.keepkey.a
[ 29%] Built target kkfirmware.keepkey
Scanning dependencies of target kkfirmware.mfr
[ 29%] Building C object lib/firmware/CMakeFiles/kkfirmware.mfr.dir/variant/mfr/resources.c.o
[ 30%] Linking C static library ../libkkfirmware.mfr.a
[ 30%] Built target kkfirmware.mfr
Scanning dependencies of target trezorqrenc
[ 31%] Building C object deps/qrenc/CMakeFiles/trezorqrenc.dir/trezor-qrenc/qr_encode.c.o
[ 32%] Linking C static library ../../lib/libtrezorqrenc.a
[ 32%] Built target trezorqrenc
Scanning dependencies of target ethereum_tokens.def
[ 32%] Generating ethereum_tokens.def
/root/build/lib/firmware/ethereum_tokens.def: Updating
[ 32%] Built target ethereum_tokens.def
Scanning dependencies of target trezorcrypto
[ 33%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/bip39.c.o
[ 34%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/hmac.c.o
[ 34%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/sha2.c.o
[ 35%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/base32.c.o
[ 36%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/hasher.c.o
[ 36%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/rand.c.o
[ 37%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/rc4.c.o
[ 37%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/blake256.c.o
[ 38%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/cash_addr.c.o
[ 39%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/curves.c.o
[ 39%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/rfc6979.c.o
[ 40%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/ed25519-donna/curve25519-donna-scalarmult-base.c.o
[ 41%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/ed25519-donna/ed25519-donna-32bit-tables.c.o
[ 41%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/ed25519-donna/ed25519.c.o
[ 42%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/ed25519-donna/curve25519-donna-helpers.c.o
[ 43%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/ed25519-donna/ed25519-keccak.c.o
[ 43%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/ed25519-donna/ed25519-sha3.c.o
[ 44%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/ed25519-donna/ed25519-donna-basepoint-table.c.o
[ 45%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/ed25519-donna/modm-donna-32bit.c.o
[ 45%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/ed25519-donna/curve25519-donna-32bit.c.o
[ 46%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/ed25519-donna/ed25519-donna-impl-base.c.o
[ 47%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/nem.c.o
[ 47%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/secp256k1.c.o
[ 48%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/bignum.c.o
[ 49%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/segwit_addr.c.o
[ 49%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/ripemd160.c.o
[ 50%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/groestl.c.o
[ 50%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/nist256p1.c.o
[ 51%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/memzero.c.o
[ 52%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/blake2b.c.o
[ 52%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/script.c.o
[ 53%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/bip32.c.o
[ 54%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/address.c.o
[ 54%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/blake2s.c.o
[ 55%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/sha3.c.o
[ 56%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/base58.c.o
[ 56%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/ecdsa.c.o
[ 57%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/pbkdf2.c.o
[ 58%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/aes/aeskey.c.o
[ 58%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/aes/aescrypt.c.o
[ 59%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/aes/aes_modes.c.o
[ 60%] Building C object deps/crypto/CMakeFiles/trezorcrypto.dir/trezor-crypto/aes/aestab.c.o
[ 60%] Linking C static library ../../lib/libtrezorcrypto.a
[ 60%] Built target trezorcrypto
Scanning dependencies of target kkfirmware
[ 61%] Building C object lib/firmware/CMakeFiles/kkfirmware.dir/app_confirm.c.o
/root/keepkey-firmware/lib/firmware/app_confirm.c:360:9: warning: implicit declaration of function 'strupr' is invalid in C99 [-Wimplicit-function-declaration]
        strupr(title);
        ^
1 warning generated.
[ 62%] Building C object lib/firmware/CMakeFiles/kkfirmware.dir/app_layout.c.o
[ 62%] Building C object lib/firmware/CMakeFiles/kkfirmware.dir/coins.c.o
[ 63%] Building C object lib/firmware/CMakeFiles/kkfirmware.dir/crypto.c.o
[ 64%] Building C object lib/firmware/CMakeFiles/kkfirmware.dir/eos.c.o
[ 64%] Building C object lib/firmware/CMakeFiles/kkfirmware.dir/eos-contracts/eosio.system.c.o
[ 65%] Building C object lib/firmware/CMakeFiles/kkfirmware.dir/eos-contracts/eosio.token.c.o
[ 66%] Building C object lib/firmware/CMakeFiles/kkfirmware.dir/ethereum.c.o
[ 66%] Building C object lib/firmware/CMakeFiles/kkfirmware.dir/ethereum_tokens.c.o
[ 67%] Building C object lib/firmware/CMakeFiles/kkfirmware.dir/exchange.c.o
/root/keepkey-firmware/lib/firmware/exchange.c:195:5: warning: implicit declaration of function 'strupr' is invalid in C99 [-Wimplicit-function-declaration]
    strupr(local_coin_name);
    ^
1 warning generated.
[ 68%] Building C object lib/firmware/CMakeFiles/kkfirmware.dir/fsm.c.o
[ 68%] Building C object lib/firmware/CMakeFiles/kkfirmware.dir/home_sm.c.o
[ 69%] Building C object lib/firmware/CMakeFiles/kkfirmware.dir/passphrase_sm.c.o
[ 70%] Building C object lib/firmware/CMakeFiles/kkfirmware.dir/pin_sm.c.o
[ 70%] Building C object lib/firmware/CMakeFiles/kkfirmware.dir/policy.c.o
[ 71%] Building C object lib/firmware/CMakeFiles/kkfirmware.dir/recovery.c.o
[ 72%] Building C object lib/firmware/CMakeFiles/kkfirmware.dir/recovery_cipher.c.o
[ 72%] Building C object lib/firmware/CMakeFiles/kkfirmware.dir/reset.c.o
[ 73%] Building C object lib/firmware/CMakeFiles/kkfirmware.dir/signing.c.o
[ 73%] Building C object lib/firmware/CMakeFiles/kkfirmware.dir/storage.c.o
[ 74%] Building C object lib/firmware/CMakeFiles/kkfirmware.dir/transaction.c.o
[ 75%] Building C object lib/firmware/CMakeFiles/kkfirmware.dir/u2f.c.o
[ 75%] Linking C static library ../libkkfirmware.a
[ 75%] Built target kkfirmware
Scanning dependencies of target kkrand
[ 76%] Building C object lib/rand/CMakeFiles/kkrand.dir/rng.c.o
[ 76%] Linking C static library ../libkkrand.a
[ 76%] Built target kkrand
Scanning dependencies of target kkvariant.keepkey
[ 77%] Building C object lib/variant/CMakeFiles/kkvariant.keepkey.dir/keepkey/keepkey.c.o
[ 77%] Building C object lib/variant/CMakeFiles/kkvariant.keepkey.dir/keepkey/logo.c.o
[ 78%] Linking C static library ../libkkvariant.keepkey.a
[ 78%] Built target kkvariant.keepkey
Scanning dependencies of target kkvariant.salt
[ 79%] Building C object lib/variant/CMakeFiles/kkvariant.salt.dir/salt/salt.c.o
[ 79%] Building C object lib/variant/CMakeFiles/kkvariant.salt.dir/salt/logo.c.o
[ 80%] Linking C static library ../libkkvariant.salt.a
[ 80%] Built target kkvariant.salt
Scanning dependencies of target kkvariant.poweredBy
[ 81%] Building C object lib/variant/CMakeFiles/kkvariant.poweredBy.dir/poweredBy/poweredBy.c.o
[ 81%] Building C object lib/variant/CMakeFiles/kkvariant.poweredBy.dir/poweredBy/logo.c.o
[ 82%] Linking C static library ../libkkvariant.poweredBy.a
[ 82%] Built target kkvariant.poweredBy
Scanning dependencies of target kkemu
[ 82%] Building CXX object tools/emulator/CMakeFiles/kkemu.dir/main.cpp.o
[ 83%] Linking CXX executable ../../bin/kkemu
[ 83%] Built target kkemu
Scanning dependencies of target rle-dump
[ 84%] Building CXX object tools/rle-dump/CMakeFiles/rle-dump.dir/main.cpp.o
[ 84%] Linking CXX executable ../../bin/rle-dump
[ 84%] Built target rle-dump
Scanning dependencies of target gtest
[ 85%] Building CXX object deps/googletest/googlemock/gtest/CMakeFiles/gtest.dir/src/gtest-all.cc.o
[ 85%] Linking CXX static library ../../../../lib/libgtestd.a
[ 85%] Built target gtest
Scanning dependencies of target gmock
[ 85%] Building CXX object deps/googletest/googlemock/CMakeFiles/gmock.dir/src/gmock-all.cc.o
[ 86%] Linking CXX static library ../../../lib/libgmockd.a
[ 86%] Built target gmock
Scanning dependencies of target gmock_main
[ 86%] Building CXX object deps/googletest/googlemock/CMakeFiles/gmock_main.dir/src/gmock_main.cc.o
[ 87%] Linking CXX static library ../../../lib/libgmock_maind.a
[ 87%] Built target gmock_main
Scanning dependencies of target gtest_main
[ 88%] Building CXX object deps/googletest/googlemock/gtest/CMakeFiles/gtest_main.dir/src/gtest_main.cc.o
[ 89%] Linking CXX static library ../../../../lib/libgtest_maind.a
[ 89%] Built target gtest_main
Scanning dependencies of target board-unit
[ 89%] Building CXX object unittests/board/CMakeFiles/board-unit.dir/board.cpp.o
[ 90%] Linking CXX executable ../../bin/board-unit
[ 90%] Built target board-unit
Scanning dependencies of target crypto-unit
[ 90%] Building CXX object unittests/crypto/CMakeFiles/crypto-unit.dir/rand.cpp.o
[ 91%] Building CXX object unittests/crypto/CMakeFiles/crypto-unit.dir/vuln1845.cpp.o
[ 92%] Linking CXX executable ../../bin/crypto-unit
../../lib/libkkrand.a(rng.c.o): In function `random_permute_char':
/root/keepkey-firmware/lib/rand/rng.c:103: undefined reference to `random_uniform'
../../lib/libkkrand.a(rng.c.o): In function `random_permute_u16':
/root/keepkey-firmware/lib/rand/rng.c:108: undefined reference to `random_uniform'
clang-5.0: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [unittests/crypto/CMakeFiles/crypto-unit.dir/build.make:135: bin/crypto-unit] Error 1
make[1]: *** [CMakeFiles/Makefile2:1488: unittests/crypto/CMakeFiles/crypto-unit.dir/all] Error 2
make: *** [Makefile:141: all] Error 2

Update nanopb

We're quite a few versions behind.

Checksum mismatch since v6.2.2

I tried to compiled the latest official fw v6.3.0 using a machine with docker.
I'm using the following script, to be sure to build a fresh new version each time.

version=v6.3.0 <- changed to the desired version
cd ~
rm -Rf keepkey-firmware/
git clone https://github.com/keepkey/keepkey-firmware.git
cd keepkey-firmware
git checkout $version
git submodule update --init --recursive
./scripts/build/docker/device/release.sh
# Compute hashes
sha256sum ./bin/firmware.keepkey.bin
tail -c +257 ./bin/firmware.keepkey.bin | sha256sum
wget https://github.com/keepkey/keepkey-firmware/releases/download/$version/firmware.keepkey.bin
tail -c +257 firmware.keepkey.bin | sha256sum

I get the following hashes :

6.3.0 ❓

1cc2f36eab7b71ba91d28d285210979e5a62363a4e4d777433ae268885daef4d
fac2060001d3d03aef65a3cef6805bb751b271313d20c3f178fb3b5341a53eda
3c63544ee6fa8c19f70071c563215e2010801381b34c385ec1cd92e1e203687c

6.2.2 ❓

a52431859b236b01291fc3f50dd560231be391ca4fc01ad7c9e243a2f7b70b30
597090aec0c426f14ecf88a5ada7d96f1699b410f372932511c84aa3e9bb7204
b1b22f06e81962c00ae8e807dc514641fd8d342f6953da0948a57027eebac71e

6.2.0 🆗

c699183079b2cf3c581ffe040a2c924570daff7d4d7b506845dfc32b55c3d5b0
8c1be122c285f43745e3455633a70915518ce56cbf42571f07db8e8ba564735a
8c1be122c285f43745e3455633a70915518ce56cbf42571f07db8e8ba564735a

6.1.1 🆗

76d822b8f050d44d1a361f1217634e3f614c5b6b031a8af0294d7ce650f263da
e3c85bc9ff45b89d0453ee0505dfc2febc669570535fc93bb10232a290fce81e
e3c85bc9ff45b89d0453ee0505dfc2febc669570535fc93bb10232a290fce81e

5.8.1 🆗

697bee3b4688f06ac14a4ac250169b29b0a9a09929b445610b33807a7ce777d1
d4005014ee8c6fa93bb7518000a69a06cf2fbbc6c8b0d309f642e649c5aa0b4d
697bee3b4688f06ac14a4ac250169b29b0a9a09929b445610b33807a7ce777d1

There's no reproducibility since v6.2.2. What am I doing wrong ?

Also the check process changed in fw from hashing the whole bin result in v5.x to excluding signature header in v6.x, that's a minor issue, more like a README.md not updated.

Support for more general output scripts

Keepkey does not support more general output scripts for signing, only basic templates like old-style limited OP_RETURN, P2SH and P2PKH. Bitcoin's scripting language is far more flexible and more general support would be very useful.

Coin integration

Hi, i updated coins.def for Electra integration: https://github.com/Jenova7/keepkey-firmware/blob/2537cc4f2b484c2d3149341b8ff433ca3495590f/include/keepkey/firmware/coins.def#L24

Is it enough or what are the other necessary points?

Thanks

Update ARM toolchain

It's been about a year since we updated gcc. New warnings are good... let's take advantage of them.

Support Bitcoin Regtest

It would be very useful for local development to have bitcoin regtest support in the coin table.

Here are the constants for regtest:
https://github.com/bcoin-org/bcoin/blob/f585d8616df8335fddbc21d1b776a979ec6ff305/lib/protocol/networks.js#L847

Satoshi Labs also has this slip:
https://github.com/satoshilabs/slips/blob/master/slip-0173.md

Potential SIGHASH_FORKID issue when signing multi-sig BCH transactions

Reported in keepkey/python-keepkey#18

Please Update Your Bootloader

I try to setup a new keepkey. I have Windows. I installed Windows app for upgrading keepkey. Then upgraded bootloader and firmware by tutorial. Suddenly after upgrading firmware and reconnecting the keepkey I have an error "Please Update Your Bootloader".
I tried 3 times to pass tutorial, but I always have an issue with bootloader at the end

How to prove signed firmware from KeepKey?

Trevor has a process that anyone can follow to prove that their signed firmware binary was made of the github source code at a specific tag. I don't see the tools available with KeepKey to prove the same.

For example, with Trezor, using the script firmware-fingerprint.sh, will remove the first 256 header bits from their official signed binary (where their signature is located) and a SHA256SUM of the rest of the file should match the SHA256SUM of the binary that can be compiled independently with the Github source code (using their script firmware-docker-build.sh).

The problem I am having with KeepKey, is their docker_build_release.sh script produces a binary file that has no header (the first 256 bits with the magic code KPKY is missing) - therefore, that binary file can't even be loaded into a KeepKey unit.

Question 1: How can we "sign" a firmware that we have compiled ourselves and load it to a KeepKey unit - with the understanding that unit will warn us every time we turn on the device that the firmware is not signed by KeepKey.

Question 2: How can we verify that the binaries provided by KeepKey matches the code on Github, for each version?

ROM savings meta-issue

#144 idea: font size savings
#190 .text section overflows rom region
#205 ROM size: misc gcc flags
fb0f6d9 dedupe bip39 wordlist

No license file

The licensing for the code in this repository is a bit unclear:

No licence file present at top level of repository.
No license mentioned in the README file.

I note that some of the files in the repository have copyright and licensing notices, e.g. https://github.com/keepkey/keepkey-firmware/blob/master/keepkey_board/public/keepkey_board.h states:

This library is free software: you can redistribute it and/or modify
it under the terms of the GNU Lesser General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

However, it is unclear which files within the repository constitute the "library" mentioned there.

Please could you add a license file to the top level of the repository, and ideally also mention the license in the readme, so that the licensing is clear?

Thanks!

Can't apply to support page. Can't send tokens

I can not apply to the support : https://keepkey.zendesk.com/hc/en-us
verification error

I am able to send ETH.

I am unable to send any tokens from the same account - I get the full dialog on the keepkey w/ pin entry, but after confirming the tx, the chrome app hangs and nothing shows up on any block explorers.

Please advise.

Supporting all SIGHASH_ types

It would be nice to be able to support SIGHASH_SINGLE and SIGHASH_ANYONECANPAY; perhaps also SIGHASH_NONE, transaction signing. The UI would need to warn / explain in some way.

Emulator build

Can't make the emulator build at all in Ubuntu18.04 :

First the doc build is so outdated and so useless. This now requires a recursive git clone, and the given build directory fails.

cd ~
wget https://jpa.kapsi.fi/nanopb/download/nanopb-0.2.9.2.tar.gz
tar xzf nanopb-0.2.9.2.tar.gz
cd nanopb/generator/proto
make
export PATH=~/nanopb/generator:$PATH
cd ~
git clone https://github.com/keepkey/keepkey-firmware
cd keepkey-firmware
git checkout v6.3.0
git submodule update --init --recursive
mkdir build
cd build
cmake -C ../cmake/caches/emulator.cmake ../
make

I get the error message :

[ 98%] Building CXX object unittests/firmware/CMakeFiles/firmware-unit.dir/storage.cpp.o
/home/moa/keepkey-firmware/unittests/firmware/storage.cpp: In member function ‘virtual void Storage_WriteMeta_Test::TestBody()’:
/home/moa/keepkey-firmware/unittests/firmware/storage.cpp:38:5: error: C99 designator ‘uuid’ outside aggregate initializer
     };
     ^
/home/moa/keepkey-firmware/unittests/firmware/storage.cpp:38:5: error: C99 designator ‘uuid_str’ outside aggregate initializer
/home/moa/keepkey-firmware/unittests/firmware/storage.cpp: In member function ‘virtual void Storage_WriteCacheV1_Test::TestBody()’:
/home/moa/keepkey-firmware/unittests/firmware/storage.cpp:188:5: error: C99 designator ‘root_seed_cache’ outside aggregate initializer
     };
     ^
/home/moa/keepkey-firmware/unittests/firmware/storage.cpp: In member function ‘virtual void Storage_DumpNode_Test::TestBody()’:
/home/moa/keepkey-firmware/unittests/firmware/storage.cpp:229:5: sorry, unimplemented: non-trivial designated initializers not supported
     };
     ^
/home/moa/keepkey-firmware/unittests/firmware/storage.cpp: In member function ‘virtual void Storage_UpgradePolicies_Test::TestBody()’:
/home/moa/keepkey-firmware/unittests/firmware/storage.cpp:589:5: error: C99 designator ‘policy_name’ outside aggregate initializer
     };
     ^
/home/moa/keepkey-firmware/unittests/firmware/storage.cpp:589:5: sorry, unimplemented: non-trivial designated initializers not supported
unittests/firmware/CMakeFiles/firmware-unit.dir/build.make:206: recipe for target 'unittests/firmware/CMakeFiles/firmware-unit.dir/storage.cpp.o' failed
make[2]: *** [unittests/firmware/CMakeFiles/firmware-unit.dir/storage.cpp.o] Error 1
CMakeFiles/Makefile2:1477: recipe for target 'unittests/firmware/CMakeFiles/firmware-unit.dir/all' failed
make[1]: *** [unittests/firmware/CMakeFiles/firmware-unit.dir/all] Error 2
Makefile:140: recipe for target 'all' failed
make: *** [all] Error 2

If I checkout the latest master and use nanopb 0.3.9.4, I have strictly the same error message.

Building with the docker script works. But then, it seems x86 and not AMD64, so difficult to use. Also @keepkeyjon is used to build it outside the script.

Any advice to compile and run emulator on Linux is welcome. I need to check because I can see some images artifacts on the keepkey and I investigate if this is a hardware issue or an issue in draw_bitmap_mono_rle.

Does not support Segwit

I'm pretty sure Trezor supports P2SH, so you can just copy most of the code from them.

Keepkey and BSV

Keepkey supports BSV transaction signing just fine by passing BitcoinCash as the coin name, and we use this in ElectrumSV.

However, for displaying bitcoin addresses for a user to confirm using client.get_address(), I cannot pass BitcoinCash as the coin name as we use original bitcoin addresses not cashaddr. So I pass Bitcoin. But then I get a nasty warning message about the address derivation (using BitcoinCash's 145' path) no being right because it expects 0'.

Could you add support for BSV as a separate coin type (with signing identical to BitcoinCash) that accepts BOTH 0' and 145' address derivations? Because of history, we use both in BSV (and no others).

GPG Key

Where is the public key for B4BE6B5BA471354E5D71AC5A1A60E4FE407D43EF, which signs the git tags and binary releases? I could not find it on keyservers. @keepkeyjon

idea: binary search for ETH tokens

Once we have: keepkey/python-keepkey#88, we could do a binary search here instead of linear: https://github.com/keepkey/keepkey-firmware/blob/master/lib/firmware/ethereum_tokens.c#L22, which would speed up ERC20 signing. This may get more important as the size of the table grows.

Related to #68.

Can't build KeepKey emulator (Ubuntu 18, GCC 7)

I've failed to build KeepKey emulator.

What I'm doing:

git clone https://github.com/keepkey/keepkey-firmware
cd keepkey-firmware
git submodule update --init --recursive
mkdir build
cd build
cmake -C ../cmake/caches/emulator.cmake ../ -DNANOPB_DIR=/path/to/nanopb-0.2.9.2 -DPROTOC_BINARY=/usr/bin/protoc
make

Simple cmake output (command cmake -C ../cmake/caches/emulator.cmake ../ -DNANOPB_DIR=home/sergey/src/nanopb-0.2.9.2 -DPROTOC_BINARY=/usr/bin/protoc >>cmake.out 2>&1): https://pastebin.com/TAkT3nNa

CMake output in trace-expand mode (command cmake --trace-expand -C ../cmake/caches/emulator.cmake ../ -DNANOPB_DIR=path/to/nanopb-0.2.9.2 -DPROTOC_BINARY=/usr/bin/protoc >>cmake.out 2>&1): https://www.sendspace.com/file/gmxtve (sorry, it is too big, can't place it at pastebin)

make output (command make >> make.out 2>&1): https://pastebin.com/CijBjZDw

I'm not sure, but looks like kkfirmware lib with unresolved references is linked before kkemulator lib that contains implementations.

Add Hatch (HATCH).

Please force the addition of HATCH.

A few things:

Being pushy / impatient isn't going to get you what you want.

Asset request form is here: https://docs.google.com/forms/d/e/1FAIpQLScUlcAUrlShaM5QT7a9Mbj30WjBnN9femcz2iSVrtaqW4TsbA/viewform fill it out, and wait. Don't ask for progress on the request. We'll let you know if we decide to list HATCH.

Originally posted by @keepkeyjon in #167 (comment)

We already filled out this form, we don’t have the opportunity to fill it out again, google does not allow it.