Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [day] [month] [year] [list]
Date: Tue, 29 Jan 2013 12:34:37 -0600
From: "jfoug" <jfoug@....net>
To: "'Dhiru Kholia'" <dhiru.kholia@...il.com>,
	<john-dev@...ts.openwall.com>
Subject: RE: [john-users] can't get jtr to ID this

Here is the C code. This 'should' work.  I would have rather kept it in c++,
but I can live with this.

Also, like I said, this is NOT really prime time ready.  Yes, I have gotten
this to work, but I am not 100% sure it is right for all cases. There may be
cases where there is a valid handshake, that can be converted into a JtR
hash, but this program fails to find it.  I believe that this would be the
case for a msg1/4 and msg3/4 pair.  But in that case, I am not fully sure if
I can make the eapol object.  Currently, the eapol object is the
Authentication object of the msg2 (in original format, i.e. no swapping),
and with the MIC zero'd out.   To recreated that with a 1/4 or 3/4 pair, I
would need to figure out what to do.  What I need to do, is to capture some
FULL 4 packet 4way handshakes.  That way, I can see just what is in the 4
packet, compared to the 2 packet.

At this time, I get the SSID from the beacon, the MAC's from the msg1/2 or
msg2/3 packets nonc2 from packet 1 or 3 (they are the same).  All other data
comes from packet 2.

Here are the issues that I am aware of:

1. It may not be able to use all 'valid' handshakes.  We do handle 1/2 and
2/3 if they are matched.  NOTE, the timestamp should also be used when
making a match (it currently is not). this should not IRL be that big of an
issue.

2. it should be made smarter, take the last handshake in the file (the cap
file may be built over days, weeks or months).

3. the current program will simply output all valid 4way parts, even if they
are multiples and the same.

4. it should handle pcap files, and iv files, and tigershark files (or
others).

5. it does swapping 'smartly' of the pcap header. However, it is NOT doing
smart swapping of the Authentication packet.  The smart swapping, in the
pcap is based upon the magic.  If the magic is 0xD4C3B2A1, then the header
needs to be swapped.  It does not matter if your computer is BE or LE.  It
simply shows that the capture session was obtained from a machine that had
different endianity than the machine we are now running on.  The swapping
that happens when processing the Authentication packet (around line 180),
should be done ONLY on LE systems, since the data is in BE format.

6. it should probably be able to handle *.cap  Right now, it only handles
one.

7. it needs a lot more testing, (probably does not work right), when there
are multiple clients connected to an AP, and they are all handshaking.

8. it should have code added to auto-detect a client that does not have the
proper password. This is seen by multiple 1/2.  There is NO way to determine
whether a client has the right password or not, other than to heuristically
watch the communications.   If there are a battery of msg1/msg2, with no
msg3/4 in there, between a client and AP, and then the AP deauths later,
then it is very likely that the client does not have the proper password,
and thus ALL 4-ways seen during that session should be ignored.  This would
be seen at run time from this tool, by quite a few of the 1/2 types in a
row.  That is IF airdump-ng continues to capture the 4ways after it things
it has one of them.

Jim.

-----Original Message-----
From: Dhiru Kholia [mailto:dhiru.kholia@...il.com] 
Sent: Tuesday, January 29, 2013 9:44
To: jfoug@....net
Subject: Re: [john-users] can't get jtr to ID this

On Tue, Jan 29, 2013 at 8:28 PM,  <jfoug@....net> wrote:
> ---- Dhiru Kholia <dhiru.kholia@...il.com> wrote:
>> :-(. I wrote a similar patch few days back.
>
> I believe your code also has bugs when building the hash file, building
invalid hashes. It appears you cut the code (along with bugs) from aircrack.
I will get some cap file built that displays this problem.

I did not write it. I just patched an existing program.

> Ok, I have include 2 .cap files. They are from the same session. The
DeJong-1.cap is filtered to contain the beacon, and all eapol packets.  The
'correct' 4way, is the msg2/msg3 pair.  The DeJong-1a.cap is the beacon, and
just the msg2/msg3 pair, all other eapol have been removed.

I have added these files to the wiki
(http://openwall.info/wiki/john/sample-non-hashes).

> I have included the source I have written.  NOTE, it may not have 'all'
ways of producing a correct hash.  But so far, all situations I have thrown
at it HAVE found valid results.

Awesome! I have done a quick port to C and committed it to bleeding-jumbo.
It will receive more testing this way (including from me). Can you please
check if I have made any mistakes in porting stuff?

--
Dhiru

View attachment "wpapcap2john.c" of type "text/plain" (12197 bytes)

View attachment "wpapcap2john.h" of type "text/plain" (6977 bytes)

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ