<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">Thanks for your inputs, Eric. <br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">What I am trying to do is in essence part of dynamic slicing of distributed programs. I wanted to find all </div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">the network I/O related function calls in the user program in order to instrument for identifying inter-process (communication) dependencies, which are important parts of a distributed program slice.</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">I think the sniffers can help with network traffic monitoring or so in a standalone manner, but for my task, intercepting the network I/Os <i>programmatically</i> would be desired. I guess something similar to the instrumentation I want has been done by the sniffers inside, yet there is no source code available to refer to regarding how exactly they realized the sniffer functionalities. </div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">Although an alternative way would be modifying system calls related to network I/Os at OS level, or changing relevant APIs in JRE assuming that any network libraries the application program uses eventually resort to the JRE APIs, these approaches seem to be overly heavyweight. </div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">Also, I am wondering about the state of art/practice of source-code analysis dealing with interprocess dependencies in distributed systems.</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">Best,</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 11, 2015 at 2:50 AM, Bodden, Eric <span dir="ltr"><<a href="mailto:eric.bodden@sit.fraunhofer.de" target="_blank">eric.bodden@sit.fraunhofer.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Haipeng.<br>
<br>
It really depends on exactly what you want to analyze but of course there are network sniffers like wireshark that might be simpler to use in such a scenario.<br>
<br>
Cheers,<br>
Eric<br>
<div><div class="h5"><br>
<br>
> On 10.02.2015, at 22:20, Haipeng Cai <<a href="mailto:hcai@nd.edu">hcai@nd.edu</a>> wrote:<br>
><br>
> Hi all,<br>
><br>
> To help identify inter-process dependencies in distributed programs, I am attempting a Jimple-level instrumentation that inserts probes after all function calls related to all network I/Os. In the simplest case, I could just identify all calls of socket.getInput/OutputStream as such instrumentation points, yet that would not give me a complete set of such points.<br>
><br>
> Is there a better approach to completely (for a 100% recall) instrumenting such interceptions through static analysis? Or, as a compromise, is there some alternative (even dynamic-analysis) approaches to capture all network I/O related function calls?<br>
><br>
> I am also wondering if there exists any relevant utilities in the latest version of Soot or its derivatives (FlowDroid, heros, etc.) that could help with this task.<br>
><br>
> Any thoughts and clues are appreciated.<br>
><br>
> Thanks.<br>
> Haipeng Cai<br>
> _______________________________________________<br>
> Soot-list mailing list<br>
> <a href="mailto:Soot-list@CS.McGill.CA">Soot-list@CS.McGill.CA</a><br>
> <a href="https://mailman.CS.McGill.CA/mailman/listinfo/soot-list" target="_blank">https://mailman.CS.McGill.CA/mailman/listinfo/soot-list</a><br>
> _______________________________________________<br>
> Soot-list mailing list<br>
> <a href="mailto:Soot-list@CS.McGill.CA">Soot-list@CS.McGill.CA</a><br>
> <a href="https://mailman.CS.McGill.CA/mailman/listinfo/soot-list" target="_blank">https://mailman.CS.McGill.CA/mailman/listinfo/soot-list</a><br>
<br>
</div></div>--<br>
Prof. Eric Bodden, Ph.D., <a href="http://sse.ec-spride.de/" target="_blank">http://sse.ec-spride.de/</a> <a href="http://bodden.de/" target="_blank">http://bodden.de/</a><br>
Head of Secure Software Engineering at Fraunhofer SIT, TU Darmstadt and EC SPRIDE<br>
Tel: <a href="tel:%2B49%206151%2016-75422" value="+4961511675422">+49 6151 16-75422</a> Fax: <a href="tel:%2B49%206151%20869-127" value="+496151869127">+49 6151 869-127</a><br>
Room B5.11, Fraunhofer SIT, Rheinstraße 75, 64295 Darmstadt<br>
<br>
</blockquote></div><br></div>