[Soot-list] Instrument for intercepting all network I/Os

[Haipeng Cai]

Thanks for your inputs, Eric.

What I am trying to do is in essence part of dynamic slicing of distributed
programs. I wanted to find all
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.

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
*programmatically* 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.

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.

Also, I am wondering about the state of art/practice of source-code
analysis dealing with interprocess dependencies in distributed systems.

Best,



On Wed, Feb 11, 2015 at 2:50 AM, Bodden, Eric <eric.bodden at sit.fraunhofer.de
> wrote:

> Hi Haipeng.
>
> 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.
>
> Cheers,
> Eric
>
>
> > On 10.02.2015, at 22:20, Haipeng Cai <hcai at nd.edu> wrote:
> >
> > Hi all,
> >
> > 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.
> >
> > 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?
> >
> > 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.
> >
> > Any thoughts and clues are appreciated.
> >
> > Thanks.
> > Haipeng Cai
> > _______________________________________________
> > Soot-list mailing list
> > Soot-list at CS.McGill.CA
> > https://mailman.CS.McGill.CA/mailman/listinfo/soot-list
> > _______________________________________________
> > Soot-list mailing list
> > Soot-list at CS.McGill.CA
> > https://mailman.CS.McGill.CA/mailman/listinfo/soot-list
>
> --
> Prof. Eric Bodden, Ph.D., http://sse.ec-spride.de/ http://bodden.de/
> Head of Secure Software Engineering at Fraunhofer SIT, TU Darmstadt and EC
> SPRIDE
> Tel: +49 6151 16-75422    Fax: +49 6151 869-127
> Room B5.11, Fraunhofer SIT, Rheinstraße 75, 64295 Darmstadt
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.CS.McGill.CA/pipermail/soot-list/attachments/20150211/db222e58/attachment.html