Topic: Tool to brute-force offline armory password? (Read 3098 times)

It's not that simple. Armory's KDF is brutal, brute forcing a password without any hint is basically impossible.

what if your not sure at all where to start?

New wallets do use master key encryption. Again, all this is possible and implemented... in the new wallets =P. Alas, the issue at hand is with the current wallets.

I've written (and have been improving I hope) a password recovery tool for a while now, and it includes support for Armory (that was the first wallet it supported as a matter of fact). You can find it here (it's open source): https://github.com/gurnec/btcrecover; the quick start is here: https://github.com/gurnec/btcrecover/blob/master/TUTORIAL.md#btcrecover-tutorial

Although it's not the easiest to use, it is fairly well documented, and it doesn't required that you send your wallet information to anyone else if that's a problem (if you run it offline, of course).

It's also probably faster than any alternative -- it's multi-threaded, so if you have a quad-core CPU, it'll run about four times faster than most alternatives. It also supports GPU-accelerated searches, although it's not very effective on that front for Armory.^*


That would be excellent. Of all of the wallets currently supported by btcrecover, Armory is the only one where I couldn't find a way to extract enough information from a wallet file to test for passwords without putting funds at risk.

Armory encodes private keys as 32-bit blobs with no padding (which is not a weakness by any means, just an inconvenience when it comes to this particular task). Every other wallet I've encountered so far offers some form of "trick" that allows me to extract only a portion of a private key (or a hash thereof) for password testing purposes. For example, many wallets add PKSC7 padding to the end, which allows me to extract just 16 bytes of key material (50%) plus the (useless) 16-byte padding in order to search for passwords. Others encode their passwords in hex or base58 prior to encryption, which allows a similar trick of extracting only a portion of any private key/seed material. It's not that Armory is inferior for being more concise (by not including padding and by using binary instead of unnecessary encoding) -- it's just that it's the only wallet I've encountered so far where you need an entire private key to test for password validity.^**



* It depends a whole lot on your GPU memory size and the KDF parameters used during wallet creation to determine whether or not GPU-based acceleration can help in password searches. Armory's excellent use of ROMix makes GPU acceleration hard (even with btcrecover's time-space tradeoff), so a GPU might help by a factor of 5x or so, or it might not help at all....

** which in combination with the (unencrypted) chaincode and master public key does put funds at risk

Instead of directly encrypting the private key with the user passcode, we could encrypt the private key with a long random key, which is encrypted with the user passcode. When a user forgot the passcode, he may pay other people to brute-force the random key, without the risk of losing bitcoin.

I thought about bringing this up earlier as a general threat vector (i.e., I'm not saying the OP would do this), but yes, this is one reason why people don't like handling private user/customer data. What are the chances that the user will turn around and make false/inaccurate claims? The blockchain and the various analytics make it easy to concoct a story where the evil Armory developer (or hacker breaking into an Armory computer) swept the wallet into their own wallet. It's a huge Pandora's Box that many people would prefer not to touch in the first place. Providing the recovery script is a good compromise for people who have the technical chops to use it. Everybody else? Frankly, in some ways, we're taking as much of a risk as they are in sending us their data, if not more so.

Don't, under any circumstances, accept to receive is wallet and password info in the unlikely event that he changes his mind.  With this attitude, you can only get trouble from it; and if something bad later happens you will most likely be blamed.  If he thinks that losing the btc is better than giving you a chance to help him, but also a chance to steal his btc if you are dishonest, then he is more mistrusting than most (to put it politely).

What goatpig said.

If somebody has a philosophical objection to sending us private data, I get it, and I don't begrudge them at all. Not everybody is willing to offer that level of trust. Even those who can offer it should only send their data via PGP-encrypted email (and expect the same from us), and they should move their money to a new wallet we can't access the second their password is recovered.

If somebody thinks we've played a little fast-and-loose with some terminology, they're right, although I promise them any goofs weren't malicious. Most people we hear from in the support channels don't necessarily have the technical prowess to run these scripts. Telling people to run scripts they're not familiar with will just confuse some people even further. So, it's natural that some of us tend to refer to these kinds of things as internal tools. (That said, perhaps we should let people know there are options if they are techies. Balance and all that.)

If somebody thinks we're incompetent and will somehow lose their coins, why are they using Armory in the first place?

If somebody thinks we're stupid enough to swipe coins from people at all, much less people who are already on a message board and can yell and scream about how we've robbed them, they're nuts. Our reputation is well worth protecting. Stealing coins, or having Sterling Archer somehow lose the coins, doesn't benefit anyone, much less us as a company.

Personally, I think the decentralized brute force idea is pretty intriguing, especially if we can get some crypto experts to go over the idea and bless it. But, we're not there yet, and we have what we have right now. If anybody has any ideas or code to offer, let us know, or post here, or both. We will appreciate it, I assure you.

https://github.com/etotheipi/BitcoinArmory/blob/master/extras/findpass.py

The script has been here the whole time. Maybe internal tool is not the proper wording, but this script needs some customization for your password pattern to squeeze decent performance, and as I said, you need to build the C++ library for the crypto, which can be painful for some. You could also just copy over the compiled so/dll from our binaries and get away with that.

Giving us your wallet is not an obligation in any way. All this code is open source, and provided you know some Python you can get away with the script on your own with moderate efforts.

If you are a responsible user, you would have paper backups (as you do), and then by all means you should just wait until you have access to them again.

If you don't have backups and can't go through the effort of setting the up the script on your own, but still have a little Python in you, you can extract that last address entry with an encrypted private key from your wallet and send us that. That's enough for us to run your password pattern against, and not enough data to recreate private keys preceding this one. This way we would not stand in a position to rob you, but you would have to roll a new wallet to move your funds there.

Ultimately, if you can't code and have no backups, you can either give up on your coins or trust us. Considering you already trust us with the code (chances are you didn't review any of our code on your own), I don't understand why you feel so uncomfortable trusting the coders. Etotheipi doesn't agree with me. He feels uncomfortable dealing with any users private data, under any condition, and frankly we'd prefer not to deal with private data, we got enough responsibility as it is. This is why he came up with the public challenge idea to allow password retrieval without exposing any private data. But that kind of development takes time and this option isn't available yet, sadly.

Decentralized and open source projects are driven by a motivation to reduce the need for trust between parties, and I think there is great power and opportunity in such approach. Yet, that doesn't mean trust is undesirable at all times. It's rather an assessment that trust is hard to build and often impractical, and that it can (and often should) be circumvented through technology. I don't think it applies in this case however.

Our greatest asset as a company is the reputation we have built ourselves, through hard work and good conduct. The loss we would incur by robbing the occasional user would largely outweigh the benefit, and most likely destroy all we have achieved through our effort. On the other hand, providing free support for a free product nets only good rep. How many open source companies can you name that have a free, direct support channel with access to the developers? Why would we go to such length and destroy it all in one go?

Even then, if you don't feel comfortable trusting us any further than with code and binaries, you still have plenty of options at your disposal. And contrary to your belief, we have a RPC interface. It's called armoryd.py, and yes, it is in our repo, right here:

https://github.com/etotheipi/BitcoinArmory/blob/master/armoryd.py

Perl away all you want. I suggested the Python script because that's a dedicated tool, but by all means, if you feel the RPC interface suits your needs better, go ahead.

You're not required to send us anything. Like goatpig said, the script is provided. Perhaps we should've been clearer about that. (Hell, I didn't know about it 'til goatpig pointed it out.)

In any event, if you have a way to improve the script, feel free to send it our way. We'll look at it and consider including it. Or post it here. Whatever's clever.


Assuming I understood goatpig correctly, there is no internal tool other than the script he mentioned. (Poor wording, I agree.) AFAIK, you have what we have. We just default to asking for wallets and password remnants because, quite frankly, quite a few people have enough trouble running a simple Python script. (Even if they can run it, there's no guarantee it'll work out-of-the-box on their system.) It's just easier to do it in-house, even if it understandably ruffles the feathers of some people.

Understood - but why require me to send you my wallet and guessed password, instead of YOU providing a way to interface with the software?

I've spent half the day writing an autohotkey script to type in a password list into the software.

With the bitcoin wallet - I can try passwords via RPC.

With Armory, there is no way to do that, and you have an internal tool that will try, yet, we can't have it, and instead you want us to send the wallet and password. Thats not right. On what planet is is MORE acceptable to ask users to take that risk, than for you to provide a simple tool.

If your reasoning behind not providing the tool is "security" and fear of it falling into the hands of hackers, security through obscurity is pointless. Using a free windows tool I've fired off a brute force process. Yes, it's slower than a direct RPC call, but it's running now. You not providing the tool is not stopping anyone from trying to brute force a wallet. Outlaw the guns, only the criminals will have the guns. Don't release the tool, only the hackers who really want to brute the wallets will create their own tool. End result? Honest customers with a problem are really inconvenienced, and you've stopped no one.

You can close my ticket, I found a way to do it myself.

Later when I find some free time, I'm going to figure out a way to do it directly, without having the GUI open and a script program typing passwords and clicking buttons.

Then I'm going to release the software.

And you keeping your tool out of the hands of the people who NEED it becomes utterly irrelevant. Again: End result? Honest customers with a problem have a solution to try, and you've still not stopped a single hacker.

Thanks.

(Side note: Today, sober, I wouldn't curse, but how I feel is no different. It's a jackass move to have an internal tool you won't share, under the pretense of keeping hackers out. At least, thats the only reason I can fathom for not releasing it)

With all due respect, there's only so much we can do at any given time. Armory is open source software. Even if we wanted to add some super-duper-secret backdoor that would let us recover coins from wallets at will, somebody would find it, and we'd be strung up by our junk in the virtual town square. We also only have so much time to devote in instances like these. People sometimes come asking for help. We could turn them away. We've decided to offer help if people are willing to accept the parameters. The lowest hanging fruit is the wallet data and the password remnants. The lowest hanging fruit also tends to be the kind that requires the most trust from the end user. It's not ideal, but hey, there are only so many hours in a day, and there are a million other things we need to have finished yesterday.

Yes, I agree that sending a wallet and what one can remember of their password is risky. I'd also like to know what alternatives people have in mind, other than just accepting that their coins might be lost. We offer multiple ways to back up wallets when said wallets are created (or even well after they're created) so that our services aren't required. We also offer a last-gasp alternative if people are willing to get their hands a little dirty one way or another. Someday, maybe we'll have a shiny alternative, like the one goatpig mentioned, that doesn't require cursing at us in public. Until then, this is the way it is. Cursing at us, and then blaming one's behavior on being intoxicated, isn't going to help matters.

At the risk of sounding arrogant, keep in mind that other businesses just plain won't help you if you forget your password. I've seen several companies that had an explicit policy stating that customers who forgot their passwords, or needed some sort of help with debugging (e.g., using Wireshark to decrypt TLS output using a customer's private key), were SOL. This included multinational corporations who had spent millions of dollars on specialized hardware. There are good reasons why even they don't always get the help they want. (There are also good reasons why they should get help. It's a balancing act.)

Wait. I have to give you my wallet and my thoughts on my password? I was under the assumption you'd give me access to the tool.

Please take this in the most respectful way possible: you can go f*ck yourselves.

What company in their right mind asks a use for that?

I would rather lose the btc I the wallet than give unknown people my wallet file AND what I believe my password to be.

I'm not trying to be an asshole here - but given the choice between giving the internal tool to users, and keeping it private and asking users to send you their wallet and approximate password, you guys are absolutely insane, and arrogant pricks, if your choice is "send us your info."

Close my ticket. I'd rather lose the bitcoin than risk ANYONE else getting it.

You just completely lost my faith in your software. Wtf is wrong with you people?

EDIT: I didn't see the end part about the python script. I'll try grabbing it and using it. That being said - no - I'm not giving you my wallet and approximate password.

EDIT 2: My gf had a party tonigt and I've had a few drinks. I may not exactly be polite. 😁😁

etotheipi has an idea for that purpose, which was something like keeping an entry in each wallet for a public challenge you can roll against password candidates, so that others can offer to brute force your password for you without getting your wallet, just the challenge, while proving proof they find the password to the user. That idea was to create a way for the community to offer computing power to users who forgot a lot of their password and have no backup, most likely against a monetary incentive.

I think we still plan on implementing that feature in the new wallets, but for this current case, infernusdoleo would have have to give his password AND wallet, and trust we don't rob him.


That's not true. If you aren't afraid to get your hands a little dirty with Python, the script is available in our repo, at ./extras/findpass.py. I think you'll have to build the C++ library for the crypto, but I'm not sure. Ask CircusPeanut, he built this script. Otherwise we can run it for you.

Except... There's no such thing as another password that will "also work".

Right, but that's because Armory has a way to validate it: it can try to decrypt your wallet. Since you're not sending the Armory developers your wallet or your private key, they don't have the ability to test to see if this is the right password and this tool would likely never actually work since they would/could just send you the first password they came up with and if it works it works, if it doesn't it doesn't.  Their answer seem to indicate that, given a weak enough password and you remembering enough of it for them to work from, they can send you a password that has a very reasonable chance of working and they might (they haven't said this so I don't know) have the ability to know when the recreation process succeeded or failed.

Don't get me wrong, I'm not trying to be a dick here at all and I certainly understand how brute force works. But what bothers me most is that they can have some certainty that the generation process worked. Unless I am completely misunderstanding how things work (and I may be, so feel free to correct me if I am) they shouldn't be able to do that without testing the password against a private key (which they don't and should not have).

Thanks for the info. I submitted a ticket.

Guys - it's a brute force tool. Which is utterly useless if you have a secure password. Will take years to figure it out.

The only reason I'm asking for this tool is Armory does not have an RPC interface or anything similar - if this were my bitcoin-qt wallet for which I effed up the password, I'd simply just brute force against the RPC with a perl script. But since it's Armory, and I need to manually type in all my password guesses, which would take forEVER, I was looking for electronic assistance. Which, thankfully, Armory has.

Unfortunately I havent heard back yet. It's the weekend. I hope I'm not waiting til Monday. 

As for how you validate it recreated the password - you use it. If it works, it did it right. If it does't, it didn't How does the Armory client know you typed in the right password?

OK, I understand what you're saying. But, here's another question: how, without the private key, do you validate that tool has recreated the correct password? Is this documented anywhere?

It depends on the capacity of the computer you have (computing power) but majority of it.