Mallory GUI not intercepting traffic

[Billy]

Hi,

I'm having an issue with the mallory gui (after setting up interfaces
and protocols tabs)

When I set the protocols the fourth column shows "Debuggable" as "no"
for HTTP and HTTPS.

How can I fix this so that "Debuggable" is "Yes" and I can edit the
traffic in the gui?

I'm running the latest mallory code (5/12/2011) on BT5.

Lastly, I know that everything else is working correctly because I can
see the traffic in the command line and the images are being flipped.

Thanks,

-Billy

[ghoultender]

Hello Billy,

There's a bug in the code that determines whether or not to display "Yes" or "No" in the Debuggable column

The file in question is: mallory/src/gui/ProtocolsGui.py

The chunk of code starts at line 179:

          if index.column() == PROTO_DEBUG:
                debuggable = spacing + "No" + spacing
               
                if proto.__class__ == "TcpProtocol":
                    debuggable = spacing + "Yes" + spacing
               
                return debuggable

Line 182 will never evaluate to True, because proto is always a subclass of TcpProtocol. If you change the line as follows:

                if proto.__class__.__bases__[0].__name__ == "TcpProtocol":

...you'll get the output you're look for. I'm not entirely certain this is what the developers intended (still wrapping my head around their code) or if the patch is necessarily the best Python syntax, but it's a start.

gt

[ghoultender]

Follow-up note:

According to a reply in another thread:

If you have the HTTPS protocol running the traffic will not show in
the GUI. Are you sure the rules are set up to have one default "Debug"
rule and no others? It *should* be capturing the HTTPS traffic using
the SSLProtocol. Only TCPProtocol and SSLProtocol can send traffic to
the GUI. All other protocols are essentially Python implementations
that "decode" data and let you manipulate the data in Python. I
recommend editing mallory.py and turning on SSLProtocol on the port of
interest, setting up your default Debug rule and then turning in
"Intercept" and seeing if the traffic shows up.

If it does not, you can drop a sanitized log in here and we can
troubleshoot from there.

The patch I suggested isn't really a fix either, if the above is true in the latest codebase.  Of course, none of the protocols appear as Debuggable, so the bug remains, somewhere.
 

[Matt]

Hi Billy and ghoultender,

I know that the last reaction was the 25th of May, however the application struck my interest and so did the bug Billy mentioned.

It is related to the fact that the comparison is done based on a String-class. 

If my understanding is right, what this check is trying to accomplish is verfying whether or not the used protocol is based on a TcpProtocol, rather than Udp. 

The following changes in ProtocolsGui.py are sufficient to accomplish that:

    from protocol.base import TcpProtocol, UdpProtocol.

   if index.column() == PROTO_DEBUG:

        debuggable = spacing + "No" + spacing

        if instanceof( proto, TcpProtocol ):

             debuggable = spacing + "Yes" spacing

        return debuggable

Regards.