This is an old thread, so hopefully you have been able to recover all your cryptos.

If not, there are known ways to recover all cryptos secured with Nano S firmware 1.3.1, but depending on the crypto type, it can require some efforts.

Do you still have the security card of your HW.1?

Note: I tried to send you a message, but i got:

User 'nimrodlehavi' has not chosen to allow messages from newbies. You should post in their relevant thread to remind them to enable this setting.

We have been able to recover BTC for old ledger HW-1 devices. You can read some of our reports here:

https://www.reddit.com/r/ledgerwallet/comments/1hcwpz2/successful_btc_recovery_from_ledger_hw1_version/

https://www.reddit.com/r/ledgerwallet/comments/m4pk7q/successful_recovery_of_btc_from_a_hw1_ledger/

https://www.reddit.com/r/ledgerwallet/comments/1h5d2cv/ledger_hw1_with_lost_security_card_and_lost_seed/

We can recover BTC from those old HW.1

Read our previous report:

https://www.reddit.com/r/ledgerwallet/s/PnbPQLzPXb

Some news on this old subject:

https://www.reddit.com/r/ledgerwallet/comments/1h5d2cv/ledger_hw1_with_lost_security_card_and_lost_seed/

- Short version / TL;DR:

Client has BTC secured by an old Ledger HW.1 hardware wallet, but lost their Security Card and their seed phrase. They still have their unlocking PIN.

The Ledger HW.1 hardware wallet, released in 2014 in the early days of the Ledger Company, is a screenless USB dongle supporting only BTC. Its Security Card feature provides an additional challenge-response layer of protection, preventing unauthorized transactions when the dongle is connected and unlocked.

Without the Security Card or recovery seed phrase, BTC secured by the HW.1 was considered irrecoverable.

However, in 2022, Ledger revealed a firmware vulnerability allowing reassignment of a new Security Card through brute-forcing responses to challenges:

https://donjon.ledger.com/lsb/017/

Note: This vulnerability applies only to older screenless Ledger devices (HW.1, Nano). Modern devices (Nano S, X, S+ etc.) are unaffected.

Using this vulnerability, we successfully exploited the HW.1’s firmware to brute-force responses and reassign a new Security Card in our test HW.1 dongle.

This technique will allow recovery of our Client's BTC.

I know, I was just wondering how it was possible to send a Tx that was spending unconfirmed deposits (i.e. with 0 confirmation). I don't think you can do that with ETH, for example. But I guess BTC allows that. Interesting.

thanks!

> The thief saw the receiving transaction to the address A and made a transaction to address B while the transaction to address A was still unconfirmed.
The fee paid for these transactions was high enough and a miner include both of them in the same block.

So the Tx from Kraken (in the mempool) is considered unconfirmed, and because it is in the mempool, it's ok to spend the utxo of this tx in another Tx?

This can obviously be only done by some mempool-watching bots.

Is it common to see this pattern in the blockchain?

A user contacted me about a weird / abnormal situation that caused them to lose 1.26869 BTC when transferring from Kraken to an wallet address under their control.

I can confirm that the situation (as seen on the blockchain) is very abnormal, and I cannot understand what caused it.

Basically, one BTC block contains 2 Txs:

- one is the transfer from Kraken to the user account address A (it's a native segqwit address in user wallet) which is the Tx that the user initialed by a withdrawal from Kraken,

- and in the same BTC block, there is a suspicious Tx from the user account address A to an unrecognized segwit address B that is not under control of the user, for a similar amount.

My understanding is that 1) this second (suspicious) Tx that moved the user funds could only have been signed by the user's private key - so likely a case of leaked key - and 2) this suspicious Tx sending the funds to address B could not have been normally initiated because no funds were on address A before the withdrawal from Kraken (which is mined in the same BTC block).

Can the BTC network (mempool) accept a Tx that moves funds from an address that has no balance / uxto?

This situation seems very abnormal to me, and the only way I think it could happen is with this BTC block 793728 being crafted by a malicious miner (or maybe a bot scanning the mempool?) who had access to the user's private key, in order to include the malicious signed Tx (A -> B) in that same block where the Kraken withdrawal was done.

Here are the info:

xpub: xpub6DAPV7c9WDLEg7GvJwZ2ptDmmQVfq7fB1hLKJJGg7P6kkLdBGnuBccSFbzBCcc6iZKZhnprKH6U Q5NNa4bkYRFVN91MuumjyE46oPSCgsCL

address A: https://www.blockchain.com/explorer/addresses/btc/bc1q927v5jvzm9pxkdxr0l8q325r3mrz8e9jp56cga (you can see both Txs on this page)

address B: https://www.blockchain.com/explorer/addresses/btc/bc1qn3rwwaaayt4ugusftlzac22rmve29mqcg6v5dt (where the BTC are now sitting)

BTC block: 793728

Have you guys seen anything like that before? And why is such a hack possible?

I have some Kayicoin (KAYI) on Cryptopia.

Will they automatically be converted into the new token?

if yes, when?, and when will they be tradable again on Cryptopia?

If no, what is the exact procedure we need to do to recover and trade our cryptopia KAYI (Kayicoin) token?

Thanks on behalf on all people holding Kayicoin on Cryptopia....