Wireshark · Wireshark-dev: Re: [Wireshark-dev] Wireshark-dev Digest, Vol 136, Issue 4

[Sadik Sikder <sadiksikder@xxxxxxxxx>]

Thanks Mr. Peter for you kind help and cooperation...

i have figured-out how should i write my own decryption function . i have some confusion or problem to understand... i am giving a example what i would like to know.

in epan/packet-ssl.c file,  i have a seen a method called:

void

ssl_load_keyfile(const gchar *ssl_keylog_filename, FILE **keylog_file,

                 const ssl_master_key_map_t *mk_map)

or 

void

ssl_debug_printf(const gchar* fmt, ...)

{

    va_list ap;

    if (!ssl_debug_file)

        return;

    va_start(ap, fmt);

    vfprintf(ssl_debug_file, fmt, ap);

    va_end(ap);

}

here ssl_load_keyfile or ssl_debug_print() are  methods. i havenot found where these method are called into main function. similar this problem i have faced several situations. In order to overcome the situation what should i follow? how can i or which file/folder contains main functions regarding epan/packet-ssl.c, epan/packet-ssl-utils.c?

i have used Eclipse IDE to track of these methods to figure-out main function  but i was unable to find the main functions regarding  packet-ssl.c, packet-ssl-utils.c and packet-ssl-utils.h.

Thanks in advance :)

Kind Regards,

Samsuddin Sikder
Masters Student 
M.Sc. in Communication Systems Engineering

Cologne University of Applied Sciences (FH-Köln),Germany 

On Tue, Sep 5, 2017 at 2:00 PM, <wireshark-dev-request@xxxxxxxxxxxxx> wrote:

Send Wireshark-dev mailing list submissions to
        wireshark-dev@xxxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.wireshark.org/mailman/listinfo/wireshark-dev
or, via email, send a message with subject or body 'help' to
        wireshark-dev-request@wireshark.org

You can reach the person managing the list at
        wireshark-dev-owner@wireshark.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Wireshark-dev digest..."


Today's Topics:

   1. Re: [RFC] Vendor-specific dissector extension for EtherNet/IP
      (Michael Mann)
   2. Re: decryption SSL (Peter Wu)


----------------------------------------------------------------------

Message: 1
Date: Mon, 4 Sep 2017 14:26:48 -0400
From: Michael Mann <mmann78@xxxxxxxxxxxx>
To: groot.samuel@xxxxxxxxx, wireshark-dev@xxxxxxxxxxxxx
Subject: Re: [Wireshark-dev] [RFC] Vendor-specific dissector extension
        for EtherNet/IP
Message-ID: <15e4e251bae-c04-b17@webjasstg-vab39.srv.aolmail.net>
Content-Type: text/plain; charset="utf-8"



Hopefully inlining comments will work...


-----Original Message-----
From: Samuel GROOT <groot.samuel@xxxxxxxxx>
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Cc: Michael Mann <mmann78@xxxxxxxxxxxx>
Sent: Thu, Aug 31, 2017 8:58 am
Subject: Re: [Wireshark-dev] [RFC] Vendor-specific dissector extension for EtherNet/IP

Hi,

I was already looking at CCO and the heuristic function when I received
your last email.
After some reading of the C dissector and some tests I arrived at the
same conclusions, I will see now what I will implement, and how.

> In the CIP specs, they focus on <identifier> being an object class and
> instance, but
> for some Rockwell PLCs, the <identifier> is just a string (and there is
> no class in the message).
> That's what I mean when I refer to "classless" requests.

I never encountered this case but indeed this notion of segment is
present in the CIP documentation, I didn't read it enough!



I believe the only time you will encounter this is with Rockwell PLCs and its use is starting to go towards "legacy"
status (not deprecated I'm guessing just because of backwards compatibility), so I wouldn't worry about it too much.



>  >> 2. If you want to add vendor specific services to already supported
>  >> objects, that would be more difficult to do in Lua because there isn't a
>  >> dissector table hook for them.  I'm not sure there would be a way to
>  >> handle the "general" case of registering service + class into a
>  >> dissector table, but you could add dissector tables (patching
>  >> packet-cip.c) for specific objects (Identity, ConnectionManager, etc)
>  >> and submit just that part as a patch for inclusion in base Wireshark
> code.
> This is where I started to steer you incorrectly.  The heuristic
> functionality should
> be able to handle this case without issue.

I think in this case it would be the dissector, since the heuristic only
triggers for common services (and we want to support vendor-specific
services for common objects).


I believe what you want is:
1. A dissector for each vendor specific object
2. A (single) heuristic dissector for all vendor specific objects that use common services.
I thought I could simplify the existing CIP dissector and only use one heuristic dissector (and just use a switch
statement for the object IDs), but the "built in" objects have a way to list their attributes so they can be dissected
by the common service dissection routines (GAA, GAS, GAL, etc).  I think part of the reason I never added an
"external" interface for the attribute lists was I wasn't sure how to make it generic enough to fit into existing
Wireshark APIs.
Your 1 heuristic dissection function should look like dissect_class_cco_heur(), but have a switch statement for
calling each of the object classes after you've parsed the EPATH for a request.  A "response" should be handled
exactly like the CCO object (but I'm not sure how all of that would translate to Lua, trying to directly access a
C structure from p_get_proto_data)



> I think the intent of the cip.data_segment.iface dissector table was to
> handle the "string"
> identifiers I mentioned with the Rockwell PLCs.  It's probably something
> that should actually
> be removed from the dissector.

It makes sense. Why remove it though, since it can be used to support
"classless" services?



Architecturally it seems simpler to have a heuristic function that registers with "cip.sc" table and dissects the EPATH
for the "classless" services to determine if they are truly "classless".  Again, the only ones that use this is Rockwell
PLCs and because the information isn't in the CIP specs, I consider it proprietary, much like vendor-specific objects.


>  >> 4. I believe Lua will "override" any value registered to a dissector
>  >> table, so you could write the "vendor specific" portion, for say the
>  >> Identity object, but then you'd have to duplicate all of the dissection
>  >> currently being done for it in your Lua script.
>  > I did test with setting a lua dissector for Identity in the
> cip.class.iface, and on packets
>  > with common services it wasn't triggered (I didn't have packets with
> vendor-specific
>  > services call for Identity).  So apparently it does not override the
> default dissector
>  > with the lua one (at least with a common service).
> Again, this issue can be handled with the heuristic dissection mentioned
> above.

True in this case.


So to clarify I could now cover the following cases:
- Vendor-specific class, vendor-specific services with a dissector (one
per class)
- Vendor-specific class, common services with a heuristic (to handle the
epath and attributes)
- Common class, vendor-specific services with a dissector (again, one
per class)

An implementation in lua seems extremely tedious, since I will have to
re-write most of the dissection code already present in C (status,
epath, and attribute-related services).



I hope you can simplify some of the dissection with the single heuristic function and a switch statement.
But yes, you would have to rewrite (copy/paste) the value_strings used in the dissector.
There is also the option of writing a C plugin (which I've done before and I know others have), but that is
typically tied to a Wireshark release version (because APIs aren't guaranteed to stay the same between
major releases)
In general, I would discourage adding vendor specific object code to the Wireshark source base because
of the high probability of collision (with another vendor's objects).  Unless you're one of the large PLC
manufacturers, you probably only have a handful of objects, and like most vendors you probably started
at the bottom with 0x7F.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.wireshark.org/lists/wireshark-dev/attachments/20170904/3e4587e6/attachment.html>

------------------------------

Message: 2
Date: Mon, 4 Sep 2017 23:05:14 +0100
From: Peter Wu <peter@xxxxxxxxxxxxx>
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Subject: Re: [Wireshark-dev] decryption SSL
Message-ID: <20170904220514.GA5060@al>
Content-Type: text/plain; charset=us-ascii

Hi Sikder,

On Mon, Sep 04, 2017 at 12:48:30PM +0200, Sadik Sikder wrote:
> could you tell me that which part of code decrypts using pre-master
> key log

Have a look at epan/dissectors/packet-ssl.c and
epan/dissectors/packet-ssl-utils.c. For the involved data structures,
see epan/dissectors/packet-ssl-utils.h

The program flow in the common case (SSLv3/TLS) is as follows:

 1. dissect_ssl is the entrypoint (commonly called from TCP dissector).
 2. dissect_ssl3_record is called for each record.
 3. ...which will read the record content type and call functions to
    parse messages including handshake, alerts and application data.
    If data was previously decrypted, that will be reused. Otherwise, an
    record decryption is attempted.
 4. The resulting (decrypted) buffer is given to
    "dissect_ssl3_handshake", "dissect_ssl_payload", etc.

In step 1, a "SslSession" structure is retrieved or created, this stores
information about the current association (connection) like the version
number in use. There is also a "SslDecryptSession" structure which is
created on the first pass(*1) and contains the state necessary to
perform decryption.

 *1) Wireshark can be invoked multiple times for a packet. The first
     time it linearly goes through all packets and performs decryption
     if enough data is available. It may be called again after that to
     fill in columns, or the packet details list (when you select a
     different packet in the GUI).

Decryption requires the cipher to be configured. Trace the use of
SslDecryptSession in the packet-ssl.c and packet-ssl-utils.c files to
find its uses. The "state" field will likely be very helpful. As you may
know, key calculation (https://tools.ietf.org/html/rfc5246#section-6.3)
requires a master secret, a server random and a client random.

In the following sections I will try to describe the process involving
the parameters, the master secret and actual record decryption.

(About Client Random, SSL/TLS Version, Cipher Suite, etc.)
The client and server random values are collected in
"ssl_dissect_hnd_hello_common" (simply follow their call chain to see
how it is invoked). It looks like this:

    ssl_dissect_hnd_hello_common(..., SslDecryptSession *ssl, ...)
    {
        ...
            rnd = &ssl->client_random;
        ...
        tvb_memcpy(tvb, rnd->data, offset, 32);
        ...
            ssl->state |= SSL_CLIENT_RANDOM;

This pattern of saving information during dissection and setting a flag
is used to ensure that all data is available before the decoder
(decryptor) is created.

(About Master Secret)
For RSA cipher suites, the captured Encrypted Premaster Secret can be
decrypted using the RSA private key (see "ssl_decrypt_pre_master_secret"
as used by "ssl_generate_pre_master_secret").

For cipher suites based on a DH key exchange, the captured
ClientKeyExchange and ServerKeyExchange messages are of no use since the
private (typically ephemeral) values are not known. That is why you have
the "keylog file" method which simply maps the Client Random value to
the master secret.

Parsing the keylog file is not that interesting (done by
"ssl_load_keyfile"), but note that it is attempted while parsing the
ChangeCipherSpec message. The motivation is that by now all parameters
(cipher suite, TLS version, Client Random, etc.) should now known and
written to the file. Following this, "ssl_finalize_decryption" is called
in order to try to build a decoder (remember that messages may be
missing in a pcap or that the key may simply be unavailable).

If all parameters are available, "ssl_generate_keyring_material" can
start the real work. It calculates the (pre)master secrets, and then
creates the bidirectional decoders using "ssl_create_decoder".

(Record decryption)
Now that the cipher is setup (the most difficult part I think), it is
time to look at what "decrypt_ssl3_record" does. That function basically
calls "ssl_decrypt_record" to do all the work. To understand function it
is critical that you know about the three encryption types (CBC block
mode, stream encryption and AEAD) as described in
https://tools.ietf.org/html/rfc5246#section-6.2.3

You should read that RFC section in order to navigate this
"ssl_decrypt_record" function. The code has additional references to
RFCs.

I have skipped over details like record compression, fragmentation,
session resumption, extended master secret, export ciphers, TLS 1.3 and
many other things that affect decryption, but hope that this
introduction will be helpful.

Note that the described structure reflects the current implementation as
of Wireshark 2.4. It might not be the best implementation, but should
give you ideas how to write your own one.
--
Kind regards,
Peter Wu
https://lekensteyn.nl


------------------------------

Subject: Digest Footer

_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
https://www.wireshark.org/mailman/listinfo/wireshark-dev


------------------------------

End of Wireshark-dev Digest, Vol 136, Issue 4
*********************************************