Dissector "atexit" functionality

[magnumripper]

I'm working with enhancements to the o5logon dissector. It collects various packets where some of the data is optional so might not be seen at all (eg. stealth scans against Oracle 11G) but is mandatory if present (eg. Oracle 12G auth). In that case, I need to print the partial data we did collect. I guess I can add trivial logic to detect a TCP tear-down and implement it for that case.

However, I'd also want some kind of "catch EOF" functionality (callback, macro, whatever) so any remaining sessions [that have enough data] can be printed on EOF or end-of-sniff - a bit like atexit() if you wish. That'd also mean a need for something like dissect_getnext() to iterate over the sessions that remains.

Or put another way: I have this function:

FUNC_DECODER(dissector_o5logon)
{
      (...)
      dissect_create_session(&s, PACKET, DISSECT_CODE(dissector_o5logon));
      (...)
      if (condition) {
          (...)
          dissect_wipe_session(PACKET, DISSECT_CODE(dissector_o5logon));
      }
}

I reckon I'd need something like this too:

FUNC_DECODER_EOF(dissector_o5logon)
{
      /* iterate through remaining sessions and process them */
      while (dissect_get_next_session(&s)) {
          (...)
          dissect_wipe_session_from_ptr(&s);
      }
}

Is this possible to achieve somehow already in some other way?

[eaescob]

Just trying to understand, what would trigger this EOF?

[magnumripper]

Reading a pcap and getting EOF, or sniffing and quitting.

This particular dissector (and others I'm pretty sure) collects data and tries to get more but if "end of data" is reached, it can and will during some cirumstances output a bit more data from sessions that were "hoping" to get more but that do have useful data already.

[eaescob]

Ah, I don't think that's the way it works now but it might be a good thing to add. Do you have a pcap I can work with? I'll pull your dissector and check

[magnumripper]

The current version of my dissector (#742) sometimes output the "short" version because it doesn't know whether we'll get more or not. So sometimes it outputs a "short" and a "long" line for the same session. With this functionality it wouldn't. See comment at line 125.

[eaescob]

I get your request, the one issue I see is that decoders are called sequentially. So the thing I have to think of is how to make it so that even the decoding library knows it's at EOF and it has to call each EOF decoder functions.

[eaescob]

Do you have any pcaps I can use to test this? Particularly the case where sessions are found after EOF?

[magnumripper]

There are such cases in the already linked samples but I'll try to create isolated test cases for you.

[magnumripper]

(From #842)

For example, it could be used in WPA sniffing as well. It goes like this: WPA handshakes are four way, let's call them M1..M4.

If you get M1 and M2 you have enough data to crack whatever password the client used to authenticate with the AP (correct or not). If you also get M3, you also know that it was a correct password that the AP accepted. So we could build a dissector that records M1, M2 and M3 packets. As soon as we see an M3 packet, we output a crackable hash. But when the sniff ends (end of sniff, end of pcap, end of file) you may still have some M1/M2 that never got a M3. They are never printed, unless the suggested new stuff could be used to iterate through them before quitting and output them too (with a note that they may not be correct passwords).