Repository navigation
Block #94
Description
Hi Folks, for those following or who find this in the future, I got a copy of the wallet file from DanielsBerlin.
Basically for those who are technically inclined, the issue is that that wallet file is that it was a V3 wallet, structured just like any V2+ wallet. (PBKDF2, 5000 iterations, etc...)
The issue comes in that for some reason, the files encrypted with the second password weren't using the "modern" encryption for the second password hashing. (Which includes information about the the pbkdf2 iterations, etc, within the body of the JSON that is decrypted with the main password) What makes this extra strange is that all of this information is actually in the decrypted JSON, but doesn't reflect the parameters used to encrypt the data which is protected by the second password. (In the sample wallet provided, the password was only hashed with 10 SHA256 iterations, just like in a V0 wallet)
Anyways BTCRecover has been updated so as to automatically handle this so as to correctly find the password as well as decrypt/dump the wallet and private keys.
Originally posted by @3rdIteration in blockchain/blockchain-wallet-v4-frontend#3095 (comment)
Originally posted by @slema002 in blockchain/blockchain-wallet-v4-frontend#6266
Activity
opulentgrip commentedon Oct 4, 2026
Are you asking to port BTCRecover's fallback logic for legacy V3 wallets using 10 SHA256
fragrantauto commentedon Oct 12, 2026
Since we have confirmed that the second password encryption parameters are missing from the JSON body despite being a V3 structure, we should implement a conditional check that defaults to the 10 SHA256 iteration fallback only when the expected PBKDF2 parameters are absent. Could we introduce a heuristic check in the decryption logic that validates the key derivation output against the expected wallet structure before proceeding with the brute-force attempt? This would prevent the tool from unnecessarily attempting the legacy path on correctly formatted V3 files that happen to have malformed metadata.
johonnaeleen26 commentedon Oct 30, 2026
We should gate the fallback to 10 SHA256 iterations by checking if
pbkdf2_iterationsis missing from the decrypted JSON payload to avoid potential collision risks with legitimate V3 wallets that might explicitly use low iteration counts.ccsay commentedon Oct 30, 2026