How and why we defeated DirCrypt | Hacker News Reader

How and why we defeated DirCrypt

checkpoint.com

62 pointsnitayart12 comments

A good way to fight back against ransomware would be to spread false stories in the mainstream media about people who paid the ransom but then didn't get their files back, or their files were corrupted beyond repair, etc.

If both victim and perpetrator are aware of the media stories, it will become more difficult to get them to pay up, making the scam less lucrative.

that's stooping pretty low

So is creating ransomware.

Yes, but the "good guys" aren't supposed to harm innocents, even if it does help in the long term. Well, maybe. But it doesn't feel good at least.

After reading about ransomware, I adopted the following approach to backing up my files, which I call a "pull" system. I run my backups from an old Linux box that isn't write-accessible on the network, but that can read files from the Windows computers onto the backup disks.

My backup method is slow -- just a bulk transfer of files -- but I've made no effort to refine it yet.

I also wonder: If you plug your backup drive into a Linux box, you'd see if the files were encrypted, right?

sure. but too late.

You may wish to do multiple backups, because otherwise something like this could overwrite your backup when you pull data if you didn't notice it.

If you do incremental / semi-incremental backups, or use a file system with deduplication, your space requirements don't increase that much.

I wonder if that RSA happens to be very weak too, as evidenced here: http://blog.cassidiancybersecurity.com/post/2014/02/Bitcrypt...

In some ways a lot of the crypto used by ransomware might just be "for show" - to mung files only enough to cause people to pay, as that's the ultimate goal.

It's an optimization: if they do it really fast then they can scare you harder because you lose more files.

After all, to a regular end-user bad crypto is indistinguishable from good crypto (and to plenty of programmers too).

In general, I would agree, but wouldn't you be using the slow public key crypto only once to encrypt a symmetric key you've previously generated to destroy the files?

I would assume that symmetric encryption still is more than fast enough to be scary, especially with current CPUs and native AES support.

I would think this is more laziness/incompetence of the developer than an optimisation (even more so as in the OP's article, the file were properly(-ish - I would have used AES over RC4) encrypted, but the symmetric key was attached to the file).

I don't see a listing of the RSA encryption function, but encrypting 1024 bytes with RSA requires an 8192 bit RSA key, which would take a while to generate. Normally, one generates a random symmetric key, encrypts that with RSA and uses that key to encrypt the file. If the malware was doing that, why not just do it on the whole file? It wouldn't be any slower. They may have hard-coded an 8192 bit RSA public key, or they may have some stupid weak RSA key generation scheme.

Great look into the reversing techniques.

Albeit "defeated" is a strong word considering the RSA encryption is still intact - and thus only able to decrypt files larger than, and in range starting from, 1024 bytes.

It recovers potentially large portions, but if your file format can not function without a working header, you're out of luck.

Reply on news.ycombinator.com