Rough hardware estimate
| Hardware | Count | Hardware | Count |
|---|---|---|---|
| 2080 TI | 2 | 1070 | 25 |
| 1080 TI | 22 | 1060 | 6 |
| 1080 | 15 | 970 | 2 |
| 1070 TI: | 7 | CPU Physical Core: | 892 |
Software used
- John the ripper + MPI
- Passcovery Suite
- Hashcat
- Bcval
- Hashtopolis
This year we had 15 members compete, we welcome 0xln, golem445, and John_Smith to the team. Tremendous thank you to Korelogic for hosting the 8th Defcon Crack Me If You Can, it was a blast this year as it contained interactive elements involving a dynamic workflow. This is quite different from what we expected and was welcomed with open arms.
After seeing that the test hashes contained usernames which involved matching, we suspected that pairing up different hashes and passwords with similar usernames was going to be needed this year. Prior to the contest, we developed a matching utility that would handle this operation for us. The pair tool was used throughout the contest to generate scrypt Hash:potential-pass pairs for us to run using single-mode style attacks.
We here able to get quite high completion rates on the “easy” hashes.
What is Bcval
Our Bcrypt Validator (Bcval for short) was originally created for the Ashley Madison project Cynosure Prime worked on back in 2015. It is an optimized single-mode cracker designed to work with hash:[potential]password pair and supports rules and case twiddling. This was quickly adapted to support scrypt during the contest.
While our team initially used john to attack the scrypt hashes, once Bcval was available we switched across as we noticed it was quicker in the workloads we benchmarked. The performance increase highlighted with the vertical red line can be seen in the contest performance graphs.
We are unable to directly produce a Bcval vs John comparison as we are running into a strange issue when using --single=none. It appears john is still using some sort of rules or is testing extra candidates (note this could be due to a PEBCAK error). On a Ryzen 2700x Bcval was running at about 240 h/s. However when running two identical hashlists john appears to run for quite some time even though it was reporting 220+ h/s.
It is unclear why we see such a discrepancy between the performance of the two tools as they are using the same hashing code. We believe this is due to the way we handle the hashes, this includes the ability to terminate jobs when a cracked hash is found as well as using a different threading model. Bcval does not use OpenMP nor is it using the ROM optimizations for the scrypt algorithm. As an afterthought to the contest, a rule candidate cache would have added nice gains for certain rules. The rule cache would effectively temporarily store all generated rule candidates for that single plain and check whether it has been tested, skipping the hash routine where applicable. Considering the slow speed of the hashing algorithm, the processing cost to store candidates and performing lookups would be negligible but would provide huge benefits.
As we had a pairing tool, this was used to crack the password changes. Pair-ception was carried out with the cracked passes along with the accounts affected. The cracked user:scrypt:plains were paired with user:[new]scrypt to provide user:[new]scrypt:[potential]plain which was then cracked by using simple rulesets such as best64 in single mode with Bcval.
While we did notice the avatar, WOLF, core and other hashsets we were not able to properly figure out the patterns for them. It appeared we were trying more complicated things than needed.
Early on, we ran into an issue where the system did not like empty hashes (we found several hashes that had blank plains), this was quickly rectified by korelogic. Due to focussing on cracking the hashes we decided not to recode our system to re-validate hashes on our end prior to submitting them and did run into a couple of submission mistakes where we accidentally submitted bad hashes.
Our team generally prefers the whatever approach, as any member can work on whatever hashlist or task they want. However, for this particular competition due to the added layer of hash pairing and password changes, some team co-ordination would have helped, especially when we had members who were only able to join in mid-way.
It was interesting to see the use of single mode password attacks and we were lucky to be familiar with this approach. It was very refreshing to see a dynamic element added to a traditional hashing cracking contest with the pairing and password changes.
Congratulations to Team Hashcat for bringing their A-Game and a massive thanks to Korelogic for organising Crack me if you can 2019.
