[HELP NEEDED] Did I make reallymine faster?

[andlabs]

I don't know if this will make anything faster for other people, but I split decryption itself across all CPUs. You can try it on the concurrent-decryption branch. A synthetic 2.4GB file decrypted in 3.5 minutes with this vs 11.5 minutes for the last binary release, but I didn't test much further than that. If it does make things faster somehow for everyone though, then I'll be surprised, but I can't know unless someone would be willing to try it. Thanks!

UPDATE I've now made some binaries available. You'll need to use the decrypt command to see the results.

Some benchmarks on a 400MB test file:
OS X Sierra 64-bit
original - average of 1m40s
concurrent - average of 10s
Linux 64-bit in a VM
original - average of 40m (???)
concurrent - average of 12s-18s

http://andlabs.lostsig.com/reallymine-concurrent-decryption-darwin64
3.1MB, md5sum 6a8acd865b9c8efb55d87ab8d5994b40

http://andlabs.lostsig.com/reallymine-concurrent-decryption-linux64
3.2MB, md5sum 5e2c82fe1c4a38b41ac5cdf5887261f5

[andlabs]

Also if you want me to provide a binary I could do so later.

[stynoo]

Could you provide a binary plz (Ubuntu 64bit if possible)? I can't seem to figure out how convince go to compile from the other branch. (Or I figured it out and it is still only working on one core.)

What I did notice is that the linux nfts driver introduces HUGE overhead and cpu-waits when decrypting so filesystem choice seems to be relevant as well when ppl report slow decrypts. I'll run some tests on that as well.

[puyuan]

I tried concurrent-decryption branch on WD Book Essential, Initio chip.
Command is: reallymine decrypt /dev/sdc /target_path_to_img.img
Its blazing fast, unfortunately nothing is decrypted.

I compared to the decryption on master branch. In the decrypted version, the hexdump -C -n 10000
would give me some ASCII text like "Invalid partition table", but in the concurrent version, it seems everything is still encrypted and showing a very different hex dump. Pretty much no readable ASCII.

I would love to use the concurrent version at the speed it was copying. Would love to see this fixed.

[andlabs]

@stynoo I can do so later, either today or tomorrow.

@puyuan Is the "decrypted" data the same as the encrypted data? What happens if you extract those early bytes into its own file and decrypt that?

[puyuan]

@andlabs

I did some more test. In the concurrent-decryption branch the
reallymine decrypt /dev/sdc supposedly_decrypt.img
simply makes a copy of the disk without decrypting. I can decrypt it again with
reallymine decryptfile supposedly_decrypt.img out.img dek steps
So the workaround now is:

reallymine getdek /dev/sdc
reallymine decryptfile /dev/sdc outfile "dek_from_above" "steps_from_above"

[andlabs]

Of course that will still do a non-concurrent decryption. So this is interesting; will have to look into it.

[andlabs]

Actually I forget if decryptfile does a concurrent decryption or not, but I do know what my mistake was: I was only decrypting the first 16 bytes of each 50MB block read. I'll fix it momentarily.

[andlabs]

Fixed that bug. I'll provide a new build later; I want to do some more benchmarking first.

[andlabs]

All right. Links and the benchmarks are in the first message above.

[stynoo]

Well, it works. But not faster...

root@tinker:~/reallymine_test# time ./reallymine.original decryptfile rm_5G.img rm_5G.original_dec.img b9f5f121f611416f4343ee4847f2ddfd03109682d97d46c6bf545f29fbee557a 'swaplongs decrypt swaplongs'

real	5m1.159s
user	1m19.360s
sys	3m38.992s

root@tinker:~/reallymine_test# time ./reallymine-concurrent-decryption-linux64 decryptfile rm_5G.img rm_5G.conc_dec.img b9f5f121f611416f4343ee4847f2ddfd03109682d97d46c6bf545f29fbee557a 'swaplongs decrypt swaplongs'

real	5m17.494s
user	1m25.192s
sys	3m40.736s

root@tinker:~/reallymine_test# md5sum rm_5G.original_dec.img 
2eeb5fcd20d5c02e3401c9c75c24f76f  rm_5G.original_dec.img

root@tinker:~/reallymine_test# md5sum rm_5G.conc_dec.img
2eeb5fcd20d5c02e3401c9c75c24f76f  rm_5G.conc_dec.img

root@tinker:~/reallymine_test# file rm_5G.conc_dec.img
rm_5G.conc_dec.img: DOS/MBR boot sector MS-MBR XP english at offset 0x12c "Invalid partition table" at offset 0x144 "Error loading operating system" at offset 0x163 "Missing operating system", disk signature 0x21968; partition 1 : ID=0xc, start-CHS (0x0,32,33), end-CHS (0x3ff,254,63), startsector 2048, 975398912 sectors

[andlabs]

decryptfile doesn't use the new code yet. You'll need to use the regular decrypt command. Sorry I didn't say that earlier.

[stynoo]

Sorry, then I cannot test it, the key got corrupted on the original drive and had to be retrieved from the modules. (Or maybe... can I manually add the key to the end of the img and loopmount?)

[athomic1]

If you have the key block, you SHOULD be able to insert it with a binary, hex, or sector editor. You could probably do the job with hexedit in Linux, and maybe something like Frhed in Windows. You'd want to be VERY careful about your aligments, though, to make sure it landed in the right place. You'd also need to make sure your tool knows how to work with MASSIVE data files.

I'd recommend working on a duplicate of the original image, but given the sizes we're dealing with, I don't imagine that's feasible for a lot of people.

[andlabs]

I'm going to be abandoning this branch and starting over.

[maxisvk]

tested on ubuntu 16.04 and i7-4770k give max speed output, about 120/130 Mb/s vs master branch only 10Mb/s. Also if destination disk is NTFS or EXFAT master branch give only 1Mb/s, this branch instead give max speed output on both Ext4 and NTFS and EXFAT

[gbatalski]

@andlabs hello, is it possible to test the decryptfile with the concurrent version now? I also could use a loop device but i don't have a password and need to provide a DEK to the decrypt command. Thnx and regards