rippex/ripple wallet lost passphrase

[kiara]

since he still have his pc where he generated the wallet , i will try to get the hand on it,
ones i do i will tell you exactly what version it was used to generate the wallet .
i guess he has also the setup.exe i will take this and installed it somewhere else and create wallets to see if the length of them are different .

(also , would that help to do something with this pc ? beside what i described above)

[philsmd]

Thanks for testing kiara.

yeah that thing you noticed with using the hash directly within the command line is not really a bug... hashcat never sees the full hash since every $xyz string is interpreted as a variable by your shell/bash etc.
just test it like this:

Code:

echo "---$THIS_IS_A_SHELL_VARIABLE---"

This is actually true for every hash format that has a "$" in it... and therefore for many hash modes that hashcat supports... you can work around it by escaping it (or using different types of quotes like the single quote ') or using a hash file (of course the whole mechanism about what is interpreted as a variable by your shell/cmd or not and how to escape it, depends a lot on the shell and operating system itself, so read the shell's manual, if you really have to do it e.g. echo "\$VAR" ).

For me your testing seems to indicate that everything is working fine, including the extractor... and the speed seems to very good and what we would expect with a little bit more advanced -m 10900 like algo with 1000 iterations).

I've also analyzed the decrypted wallet (plain text) and the length seems to be varying a little bit. the main JSON keys that changed are:

Code:

"sequence":1,
"fee":200000,
"defaultDirectory":""

of course this makes the ciphertext (and plaintext) longer, if some of these keys/values are different or missing, but the hash module and kernel actually accepts all of these lengths/strings.


I don't think the PC could now help a lot for finalizing/improving this new hash module/addition. If anything, it could maybe help your friend somehow to discover or remember the password, but in my opinion it's not important to do anything special with this PC to make this module better etc.

I've also thought a little bit about what we could optimize further, but the only thing that came to my mind is this little test/change that could or could not make a little speed difference (attached file, run within shell).

I was also thinking about using an entropy check right away instead of the TAG, but for me the tag / checksum turned out to be faster (compared to adding some additional code for an entropy/randomness check with the hc_get_entropy () function or similar, the other problem is that we would need to assume/have a fixed minimum data length and check the plaintext for randomness and therefore the plaintext shouldn't be too small... for truecrypt/veracrypt we use at least 512 bytes which aren't available here). An advantage of the entropy check would be that we wouldn't need to rely on the short 8 byte tag. But since it seems to be slower, it's not really a valid/good alternative.

Hopefully the most important wallet here, the one of your friend, is also working (extraction and accepted by hashcat).
Good luck cracking. thx

[kiara]

Thanks for testing kiara.

yeah that thing you noticed with using the hash directly within the command line is not really a bug... hashcat never sees the full hash since every $xyz string is interpreted as a variable by your shell/bash etc.
just test it like this:

Code:

echo "---$THIS_IS_A_SHELL_VARIABLE---"

This is actually true for every hash format that has a "$" in it... and therefore for many hash modes that hashcat supports... you can work around it by escaping it (or using different types of quotes like the single quote ') or using a hash file (of course the whole mechanism about what is interpreted as a variable by your shell/cmd or not and how to escape it, depends a lot on the shell and operating system itself, so read the shell's manual, if you really have to do it e.g. echo "\$VAR" ).

For me your testing seems to indicate that everything is working fine, including the extractor... and the speed seems to very good and what we would expect with a little bit more advanced -m 10900 like algo with 1000 iterations).

I've also analyzed the decrypted wallet (plain text) and the length seems to be varying a little bit. the main JSON keys that changed are:

Code:

"sequence":1,
"fee":200000,
"defaultDirectory":""

of course this makes the ciphertext (and plaintext) longer, if some of these keys/values are different or missing, but the hash module and kernel actually accepts all of these lengths/strings.


I don't think the PC could now help a lot for finalizing/improving this new hash module/addition. If anything, it could maybe help your friend somehow to discover or remember the password, but in my opinion it's not important to do anything special with this PC to make this module better etc.

I've also thought a little bit about what we could optimize further, but the only thing that came to my mind is this little test/change that could or could not make a little speed difference (attached file, run within shell).

I was also thinking about using an entropy check right away instead of the TAG, but for me the tag / checksum turned out to be faster (compared to adding some additional code for an entropy/randomness check with the hc_get_entropy () function or similar, the other problem is that we would need to assume/have a fixed minimum data length and check the plaintext for randomness and therefore the plaintext shouldn't be too small... for truecrypt/veracrypt we use at least 512 bytes which aren't available here). An advantage of the entropy check would be that we wouldn't need to rely on the short 8 byte tag. But since it seems to be slower, it's not really a valid/good alternative.

Hopefully the most important wallet here, the one of your friend, is also working (extraction and accepted by hashcat).
Good luck cracking. thx

not sure what you shared as an attachment .

any how, i got a hand of his pc, i created a wallet , and hold and behold the length is longer, and i dont know why.

the wallet version is exactly the same as the one i used 1.4.1 i also checked the checksum of both installers (the one that he had on his laptop and the one i had) they are exactly the same .

so idk wtf is going on honestly  
i created a test wallet on his pc, and was able to cracked it aswell even tho the length was longer .



i've attached the wallet i've created from his pc. 
i got really no clue why this is happening

[philsmd]

I think the reason why you are confused is that there are different lengths:
- base64 wallet string length
- JSON length (the above wallet, but base64 decoded)
- ct (ciphertext) / data length (this is also base64 encoded again)

The overall wallet file length (and therefore also the JSON length, whose lengths are related) could sometimes contain additional JSON fields/lkeys (as mentioned above the "fee", or installed directory etc)... so it's perfectly normal if the length and file size isn't always the same (even with the same installer and running software). It doesn't matter too much.

the only real important thing to us for now is the "ct" length, but the hashcat module supports quite large range of "ct" lengths (from 128 to 512 base64 characters for now).

it would be interesting to know what that encrypted "contacts" lists would normally look like... it could maybe be longer if the user made a lot of transactions or somehow stored some contacts etc... but this of course can only be seen when trying a heavily used wallet (I guess). maybe there also exists a test network where you can make some transactions / contacts for free, without spending any coins/money. dunno

Maybe this information can also be found out on the internet or when reading the rippex source code (I didn't investigate this yet).


The attachment (diff.txt) was basically a test change (diff / patch) included as base64 string within a shell script (that's why I said it needs to be run by bash or a shell). I did some tests and for me it doesn't seem to make much of a difference even with the precomputed lookup table. Instead, on my systems the speed of my current github branch is slightly better/faster on my systems (yeah, diff.txt would need to be applied on top of the github branch, an additional change).

---

update, I've now analyzed the above new wallet and the encrypted text ("ct") contains these additional fields:

Code:

"preferred_issuer":{},
"preferred_second_issuer":{}

so yeah, this doesn't really matter too much (the only problem would be if the ct length would be really very, very long. like > 512 bytes)

[kiara]

kudos for all what you've done phil


i've tried and failed to recover his password for like 2-3 days with all the combination he remember .
i guess he needs to dream about it more

at least now , hashcat community as the ability to crack their lost rippex wallet

btw if you need the setup file tell me i will upload it . (tho its opened source so it can be compiled )

thanks alot !
and great f***** job