It can be decrypted with the seed_password you posted using Electrum's kdf and cipher, and the result is "This is just a test for AES decryption!", but as an Electrum seed it's meaningless, so I couldn't say where it came from.
btchris managed to decrypt the code which i posted as an example. So basically i need some kind of tutorial to fugure out how to use "electrum kdf and cipher" to decrypt the real code. Do you have an Electrum wallet file? If not, can you create a text file like this, except put your real encrypted seed in it? {"seed": "hGt+sQGFlt7Dhgb3a1kHetNJmlxrMQrZ3D8mheYgVr79ZEGOZK1btAzv44QMwGQ2K+1a/1ct10abxrX56OtvFA==", "use_encryption": true}If you can, you can follow the instructions I posted above to download and run a decryption tool, here: https://github.com/gurnec/decrypt_electrum_seed |
|
|
|
With Electrum 1.x, the "message" being encrypted is 16 random bytes of information (the decoded seed)...
Actually that's not true. The message being encrypted is a hex-encoded string of the 16 random bytes; it's 32 hex digits. On top of that, it's PKCS7 padded, which for a 32-byte string results in 16 bytes all of value 0xf being appended to the end of the string before encryption. This makes it very easy (and fast) to test passwords against Electrum 1.x wallets (with 2.x you can use a similar trick by trying to decrypt the master private key which is encoded in BIP32 xprv format before encryption). If you would like to make a script that tests many passwords, you will first have to understand how to derive from the decoded seed to the master public key.
Source: I have done so.... https://github.com/gurnec/btcrecover so the only way to know whether you got the password correct or not is to do the following:
1. Decrypt with AES and your password attempt.
2. Hash the result with itself 100000 times.
3. Use that final hash as a private key and find the x and y values of the public key.
4. Compare the x and y values to your wallet's MPK (master public key) and if they are equal, then your passphrase was correct.
Out of all of the wallets btcrecover supports (roughly 10 depending on how you count), the only wallet where I actually have to go so far as to derive a pubkey from a privkey to check if a password is correct is Armory. All of the others offer similar tricks to prevent having to doing so. That's not to say that they're all insecure. Although it's true there are a surprising number of wallets with non-existent key stretching, there are a few that do it right (from a key stretching point of view, anyways, some of these have other encryption issues): Bitcoin Core, Armory, MultiBit HD, Hive for OS X (vanilla bitcoinj), and to a much lesser extent Blockchain.info's most recent version as of roughly late last year. |
|
|
|
Thank you for the reply! Iv'e just posted this seed as an example. I found it somewhere on the internet. Ofcourse i wouldnt put the real one, to make it visible to everyone  Iv'e been looking for the Electrum kdf, but i couldnt find it... Could you explain how to use these tools, and where can i download them ? Thanks! Sure, just follow the instructions here: https://github.com/gurnec/decrypt_electrum_seedIf you don't have an Electrum wallet to use the script on, you can create a minimalist one containing this (it's just a JSON text file): {"seed": "hGt+sQGFlt7Dhgb3a1kHetNJmlxrMQrZ3D8mheYgVr79ZEGOZK1btAzv44QMwGQ2K+1a/1ct10abxrX56OtvFA==", "use_encryption": true}If you do need to create your own, the Python script will spit out a bunch of warnings which you can mostly ignore. FYI the KDF is sha256(sha256("password")), and the encryption is AES-256 in CBC mode with PKCS7 padding. Electrum 1's own mnemonic.py library is included and used if it's an Electrum 1 seed to finish the conversion from seed to mnemonic sentence. |
|
|
|
why is that?
A corrupt blockchain/Db is typically a symptom of a hard disk that's beginning to fail. No amount of software engineering can get around that problem. Just wanted to add that failing memory can cause file corruption as well; you might want to consider running memtest overnight just to double-check. I had a bad RAM stick with just a single bad bit. Just one bad bit out of 64 billion was enough for me to get DB corruption issues every couple of days (and there were no other obvious symptoms anywhere else on the PC). |
|
|
|
I'd try logging in with the next few paper codes, and maybe a couple of the most recently used-up codes too. If nothing works, you'll probably have to go through the two-factor removal process, which takes 2 weeks: https://localbitcoins.com/twofactor_reset_request/ |
|
|
|
edit: stop way to complex... the way to store this is:
make a section in the token / typos file which contains the old values. that way you can even store multiple runs.
eg
token1
token2
[before]
token1
[before]
token2
this shouldnt change anything in your security/thread model.
That's an interesting idea. Keep in mind it's not just the token / typos-map files that that I need to keep track of, it's also the command-line options too. Still, that could be doable. So here's what I'm thinking. New feature 1: add an "--exclude-passwordlist [FILE]" command line option. Passwords read from the FILE will be skipped. FILE defaults to stdin. This allows you to run btcrecover along these lines: btcrecover --tokenlist old-tokens.txt --listpass | btcrecover --exclude-passwordlist --tokenlist new-tokens.txt --wallet wallet.dat You could even combine multiple old runs, e.g. (Linux / OS X only): ( btcrecover --tokenlist old-tokens-1.txt --listpass ; btcrecover --tokenlist old-tokens-2.txt --listpass ) | btcrecover --exclude-passwordlist --tokenlist new-tokens.txt --wallet wallet.dat (maybe) new feature 2: add an "--exclude-tokenlist FILE" command line option (FILE is required). btcrecover --exclude-tokenlist old-tokens.txt --tokenlist new-tokens.txt --wallet wallet.dat It's a little more convenient than the first feature for common cases, but it's less flexible and more difficult to implement. (BTW I definitely liked your idea of multiple sections in a single tokenlist file, but keeping the files separate would be easier to code.) What do you think? |
|
|
|
a password for the autosave file is a little crazy... but you could extend your passwortcracker to crack your autosave file  couldnt resist...  is it possible to let the user enter a new password for wallet.dat as soon as you found it (maybe even let the user enter it as soon as you program starts (this seems(!) to be a good way to store it in mem: https://pypi.python.org/pypi/keyring)?That hurts my head to even think about.... btcrecover supports (depending on how you count) between 10 and 15 different wallet formats, and for many of them it only understands the bare minimum required to test passwords (and not nearly enough to read or write an entire wallet file). Cool library though (keyring), I haven't heard of it before. edit: stop way to complex... the way to store this is:
make a section in the token / typos file which contains the old values. that way you can even store multiple runs.
eg
token1
token2
[before]
token1
[before]
token2
this shouldnt change anything in your security/thread model.
That's an interesting idea. Keep in mind it's not just the token / typos-map files that that I need to keep track of, it's also the command-line options too. Still, that could be doable. (FYI I'm signing off for the night.) |
|
|
|
I think I understand what you're saying. If you run btcrecover with expanded parameters, it would be nice if it didn't check passwords that it checked during the last run, is that correct?
It does have some limited ability to do that with --min-typos and --min-tokens, but it's not ideal. TBH, I'm not sure how to improve it...
exactly... just one idea: use the old autosave file to calculate the old worldlist again and skip all entries for the new one (this may require to save the token / typos file inside the autosave). Agreed that could work, but I've intentionally avoided saving any sensitive information inside the autosave file. I save the command-line arguments in plaintext, but I only save an SHA1 of the tokenlist file in the autosave. It's bad enough with all of the insecure handling of password information that I do (see here), so I really wanted to avoid surprisingly saving any sensitive data inside the autosave file. (I only bother saving an SHA1 of the tokenlist file to ensure that someone doesn't try to resume a session with a changed tokenlist file, which would be a pretty bad idea...) |
|
|
|
well i tried... 12cores / 4days but i think its lost...i have given up...
Really sorry to hear that...  if it makes you feel any better, the reason I started working on this in the first place was to recover my own password... and despite a sh*tload of effort, I still haven't gotten it back yet.  but i like this app! very good work from you and i will recommend it (in fact i already did in another thread)
Thank you! just one suggestion: sometimes people use chars between the tokens (eg bitcoin-core vs bitcoincore) would be nice if you could support that.
I think this is a great idea. It would also help people who use passphrases with space-separated words. It's sort of possible to do today (by being clever with anchored tokens), but it's pretty painful. I'll definitely give this some thought. another idea (though i have no idea if this is even possible to implement): i have started with a narrow token definition and with --typos=1. as this did not work i tried to widen that definition which has lead to many duplicate checks. would be nice if somehow this can be reduced.
I think I understand what you're saying. If you run btcrecover with expanded parameters, it would be nice if it didn't check passwords that it checked during the last run, is that correct? It does have some limited ability to do that with --min-typos and --min-tokens, but it's not ideal. TBH, I'm not sure how to improve it... |
|
|
|
Dave at walletrecoveryservices.com managed to recover my password with only the information of what I originally thought my password was. He charges 20% of the wallet amount (not much in my case) and was totally trustworthy. With all the stories around hacking and dodgy activities flying around, it was nice to have this experience when just getting started. So thanks Dave I think I need his services too, can't recover my 5 btc If you'd like to try to recover it yourself, here's the Quick Start for an open source (free) tool called btcrecover: https://github.com/gurnec/btcrecover/blob/master/TUTORIAL.md#btcrecover-tutorial. It does take a bit of work to get it set up and running, though. (Full disclosure: I'm the author of that tool.) If you have any questions about it, just let me know. Although I've never dealt with Dave personally, he's gotten nothing but good reviews from what I can tell, so that seems like a good option too. |
|
|
|
thank you. i'll give it a shot. i'll tell my friend if it worked and that he should donate something (he'll like do this) Hi, onemorexmr. By all means, if you have a question or need a hand with something, just let me know (here in this thread or via PM if you'd prefer). Definitely want to use this: https://github.com/gurnec/btcrecoverThe developer is here on the forums, and is super nice. It is easy to use too. I forgot my password a few weeks ago, and it would of recovered it, except I remembered it as I was entering phrases to search for. Uhhmm... wow.. I'm not even sure my wife would describe me so nicely  (Thanks!) |
|
|
|
seed_password = 'a'
seed = 'hGt+sQGFlt7Dhgb3a1kHetNJmlxrMQrZ3D8mheYgVr79ZEGOZK1btAzv44QMwGQ2K+1a/1ct10abxrX56OtvFA=='
So the question is... Is it possible to get the seed back,by knowing the code above? Some help would be realy appreciated! Thanks!
First thing: if you think that is your seed and your password, it's a really bad idea to be posting it on the Internet. Luckily for you, it seems it's not. I don't really understand the chain of events you described, but the "seed" you posted above is definitely not an Electrum 1.x seed (and it's too short for a normal Electrum 2.x seed). It can be decrypted with the seed_password you posted using Electrum's kdf and cipher, and the result is "This is just a test for AES decryption!", but as an Electrum seed it's meaningless, so I couldn't say where it came from. |
|
|
|
It would be nice if there was an open source equivelent for the mobile app. Maybe one exists? I am not sure.
FreeOTP (which is OSS) is available for both Android and iOS: https://fedorahosted.org/freeotp/. I've been using it for a little less than a year now with no problems. It is maintained by a Red Hat employee (I'm not clear if it's actually sponsored by Red Hat, not that it matters to me). |
|
|
|
FYI I ran into... something. Running 67759a9 (will upgrade to the most recent now). I just now noticed that Armory wasn't running, it apparently crashed this morning. -DEBUG - 1426162994: (..\Blockchain.cpp:211) Organizing chain
-INFO - 1426162994: (..\BlockUtils.cpp:1531) Loading block data... file 242 offset 74249660
-INFO - 1426162994: (..\BlockUtils.cpp:589) Reading raw blocks finished at file 242 offset 74606873
-WARN - 1426162994: (..\BlockUtils.cpp:1116) Scanning from 347295 to 347295
-DEBUG - 1426163115: (..\Blockchain.cpp:211) Organizing chain
-DEBUG - 1426163116: (..\Blockchain.cpp:211) Organizing chain
-WARN - 1426163116: (..\Blockchain.cpp:317) Reorg detected!
-DEBUG - 1426163116: (..\Blockchain.cpp:211) Organizing chain w/ rebuild
-INFO - 1426163117: (..\BlockUtils.cpp:1531) Loading block data... file 242 offset 74606873
-INFO - 1426163117: (..\BlockUtils.cpp:589) Reading raw blocks finished at file 242 offset 75038837
-WARN - 1426163117: (..\BlockUtils.cpp:1633) Blockchain Reorganization detected!
-INFO - 1426163117: (c:\bitcoinarmory\cppforswig\ReorgUpdater.h:257) Reassessing Tx validity after reorg
-INFO - 1426163117: (c:\bitcoinarmory\cppforswig\ReorgUpdater.h:180) Invalidating old-chain transactions...
-ERROR - 1426163117: (..\BlockUtils.cpp:1658) Error adding block data: Cannot get undo data for block because not full!
-DEBUG - 1426163138: (..\Blockchain.cpp:211) Organizing chain
-INFO - 1426163138: (..\BlockUtils.cpp:1531) Loading block data... file 242 offset 75038837
-INFO - 1426163138: (..\BlockUtils.cpp:589) Reading raw blocks finished at file 242 offset 75080650
-WARN - 1426163138: (..\BlockUtils.cpp:1116) Scanning from 347297 to 347297
-DEBUG - 1426163193: (..\Blockchain.cpp:211) Organizing chain
-INFO - 1426163193: (..\BlockUtils.cpp:1531) Loading block data... file 242 offset 75080650
-INFO - 1426163193: (..\BlockUtils.cpp:589) Reading raw blocks finished at file 242 offset 75098598
-WARN - 1426163193: (..\BlockUtils.cpp:1116) Scanning from 347298 to 347298
-DEBUG - 1426163215: (..\Blockchain.cpp:211) Organizing chain
-INFO - 1426163215: (..\BlockUtils.cpp:1531) Loading block data... file 242 offset 75098598
-INFO - 1426163215: (..\BlockUtils.cpp:589) Reading raw blocks finished at file 242 offset 75098810
-WARN - 1426163215: (..\BlockUtils.cpp:1116) Scanning from 347299 to 347299
-DEBUG - 1426164532: (..\Blockchain.cpp:211) Organizing chain
-INFO - 1426164532: (..\BlockUtils.cpp:1531) Loading block data... file 242 offset 75098810
-INFO - 1426164532: (..\BlockUtils.cpp:589) Reading raw blocks finished at file 242 offset 75906414
-WARN - 1426164532: (..\BlockUtils.cpp:1116) Scanning from 347300 to 347300
2015-03-12 08:23 (INFO) -- Networking.py:215 - Received new block. 0000000000000000142c8fa8984becbe71c90658c89c3f77490bc40ad2b9be0b
2015-03-12 08:23 (INFO) -- ArmoryQt.py:6242 - New Block! : 347295
2015-03-12 08:23 (INFO) -- ArmoryQt.py:6250 - Current block number: 347295
2015-03-12 08:25 (INFO) -- ArmoryQt.py:6242 - New Block! : 347296
2015-03-12 08:25 (INFO) -- ArmoryQt.py:6250 - Current block number: 347296
2015-03-12 08:25 (INFO) -- Networking.py:215 - Received new block. 000000000000000006a4096ac98c907a3354fdf2dae617739c588a80bf0b54d4
2015-03-12 08:25 (INFO) -- ArmoryQt.py:6242 - New Block! : 347297
2015-03-12 08:25 (INFO) -- ArmoryQt.py:6250 - Current block number: 347297
2015-03-12 08:26 (INFO) -- ArmoryQt.py:6242 - New Block! : 347298
2015-03-12 08:26 (INFO) -- ArmoryQt.py:6250 - Current block number: 347298
2015-03-12 08:26 (INFO) -- Networking.py:215 - Received new block. 0000000000000000018a2949009fe75921bb6737cb2c1bc887a8ea6bf5ce056f
2015-03-12 08:26 (INFO) -- ArmoryQt.py:6242 - New Block! : 347299
2015-03-12 08:26 (INFO) -- ArmoryQt.py:6250 - Current block number: 347299
2015-03-12 08:29 (INFO) -- announcefetch.py:271 - Fetching: https://bitcoinarmory.com/announce.txt
2015-03-12 08:48 (INFO) -- ArmoryQt.py:6242 - New Block! : 347300
2015-03-12 08:48 (INFO) -- ArmoryQt.py:6250 - Current block number: 347300
|
|
|
|
I wish there were a way to keep the settings within Armory and not in the program's link. Is this sth that can be fixed? (.ini file?)
I'm with you, but then where would the .ini file be (and what if it were located in a path with non-ASCII characters)? The "right" way to do this is of course to store settings in the Windows registry, however the Armory devs have to support multiple OS's, and it's understandable that they don't want to have to maintain different code paths for every OS. On the plus side, an Armory dev did say that they plan to fix the non-ASCII-path issue over here: https://bitcointalk.org/index.php?topic=984101.msg10727929#msg10727929Another way to go about this would be to migrate all of the settings storage to QSettings. They already use Qt, and QSettings abstracts away the "right" thing and does it pretty well (it does use the Windows registry for example). Of course, every minute they spend fixing these types of issues is a minute they don't spend implementing something more important.... |
|
|
|
I don't know anything about Ethereum, so this is probably a stupid question, but what prevents the contract writer from offering a huge per-cycle fee and then providing an algorithm which (non-trivially) doesn't halt?
The cycles are not free. The success of such an attack is limited by the amount of money the attacker has. I was assuming that the attacker need only pay for completed machines (that reach a halted state). If everyone pays for cycles regardless of whether or not the machines halt, could a malicious miner DOS the network by operating machines up until their final state minus one cycle? (I'm asking dumb questions that are all answered in the referenced paper, just like ppl do when they don't read the original Satoshi paper, aren't I? Be honest....) |
|
|
|
Don't know if Windows/Python/Armory can deal with that either.
Actually (just FYI) most of the Win32 API accepts either forward or backward slashes as a path separator (both of which are disallowed in file names), and that extends to most programming languages including the C/C++/Python used by Armory. There are some frustrating exceptions though, so backslashes are safest (e.g. paths whose length exceed 260 characters must us a special format which requires backslashes). Then there's the legacy cmd.exe and the various legacy command-line tools which get confused with forward slashes (because they often indicate an option, akin to Unix's dash). These issues thankfully did not make it to PowerShell which behaves much more sanely. |
|
|
|
How does Ethereum prevent DoS attacks by rogue contractors (contracts taking advantage of Turing-completeness) ?
The contract states the amount the sender will pay the miner per cycle and a limit on the number of cycles. I don't know anything about Ethereum, so this is probably a stupid question, but what prevents the contract writer from offering a huge per-cycle fee and then providing an algorithm which (non-trivially) doesn't halt? |
|
|
|
I really doubt that Armory can deal with file paths (on any OS) that include non- ASCII characters (Unicode support in Python 2 is a real pain, something that I'm happy was fixed in Python 3). You'll probably need to create two folders that have only ASCII characters in their entire path, and then start Armory with two command-line options like this: armory --datadir=C:\Armory-datadir --satoshi-datadir=C:\Bitcoin-Core-datadir If you've already downloaded the blockchain, you should move the entire contents of %appdata%\Bitcoin to the new Bitcoin-Core-datadir (or you could make the Bitcoin-Core-datadir a symlink instead). Edited to add: it looks like some work has already been done to make Armory more Unicode friendly, so you might not need to move the Bitcoin Core datadir. If I were you I'd try moving just the Armory datadir first (and get rid of the --satoshi-datadir option). |
|
|
|
|
Show Posts
