Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A tale of Phobos – How we almost cracked a ransomware using CUDA

cert.pl

Post reply on HN
Print view View original

51–60 of 65 posts

Re: A tale of Phobos – How we almost cracked a ransomware using CUDA

#51

Post by ganoushoreilly »

zitterbewegung wrote: post #45

I think this would be a stupid idea but you can buy an Antminer for $2458 and it does 104 TH/S for SHA256. I think doing a bit of hacking to make it crack the ransomware might be feasible?

There have been tons of projects that tried to repurpose bitcoin hardware. Even if it's not the latest that's a lot of computational power! So far though none of the project I follow have yielded any real results.

Here's a interesting read that gives a bit of info on the differences and why it doesn't really work. https://rya.nc/asic-cracking.html

Re: A tale of Phobos – How we almost cracked a ransomware using CUDA

#52

Post by iforgotpassword »

deeesstoronto wrote: post #50
fps_doug wrote: post #23

Earlier quoted context omitted.

Don't do simple rolling backups, use something with deduplication like borg backup or ZFS/btrfs if you want to do it at the FS level. The backup size should not increase by much more than the actual size of any new files, so if suddenly, you need twice as much backup space because all your files seem to have changed, you should get suspicious.

Also ensure your client does not have access to the backup server share so that ransomware can't encrypt backups on a network drive etc. My backup solution (backuppc/other syncs + zfs + sanoid/syncoid plus offsite server with zfs) means the backup server pulls files from the clients using backuppc/rsync. The backup server volume is zfs snapshoted regularly using sanoid. The offsite server pulls these from the backup…

Yes this. I use Borg via ssh to an off-site server. With the proper ssh config (force-command, no pty, no forwarding etc) you can lock it down pretty well, especially since you can add an "append only" switch to the serve command that will refuse any modifications or deletions to existing snapshots.

Re: A tale of Phobos – How we almost cracked a ransomware using CUDA

#53

Post by iforgotpassword »

msm_ wrote: post #3
rfoo wrote: post #2

Overall, cool work! Especially the search space reduction part. I haven't dive into the code, but only 818000/60=13633 attempts per second for 64 SHA-256 rounds plus one AES-256 decryption on a 2080 doesn't sound right. Learn some GPU and tuning the code can likely increase the throughput a lot. Mind you, that's only 25x naive Python implementation on (supposedly) 1 core. Also, hashcat does >1M hash/s for even higher…

Thanks! I wonder if the Python number is correct, I remember Python being prohibitively slow in comparison. But assuming it is: There are 256 sha256 iterations on average, so the number is a bit better - but there's probably still a lot to improve (it's much more optimised than the naive version, but it was written by reverse-engineers, not GPGPU specialists). The PoC was also opensourced [0], it would be great if so…

I can't offer "four orders of magnitude", but "four" ;-)

PIDs on windows are always a multiple of four.

(I didn't see that mentioned in the blog post, but didn't check the code so maybe that's already in there.)

Edit: nvm I guess that's why it says 2^30 not 2^32...

Re: A tale of Phobos – How we almost cracked a ransomware using CUDA

#54

Post by PUSH_AX »

ganoushoreilly wrote: post #51
zitterbewegung wrote: post #45

I think this would be a stupid idea but you can buy an Antminer for $2458 and it does 104 TH/S for SHA256. I think doing a bit of hacking to make it crack the ransomware might be feasible?

There have been tons of projects that tried to repurpose bitcoin hardware. Even if it's not the latest that's a lot of computational power! So far though none of the project I follow have yielded any real results. Here's a interesting read that gives a bit of info on the differences and why it doesn't really work. https://rya.nc/asic-cracking.html

Interesting, I wonder if you could (hypothetically) develop some hardware that does the bits the CPU needs to do and essentially have a cracker ASIC? And if it would yield improvements that require a reaction.

Re: A tale of Phobos – How we almost cracked a ransomware using CUDA

#55

Post by semitones »

Tepix wrote: post #7

So, if you're a victim and you don't want to pay ransom - hire an expert to find out the missing data (timestamp, is it the vulnerable version?, ...), then - rent a GPU server and keep the fingers crossed. I've looked for cheap GPU servers yesterday, the cheapest i found was Ultrarender at 200€ per week for a Dual RTX 3080Ti remote workstation. Which is probably overkill, a single RTX 3080Ti can do it in 33 hours or…

coreweave.com has pretty cheap GPUs

Re: A tale of Phobos – How we almost cracked a ransomware using CUDA

#56

Post by ganoushoreilly »

PUSH_AX wrote: post #54
ganoushoreilly wrote: post #51

Earlier quoted context omitted.

There have been tons of projects that tried to repurpose bitcoin hardware. Even if it's not the latest that's a lot of computational power! So far though none of the project I follow have yielded any real results. Here's a interesting read that gives a bit of info on the differences and why it doesn't really work. https://rya.nc/asic-cracking.html

Interesting, I wonder if you could (hypothetically) develop some hardware that does the bits the CPU needs to do and essentially have a cracker ASIC? And if it would yield improvements that require a reaction.

I'm sure you could build an asic for assistance, but I tend to see more FPGA style tools for these kinds of things given changes / variables that you wouldn't want hardcoded. There have definitely been a few tools built, the article I linked had reference to DES hardware crackers.

Anyone that comes up with a way to repurpose all those bitcoin miners into something productive will be pretty cool in my book.

Re: A tale of Phobos – How we almost cracked a ransomware using CUDA

#58

Post by aaron695 »

zht wrote: post #39
comboy wrote: post #12

I know I'm in minority and that this view is not empathetic one, but I really like that ransomware is around. More secure data storage at companies where otherwise it would be just silently stolen and sold. More backups. Even some incentive to research security of encryption methods. We won't get more secure systems without some proper incentives.

This is like saying it’s a good thing that burglars exist so it forces us to invest in stronger locks/doors

[dead]

Re: A tale of Phobos – How we almost cracked a ransomware using CUDA

#59

Post by ryan-c »

ganoushoreilly wrote: post #51
zitterbewegung wrote: post #45

I think this would be a stupid idea but you can buy an Antminer for $2458 and it does 104 TH/S for SHA256. I think doing a bit of hacking to make it crack the ransomware might be feasible?

There have been tons of projects that tried to repurpose bitcoin hardware. Even if it's not the latest that's a lot of computational power! So far though none of the project I follow have yielded any real results. Here's a interesting read that gives a bit of info on the differences and why it doesn't really work. https://rya.nc/asic-cracking.html

I'm glad people are still finding that post useful.

Re: A tale of Phobos – How we almost cracked a ransomware using CUDA

#60

Post by Too »

TacticalCoder wrote: post #27
heywhatupboys wrote: post #17

Earlier quoted context omitted.

don't backup file names. Backup checksums.

I agree. And for some stuff you get cryptographic checksums for free. Backup of Git repositiories: ... # git fsck --full error: unable to unpack contents of .git/objects/a2/cf1a9631658799733f43c3b3f0a799696a4b21 error: a2cf1a9631658799733f43c3b3f0a799696a4b21: object corrupt or missing: .git/objects/a2/cf1a9631658799733f43c3b3f0a799696a4b21 Oops... No matter if it's a malware, the lack of ECC which by bad luck induce…

People normally say don’t store binaries in git. Is this a big issue if the files don’t change very often? From what I understood the biggest problem is they don’t diff well. With photos not changing very often, can it work?

Anyone tried using git for 500G of photos?

I would love to if it worked, I have my photo collection spread out on multiple computers and merging the edits to the master backup is always a pita. “Was this file removed from copy A or added to copy B”? All those problems just solve themselves with a clear DVCS git history.

Not having the possibility of ever removing photos, to free up space, is of course another issue of git.

Post reply on HN