Analysing Syscalls

242 views
Skip to first unread message

Henning Schröder

unread,
Jan 31, 2012, 8:24:06 AM1/31/12
to s2e...@googlegroups.com
Hi,

I'm writing a tool to analyse Linux binaries. I plan to track which
syscalls are made and whether they comply with a certain security policy.
So far I'm using init_env to configure s2e to explore the binary and
plan to use a plugin to monitor every system call.
The plugin is registered to the onException event and checks for the
interrupt 0x80 (as int 80 is the machine instruction for a syscall).
This works so far, but now I have to check the EAX register to see which
syscall is requested and further I need the contents of the other
registers according to the syscall in respect.
For this I call the readRegisterConcrete() method of an
extern s2e::S2EExecutionState *state
like this:
char* buf = new char[2];
memset(buf,0,2);
s2e()->getDebugStream() << atoi(buf) << std::endl;
state->readRegisterConcrete(env, 0, (uint8_t*) buf, sizeof(char));

It doesn't seem to work as the buffer handed to readRegisterConcrete
either stays 0 or is set to 6 or 9. Not the only syscalls to expect, right?
What am I doing wrong?
Is readRegisterConcrete the right one for my needs in the first place?
There are more similar methods in S2EExecutionstate, maybe one of them?

After all, is there a more elegant way to analyse system calls?

I know I still need to check whether the interrupt/syscall concerns me
by looking at the PC value (is it in the process' space?) and so far
syscalls via sysenter are not catched.

Henning

Jonas Wagner

unread,
Feb 3, 2012, 6:46:36 AM2/3/12
to s2e...@googlegroups.com
Hello,

> After all, is there a more elegant way to analyse system calls?

Could you use strace inside the guest? [1] Or if not directly use it,
then at least inspire yourself from its source code to see how it traces
the syscalls...

http://en.wikipedia.org/wiki/Strace

Another way that comes to my mind: If the program is a C program, you
might be able to intercept the syscall stubs from glibc (in a similar
manner as init_env is intercepting main())

The advantage of these two approaches is that you can do some processing
in the guest, which might make it easier to find the information you
need. The disadvantage is that you must do some processing in the guest,
which will slow things down.

As for reading CPU registers... I'm not an expert for this, but you can
find many usage examples of readCpuRegisterConcrete in
qemu/s2e/Plugins/BaseInstructions.cpp

> I know I still need to check whether the interrupt/syscall concerns me
> by looking at the PC value (is it in the process' space?) and so far
> syscalls via sysenter are not catched.

Your S2E plugin could instead register a listener for
onModuleTransition, exported by the ModuleExecutionDetector. That way,
you always know whether you're inside your process' space or not:

> m_executionDetector = (ModuleExecutionDetector*)s2e()->getPlugin("ModuleExecutionDetector");
> assert(m_executionDetector);
> m_executionDetector->onModuleTransition.connect(
> sigc::mem_fun(*this, &YOURPLUGIN::onModuleTransition));

Hope this helps,
Jonas

Jonas Zaddach

unread,
Feb 3, 2012, 8:02:45 AM2/3/12
to s2e...@googlegroups.com
Hi,

I tried to code a system call interceptor as my first plugin. It's not very elegant, but worked on my machine. I'm intercepting system calls done through int 0x80 as well as through sysenter. Syscall is not supported, since S2E is 32 bit only at the moment (guest) and the syscall instruction only exists in 64 bit mode.

Cheers, Jonas





--
You received this message because you are a member of the S2E Developer Forum.
To post to this group, send email to s2e...@googlegroups.com
To unsubscribe from this group, send email to s2e-dev+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/s2e-dev

LinuxSyscallMonitor.cpp
LinuxSyscallMonitor.h
InterruptMonitor.cpp
InterruptMonitor.h
Reply all
Reply to author
Forward
0 new messages