![]() I tried his suggestion in the end, scoped threads, and it made things slower due to the read problem. Because rust’s borrow checker stops you from being a bonehead, it also makes it very hard to share data between threads (I’m not even talking write here). Steve Klabnik has a perfect write up of why here ( ). Threading in rust is hard, if you follow the “Rust by Example” guide ( ) you quickly run into a protracted battle with the borrow checker. So if you head to threading too soon, you’ll either end up with an inefficient hash generator that threading would hide a little, or you end up constrained waiting for the data to be read from the file.Īs I spent a lot of time working on getting the hashing fast first, by the time I got to threading I didn’t have that problem, but I did have the other … simple threading made stuff *slower* because the threads sat around waiting for things to be read and fed to them. The main problem with password cracking is first to write an optimised hash generator, but second to feed it from the wordlist fast enough. Especially for large scale brute forcing like this, we should just be able to parallelise the tasks and get an instant speed up. Multi-threading is an obvious way to speed something up. I’ll start with what made stuff go the fastest not the order I actually built it. In the next section I’m going to go through each of those, in roughly descending order of impact i.e. I’ve commented the code so you can see what I did to speed things up, but it doesn’t really give you what the alternatives are, and which I tried. I’ll get to that … maybe … pull requests welcome. Expects a wordlist with unix line breaks, you can’t specify the number of threads, and doesn’t even let you pipe the wordlist. It reads a list of input hashes to crack from a file, and a wordlist to check the hashes against from stdin. It runs multi threaded on CPU only, no GPU. Ntcrack is a simple rust program, weighing in at around 150 lines of code. So this isn’t a “hashcat bad, me good” post. In fact, the second you throw a simple mutation to brute force an extra ASCII byte ( ?a) on the end of each word ( -a6) in the wordlist, hashcat hits 900+ MH/s, which also thrashes the hashes per second, *and* total running time of ntcrack. For NT hashes and other fast hashes, they have a ton of rules and other manipulations that can be used. They support a bajillion different hashes, and a bajillion different ways to crack them. In terms of total functionality, hashcat thrashes my little project into a little whimpering mess. Hashcat is amazing, not just the tool, the project and the community around it is too. The first response to this sort of work and comparison always seems to be to suggest shifting the goalposts to a different comparison, oft times driven by a belief this is some sort of fight, so let me get all the caveats out of the way. In this post, I’ll go through what I did that worked, and didn’t work to get this result. But even if we look at raw hashes generated per second, when cracking the 143 test hashes against the 1G sized insidepro wordlist, hashcat gets 26 205 kH/s while ntcrack gets 40 207 kH/s. I optimised for total running time, and got some good gains against hashcat by a faster startup. ![]() ![]() (If you’re wondering why there’s no hashcat run for the full rockyou hashes as input, it’s because it takes about 10m with hashcat.) You can get the code at in the ntcrack directory. If you’re only interested in the results, here it is, under a variety of scenarios against hashcat, and you’ll see it ranges from waaay faster to much faster than hashcat. ![]() Instead of figuring out why, I decided to try my hand at writing my own NT hash cracker, because I’m kind of addicted to writing single use tooling in rust then taking time to perf optimise it. But, when it came to actually cracking things, the speed dropped off considerably. The first thing I did was to fire up hashcat which gave an impressive benchmark speed for NT hashes (mode 1000) of around 9 GH/s, a solid doubling of the benchmark speed of my old Intel MacBook Pro. When I got a new MacBook with an M1 Pro chip, I was excited to see the performance benefits. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |