That's interesting... because that reddit post links to this solution:
https://github.com/langerhans/dogecoin-w...-769800820
which suggest that the 3 iteration of MD5-based algorithm of openssl is used (same as requested and implemented here
https://github.com/hashcat/hashcat/issues/2303 ? That would be the hashcat hash type -m 22500 = MultiBit Classic .key (MD5)).
Also the analysis that the decrypted file always starts with org.dogecoin.production (see again github post above) could be very good for you since hashcat actually tests for 3 different cases (the most easy way to see this 3-case check is with the perl testing code, but the actual optimized kernel does the same:
https://github.com/hashcat/hashcat/blob/...pm#L59-L69 and
https://github.com/hashcat/hashcat/blob/...#L115-L131 , therefore there should be always a "bitcoinj" type addess at the start after an initial newline character \n).
I suggest that if you don't succeed with just using "openssl" to find the correct password with a trial-and-error on the command line (cmd) or a bash/batch script... you could try to create a test account with your old smartphone app and test if an example wallet password can be recovered this way.
BTW: there is also this guide:
https://github.com/langerhans/dogecoin-w...decrypting (strangely, it says that org.bitcoin.production , "bitcoin" not "dogecoin" is at the start of the file. This could also be an error in the documentation, dunno).
It's also interesting that there is an example here:
https://github.com/langerhans/dogecoin-w...stnet-3.50 and the tests here:
https://github.com/langerhans/dogecoin-w...t.java#L41 . This decrypted with an openssl command and password "password" (without quotes) indeed starts with newline char \n + org.bitcoin.test
Code:
openssl enc -d -aes-256-cbc -md md5 -a -in bitcoin-wallet-backup-testnet-3.50 2>/dev/null | xxd -g 1
enter aes-256-cbc decryption password:
00000000: 0a 10 6f 72 67 2e 62 69 74 63 6f 69 6e 2e 74 65 ..org.bitcoin.te
00000010: 73 74 12 20 00 00 00 00 76 12 55 a0 4d 0b 0b 23 st. ....v.U.M..#
00000020: fa 22 1b e8 39 ec 2d fc 25 d8 69 ae df b5 33 51 ."..9.-.%.i...3Q
00000030: 5e 1d 42 92 1a 4e 08 01 12 20 69 6a 51 8c 58 6a ^.B..N... ijQ.Xj
00000040: c4 75 94 ab 72 cb f2 89 6e 8e 8e 70 23 08 34 7d .u..r...n..p#.4}
00000050: 59 1a b1 e1 f8 d3 0e 23 18 36 1a 21 03 30 bd be Y......#.6.!.0..
00000060: a8 b5 a4 10 18 0c 7e 8e 4e 76 4a 6f 88 c4 a9 c7 ......~.NvJo....
00000070: 20 18 44 68 13 33 64 1a 4e d2 0f 5e ea 28 f0 98 .Dh.3d.N..^.(..
00000080: a2 d0 e9 28 28 01 38 00 60 b5 82 10 68 00 70 81 ...((.8.`...h.p.
00000090: e7 f0 9c 05
This wallet can indeed be cracked with hashcat like this:
1. base64 decode the "U2FsdGV..." like this
Code:
echo -n U2FsdGVkX19pY3qMQBP4lcdqITcJZLWS3CA99iFfEpwrt3O0f57yDfGDFxpybDZBNEus0OeP0a2mx9hwj7CGWaec6eU1pFQs/JF3TaGnH/i32VrmLU5TX2ay06+0XcIbommjC+U0Slx5HWS2ARt3UBF7dktVryZQrzpdncYVe88Cy8r2RezpwTScVBXyUnxSPpStVwoUy8ogJ4cAakhpHOu5n5qkQeHAy0CviaFVlOc= | base64 -d | xxd -g 1
00000000: 53 61 6c 74 65 64 5f 5f 69 63 7a 8c 40 13 f8 95 Salted__icz.@...
00000010: c7 6a 21 37 09 64 b5 92 dc 20 3d f6 21 5f 12 9c .j!7.d... =.!_..
00000020: 2b b7 73 b4 7f 9e f2 0d f1 83 17 1a 72 6c 36 41 +.s.........rl6A
...
...
...
now the first 8 hex characters are just "Salted__" which can be ignored.
The next 8 hex chars are important, because they make up the actual 8 byte salt (69637a8c4013f895), after that we need 32 bytes "encrypted data" (c76a21370964b592dc203df6215f129c2bb773b47f9ef20df183171a726c3641).
the full -m 22500 hash now will be this (again for the bitcoin-wallet-backup-testnet-3.50 example):
Code:
$multibit$1*69637a8c4013f895*c76a21370964b592dc203df6215f129c2bb773b47f9ef20df183171a726c3641
hashcat can crack this hash like this:
Code:
hashcat -m 22500 hash.txt dict.txt
$multibit$1*69637a8c4013f895*c76a21370964b592dc203df6215f129c2bb773b47f9ef20df183171a726c3641:password
Note: that the decrypted data contains "org.bitcoin.test" and nothing about dogecoin, but it seems that your backed up wallet starts similarly and has a similar format... and even if hashcat needs to find org.dogecoin.production or org.bitcoin.production it will succeed, because it just tests for some "non-random data", not a very specific address, fortunately.
I would give it a shot, but of course having more tests would be great
update:
I just noticed that your original post also includes an example with password 123...
so I tested it and it works with hashcat perfectly fine ! (same method with -m 22500 as explained above).
Your screenshots shows a file with this content:
Code:
U2FsdGVkX1/E+9YU2vL2g2ADcTJ+fIByG8Y2QGZXenNy/PR1E2ze7URSv6KlcQqwsBtx1fIg2fs5
...
BTW: I wasn't even sure about the exact beginning because your screenshot had some circles drawn around the start, but I figured out the correct start very quickly just by trial-and-error.
If we try to decrypt this with password 123 and openssl it of course works:
Code:
echo U2FsdGVkX1/E+9YU2vL2g2ADcTJ+fIByG8Y2QGZXenNy/PR1E2ze7URSv6KlcQqwsBtx1fIg2fs5 | openssl enc -d -aes-256-cbc -md md5 -a 2>/dev/null | xxd -g 1
enter aes-256-cbc decryption password:
00000000: 0a 17 6f 72 67 2e 64 6f 67 65 63 6f 69 6e 2e 70 ..org.dogecoin.p
00000010: 72 6f 64 75 63 74 69 6f 6e 12 20 64 11 07 9f 83 roduction. d....
Note that "org.dogecoin.production" is at the start of your 123 example... this is very good because hashcat's hash type -m 22500 exactly tests for such a non-random string at the start.
Now we know that this method should work and "org.dogecoin.production" is the correct string (not org.bitcoin.production as the documentation on the github repository says... maybe it's a general howto for bitcoinj-like wallets and the MAINNET parameters change depending on the cryptocurrency etc... but your dogecoin wallet repo probably should at least mention the correct one for this type of wallet).
Just for completeness I also include the instruction on how to convert the string to a hashcat hash here:
base64 to hex conversion (base64 decode and hex encode, or use hex editor):
Code:
echo -n U2FsdGVkX1/E+9YU2vL2g2ADcTJ+fIByG8Y2QGZXenNy/PR1E2ze7URSv6KlcQqwsBtx1fIg2fs5 | base64 -d | xxd -g1
00000000: 53 61 6c 74 65 64 5f 5f c4 fb d6 14 da f2 f6 83 Salted__........
00000010: 60 03 71 32 7e 7c 80 72 1b c6 36 40 66 57 7a 73 `.q2~|.r..6@fWzs
00000020: 72 fc f4 75 13 6c de ed 44 52 bf a2 a5 71 0a b0 r..u.l..DR...q..
as mentioned above we only need the first 16+32 bytes (actually only the 8 bytes salt after Salted__ and the next 32 bytes after the 8-byte salt). therefore we get this hash:
Code:
$multibit$1*c4fbd614daf2f683*600371327e7c80721bc6364066577a7372fcf475136cdeed4452bfa2a5710ab0
As you can see the 8 bytes of salt need to be separated by a star and the multibit signature must be added; both the salt and encrypted data are in hexadecimal format.
You can use hashcat to crack this hash like this:
Code:
hashcat -m 22500 hash.txt dict.txt
$multibit$1*c4fbd614daf2f683*600371327e7c80721bc6364066577a7372fcf475136cdeed4452bfa2a5710ab0:123