hashcat Forum

I think quite a few people are worried about asking for help testing their WPA protected wifi networks because they are concerned about making the MAC address of the AP and client publicly available.

I understand there is a way for people to find the physical location of the AP using Google or similar.

I wonder if this request may help with this problem ?

Atom, would it be possible for you to make a feature in hashcat-plus or a standalone tool to encrypt the .hccap file ? The idea is this special new feature would allow the user to make their .hccap file as normal but then encrypt it using hashcat-plus so they can then freely distribute it publicly.

People offering to help crack will also have the new version of hashcat-plus (with this feature). They would accept the "secure.hccap" file, decrypt it (automatically and internally within hashcat-plus) and start work cracking it as normal. The helpers have no knowledge of the password to open the .hccap file.

Obviously the feature where the user can see the MAC would be obscured. This way the person who captured the .hccap can feel able to distribute it knowing that people helping cannot ever see the MAC address's. When the password is found only the password is displayed.

The only problem I can think of is if someone could view what was happening in RAM and so see the MACs. However I am not sure how that is possible with GPU RAM so I will hope someone more knowledgeable than me will answer that.

I suppose a further enhancement to this would be that the ESSID is also hidden.

I guess the encryption could be to a hashcat-plus GnuPG public key and the secret key would be within the hashcat-plus binary ?


Thank you.

sounds like useless bloat

if hashcat can decrypt it so can anyone else.

(12-09-2012, 07:24 PM)undeath Wrote: [ -> ]if hashcat can decrypt it so can anyone else.

Thanks undeath.

I understand what you are saying but I hoped someone here would be clever enough to come up with something. I was thnking more about a public / private key. Atom would obviously have the private key and tecnically he would be able to unlock any special .hccaps. However I hoped there would be some solution to alowing hashcat-plus to open it without the normal user being involved or seeing what is within.

I suspect your comment was related to the RAM problem ? Yes a forensic type person, or general computer whizz would probably be able to do such a thing. Is there really no way around that ?

Can't you just use gpg to encrypt it and then share your public key with the ones that need to decrypt it?

(12-09-2012, 11:27 PM)gat3way Wrote: [ -> ]Can't you just use gpg to encrypt it and then share your public key with the ones that need to decrypt it?

Hi gat3way

Thanks for your suggestion but it wouldn't help as the end user ( me ) will see the .hccap file decrypted.

The idea for this feature is that I can help other people decrypt their .hccap files without me ever knowing the MAC address of the AP or the asociated client.

The decryption would have to be done within hashcat-plus itself, without user intervention. The only problem I can think of is that the decrypted MAC address's will be in RAM and I think that is what undeath was meaning.

What i was referring to is that everyone is able to reverse engineer the binary executable and figure out how the file gets decrypted. It's about the same level of security as locking your car and hiding the key behind your tire.

Any work here would be mostly for show, there is no way to secure the data if the program that has the key is publicly available. If there was interest someone would release a decrypter script in a matter of weeks to do it and display this data.

You could require a PSK or something, but at that point people are going to be asking atom to add a mode to attack hashcat's own files.

Your goal is a reasonable one, but I don't see a reasonable generic solution. It's a race not worth running.

undeath and pragmatic

I understand now and thank you both very much for your help.

I didn't realise it was possible to open up the hashcat-plus binary or reverse it so easily.

Its a shame I thought I had a good idea there !

Can anyone smarter than me think of a way round this ?