I use Fiddler a lot (especially the composer and reverse proxy features) in web debugging. I am able to successfully send traffic to my reverseproxy server ("myreverseproxy:8888"). This is basically using custom rules explained here, and it works with most cases.
However I tried to redirect traffic similar with one of the third party DLLs. These are native code, so can't decompile to see what's happening. Basically I don't have a source - but it connects to a host on a specified port - I wanted to observe the packets to take a closer look at headers, packets, authentication etc.
But in this particular case reverse proxy is not working. Probably the third party DLL is not using http stack.
My questions:
Is there anything I can do in this particular case to understand how this external native assembly is connecting to the server? or Fiddler can't be used as it probably can't intercept this traffic?
if that is the case, what other tools I can use to intercept the traffic?
Update
Here are the things I observed:
- From client side, Fiddler is unable to capture packets (probably the api's Fiddler use at higher level)
- Then I setup reverse proxy, to make sure I catch the traffic at 'rever proxy server' - however Fiddler still could catch the traffic. Thanks to Lex - looks like fiddler won't even show the packet if it can't decode payload as http (not too sure - but it's my conjecture from Lex's response and other posts)
- Then I have installed Wireshark, captured the packets, and by default 'wireshark' showed the interactions between client and server as TLSv1 - so it confirms why fiddler couldn't catch
- Just to confirm I applied HTTP decoder to see if 'default decoder' assigned by Wireshark is wrong - but, it couldn't decode details.
So, it confirms the native module is using TLSv1, not https and that explains why I can't use Fiddler.
