Search the Community

After 3 months of work I've released version 0.1 of Abrute. Abrute is a Multi-threaded AES brute force file decryption tool. It has much of the same character sequencer support that the crunch tool does. I've spent a good portion of my development time discovering and implementing sequence algorithms to shave off as many wasted CPU cycles as I can and I feel pretty good about it. The beauty of it is that it works. Now the computers I own only have 4 cores so I'm limited in the amount of processing power to get work loads done. I can say that with a finite amount of cores the workload goes up exponentially as the password length goes up. Also true for the longer a character set is to work with. I so want the new AMD Thread-Ripper with all its cores. My journey started with finding some of my old archived encrypted files and discovering I am unable to remember the password correctly. This led me to look for answers on Security/StackExchange. I went from creating a detailed question, as I was unable to find the answers I was looking for, and got a few small tips pointing me towards the tool known as crunch. I have answered my own question on the forum with many helpful ways I've tried to implement a solution to opening my AES encrypted files. That thread is here: https://security.stackexchange.com/questions/161592/how-to-brute-force-a-somewhat-remembered-aescrypt-password On that thread I first developed a likely word list with shuffling sequences, ordering, and generating plenty of output to test against. That didn't open the file for me but that code has already helped one other person open their encrypted file. Next I learned how to do the equivalent of multi-threading with only using Bash and xargs which will let you spin up parallel processes to run across all your cores. And that works well with crunch. But this was a bit crude as I had to let it run many weeks and could only check the progress by peeking into data being passed through Linux pipes. Not to mention a power outage had me lose a good chunk of progress. So yeah, I wanted to have something better. So I wrote Abrute. I ended up rewriting most of the crunch tool into my own sequencer with my algorithm improvements to save CPU cycles. And the attempts for decrypting are all calls to the aescrypt command for now. But the threading work is handled brilliantly (some one elses library) and at the moment I have Standard Out including progress. Over time I plan to write my own code for decrypting AES files and drop the need for the aescrypt executable. I also want to add GPU support for processing with ArrayFire but I first need to look into how feasible this is. Abrute works well on Mac and Linux and is untested on Windows (it shouldn't take too long to try it out on Windows). The commands are fairly straight forward and detailed in the help you get with -h. You can set the range of characters, character set, limit adjacent same characters, and start point. This uses your CPU cores at 100% so you'll likely need to do this work on a secondary system. I'm playing with the idea of divvying out the work to the cloud. You can rent an Amazon multi-core system for around 64 cores @ $3 to $5 an hour. So I can only imagine the performance gains from splitting the work across so many systems and system cores. Benchmarking is next for my project. I plan to have this program be one of those system benchmarks that everyone compares their computer by . I have some numbers from the original bash/crunch/xargs: At two character passwords I got about 35 passwords tried per second, at 3 character passwords I get about 12 passwords tried per second. At 8 characters with 4 cores a month isn't out of the question. So long passwords would be a long term commitment to try to crack unless you own Amazon or the like . I may never get my files open again. I have a tendency towards longer passwords. But this whole journey has been an amazing learning experience for me allowing me to sharpen many skills and develop many new ones. Anyway I hope you all find this tool useful. I'll get back to you with the newer benchmark numbers when I have them. Feel free to contribute to the project in any way. _I have enough details for you to get it running on a Docker image so cloud is already possible._ I'm just excited about it. Enjoy! ~6ftdan

I've created a payload in C# that appears as a legitimate application but grants an attacker admin remote shell access on a windows system. My primary focus now it to encrypt the network traffic as best as I can for obvious reasons. I haven't done this before so I would like some guidance on how it should be done. I've done some research and come across two methods, AES using RSA to encrypt the key and SSL. I'm worried that the SSL method could easily be attacked with SSL-Strip since there is no HSTS-like implementation to prevent it. I know how to start with AES in C# as the System.Security.Cryptography namespace makes that fairly simple. However, I have no idea how to use RSA to encrypt the AES key and send it over the network. A lot of my research lead me to using AES-HMAC but some of the recent posts I've seen hint toward that only being used for encryption of local information rather than network information. Can someone shed some light on these methods, which is the most secure, and how to use it?