[panda-users] Problem syscall plugin usage

Simone Mazzoni simone.mazzoni13 at gmail.com
Mon Jan 5 10:28:46 EST 2015


Yes I did.

I think I figured out the error.
There was a typing error in a line of my plugin that make the script not to
create the myplugin.o file.
For that reason,the make process fails to build the plugin and return that
error.
It was a cascade error. Llvm seems to work fine ;)

-Simone

Il giorno lun 5 gen 2015 16:22 Hulin, Patrick - 0559 - MITLL <
Patrick.Hulin at ll.mit.edu> ha scritto:

>  Simone,
>
>  It looks this is an RTTI error. Did you build LLVM with REQUIRES_RTTI=1
> on the make line?
>
>   From: Manolis Stamatogiannakis <mstamat at gmail.com>
> Date: Sunday, January 4, 2015 at 6:57 PM
> To: Simone Mazzoni <simone.mazzoni13 at gmail.com>
> Cc: "panda-users at mit.edu" <panda-users at mit.edu>, Brendan Dolan-Gavitt <
> brendandg at gatech.edu>
>
> Subject: Re: [panda-users] Problem syscall plugin usage
>
>   Hi Simone,
>
>  Do you need all of the plugins which are enabled by default? Maybe you
> should try disabling one/both of the taint plugins and see if it works out
> for you (until the problem is properly fixed).
>
>  Also, doing "LC_ALL=C ./build.sh" should produce messages in English
> which will be easier to understand for us.
>
>  Cheers,
> Manolis
>
>
> 2015-01-04 15:07 GMT+01:00 Simone Mazzoni <simone.mazzoni13 at gmail.com>:
>
>> Hello,
>>
>> I have some problems with the new version of panda.
>> I cloned the new version from the branch "master", I followed the new
>> compiling instructions, but when I run the "build.sh" script I get this
>> error:
>>
>>   The language of my Ubuntu 14.10 is Italian, so tell me if you don't
>> understand some debug messages. I don't understand why it gives that
>> "subdir-x86_64-softmmu" error.
>>
>> Any idea?
>>
>>  Thanks a lot.
>>
>>  Simone
>>
>> Il giorno Thu Dec 18 2014 at 03:35:57 Brendan Dolan-Gavitt <
>> brendandg at gatech.edu> ha scritto:
>>
>>  Right now the syscalls plugin only supports Linux system calls. So the
>>> "callname" you get is essentially whatever Linux system call
>>> corresponds to the syscall number (which is what's in EAX). We are
>>> working on adding support for Windows system calls (including
>>> arguments). If you just want something quick, you could change it to
>>> not print out the system call name and instead just use the number to
>>> look up the correct name in a Windows system call list.
>>>
>>> EAX is the ID of the system call, as you guessed. There are system
>>> call lists for Windows available; here's the one that comes with
>>> Volatility for Windows 7 SP1 32-bit:
>>>
>>> https://github.com/volatilityfoundation/volatility/blob/master/
>>> volatility/plugins/overlays/windows/win7_sp01_x86_syscalls.py
>>>
>>> EDX, on Windows, points to the stack at the time the syscall was made.
>>> The arguments to the syscall start at [EDX+8] (for Windows 32-bit).
>>> Here's an example function that gets an argument to a system call in
>>> Win7 32-bit:
>>>
>>> static uint32_t get_syscall_arg(CPUState* env, int nr) {
>>>     // At sysenter on Win7, args start at EDX+8
>>>     uint32_t arg;
>>>     panda_virtual_memory_rw(env, env->regs[R_EDX] + 8 + (4*nr),
>>>         (uint8_t *) &arg, 4, false);
>>>     return arg;
>>> }
>>>
>>> Hope this is helpful,
>>> Brendan
>>>
>>> On Wed, Dec 17, 2014 at 12:38 PM, Simone Mazzoni
>>> <simone.mazzoni13 at gmail.com> wrote:
>>> > Hello Brendan,
>>> >
>>> > I checked your code and I think that is a good way to pass and execute
>>> an
>>> > executable in the guest VM. I will try to implement such a thing as
>>> soon as
>>> > I can.
>>> >
>>> > Now I have another issue.
>>> > Premise: I’m doing this work for my master thesis. My purpose is to
>>> find a
>>> > way to track windows7 system calls (and their arguments) without doing
>>> > hooking, but by reading the guest VM memory, and storing it in a text
>>> file
>>> > or in a database, in order to reconstruct the execution flow of the
>>> > executable and perform some analysis.
>>> >
>>> > Until now, I found a way to use the panda plugins “osi” and
>>> “win7x86intro”
>>> > to selectively track only the syscalls of a certain process specifying
>>> its
>>> > name.
>>> > To track the syscalls, I’m currently using the “syscalls” panda plugin
>>> but I
>>> > don’t understand few things. The part of that plugin that interest me
>>> is
>>> > around row 337 —> “syscall_fprintf(env, "CALL=%s, PC=" TARGET_FMT_lx ",
>>> > SYSCALL=" TARGET_FMT_lx ", EDX=" TARGET_FMT_lx "\n", callname, pc,
>>> > env->regs[R_EAX], env->regs[R_EDX]);”
>>> > I edited this line to print out the R_EDX value instead of the CR3
>>> value.
>>> > I need now to understand some things that are not clear to me:
>>> >
>>> > what is contained in the variable “callname”? Sometime it prints out
>>> UNKNOWN
>>> > value, and sometimes it prints out linux system calls name (like
>>> sys_getuid)
>>> > even if I am running a windows OS —> I thought it would print
>>> something like
>>> > “NtCreateFile” that is a windows syscall.
>>> > what is contained in env->[R_EAX]? Is the code/id of the system call?
>>> And
>>> > what is TARGET_FMT_lx? Is looks like a placeholder but I don’t
>>> understand
>>> > exactly what it represents.
>>> > what is contained in env->[R_EDX]? I believe it contains the pointer
>>> to the
>>> > first syscall argument. Is it right?
>>> >
>>> >
>>> > Sorry for the huge amount of questions, but I’m a little stuck and I
>>> can’t
>>> > find so much documentation about these topics.
>>> >
>>> > Many thanks
>>> >
>>> > - Simone
>>> > -----------------------------------------------------
>>> > Simone Mazzoni
>>> > Cell: 340 5210441
>>> > E-Mail: simone.mazzoni13 at gmail.com
>>> > skype: mazzoni.s
>>> >
>>> > Il giorno 15/dic/2014, alle ore 18:55, Brendan Dolan-Gavitt
>>> > <brendandg at gatech.edu> ha scritto:
>>> >
>>> > Hi Simone,
>>> >
>>> > I actually recently set up something similar, in order to run malware.
>>> > You can see the script I ended up with here:
>>> >
>>> > http://amnesia.gtisc.gatech.edu/~moyix/runmal.py
>>> >
>>> > Basically it uses the QEMU monitor to insert a CD containing the
>>> > executable, and then sends keystrokes to the guest VM to copy it to
>>> > the desktop and execute it.
>>> >
>>> > On the other hand sending keystrokes is a bit unreliable, so I am
>>> > planning on switching over to a batch file on the CD that gets autorun
>>> > in order to start up the malware.
>>> >
>>> > Hope this helps,
>>> > Brendan
>>> >
>>> > On Mon, Dec 15, 2014 at 12:49 PM, Simone Mazzoni
>>> > <simone.mazzoni13 at gmail.com> wrote:
>>> >
>>> > Thanks all for the answers,
>>> > using the "osi;win7x86intro;my_plugin” configuration works for me, and
>>> now I
>>> > am able to track the syscalls of a specific process specifying its
>>> name or
>>> > PID.
>>> >
>>> > Now I’m trying to figure out if I can run an executable file from the
>>> > extern.
>>> > To be more clear, I wish to launch the win7 VM specifying an exe file (
>>> > let’s say foo.exe ) to execute once the system is booted, and the
>>> executable
>>> > should be passed as an argument or something similar to the host VM.
>>> Is it
>>> > possible to do something similar with qemu?
>>> >
>>> > My purpose is to analyze the syscalls traffic of a given executable
>>> file,
>>> > passed from the user.
>>> >
>>> > -Simone
>>> > -----------------------------------------------------
>>> > Simone Mazzoni
>>> > Cell: 340 5210441
>>> > E-Mail: simone.mazzoni13 at gmail.com
>>> > skype: mazzoni.s
>>> >
>>> > Il giorno 11/dic/2014, alle ore 01:23, Brendan Dolan-Gavitt
>>> > <brendandg at gatech.edu> ha scritto:
>>> >
>>> > Are you trying to run these plugins on a live system? You would
>>> > probably be better off making a recording and then doing your analysis
>>> > on a replay.
>>> >
>>> > In any case, yes – the plugins have to be loaded in the right order:
>>> > first osi, then win7x86intro, then testintro.
>>> >
>>> > -Brendan
>>> >
>>> > On Wed, Dec 10, 2014 at 4:51 PM, Simone Mazzoni
>>> > <simone.mazzoni13 at gmail.com> wrote:
>>> >
>>> > Hello Brendan,
>>> > I tried to use the testintro plugin today, but when I load it, it
>>> close qemu
>>> > with a core dump error.
>>> > And the error seems to be caused by the printf at line 34, because the
>>> > get_current_process(env); function returns a null pointer instead of
>>> the
>>> > current process.
>>> >
>>> > Should I have to load the testintro plugin and the win7x86into plugin
>>> > togegher?
>>> >
>>> > Thanks
>>> >
>>> > -Simone
>>> > -----------------------------------------------------
>>> > Simone Mazzoni
>>> > Cell: 340 5210441
>>> > E-Mail: simone.mazzoni13 at gmail.com
>>> > skype: mazzoni.s
>>> >
>>> > Il giorno 10/dic/2014, alle ore 17:09, Brendan Dolan-Gavitt
>>> > <brendandg at gatech.edu> ha scritto:
>>> >
>>> > I agree with Patrick that CR3 is probably the right choice in most
>>> > cases. But if you really want PID and you happen to be on Windows 7
>>> > 32-bit, you can use the OS introspection support we've added for that
>>> > OS. Look at
>>> >
>>> > https://github.com/moyix/panda/blob/master/qemu/panda_
>>> plugins/testintro/testintro.c
>>> >
>>> > for an example of how you'd add that to your plugin. When running it,
>>> > you'd use the argument "-panda osi; win7x86intro;your_plugin" to load
>>> > the Win7 introspection and the introspection abstraction layer
>>> > plugins.
>>> >
>>> > -Brendan
>>> >
>>> > On Wed, Dec 10, 2014 at 9:39 AM, Hulin, Patrick - 0559 - MITLL
>>> > <Patrick.Hulin at ll.mit.edu> wrote:
>>> >
>>> > Hi Simone,
>>> >
>>> > I’d recommend just using the CR3 register to track processes (we have a
>>> > function, panda_get_current_asid, that generalizes it to different
>>> > architectures). It won’t change for kernel mode, so you’ll have to
>>> manually
>>> > check whether or not you’re in kernel mode (ring 0). Finding PIDs is
>>> highly
>>> > OS-specific; you can use panda_memsavep and volatility to look at them
>>> for a
>>> > given memory snapshot, but we don’t have a generic way to look at them.
>>> >
>>> > From: Simone Mazzoni <simone.mazzoni13 at gmail.com>
>>> > Date: Wednesday, December 10, 2014 at 5:08 AM
>>> > To: - yrp <yrp604 at yahoo.com>
>>> > Cc: "panda-users at mit.edu" <panda-users at mit.edu>
>>> > Subject: Re: [panda-users] Problem syscall plugin usage
>>> >
>>> > Hello,
>>> > I have another question.
>>> >
>>> > There is a way to obtain the PID of the process caller of a system
>>> call in
>>> > order to filter the system calls analisys only for specified Processes?
>>> > My purpose is to track system calls only for a specified program in
>>> > execution on the system (i.e tracking only the system calls of the
>>> execution
>>> > of notepad.exe program on windows)
>>> >
>>> > Is it possible to do such a thing by editing the PANDA syscalls plugin?
>>> >
>>> > Simone
>>> >
>>> > 2014-12-08 20:14 GMT+01:00 - yrp <yrp604 at yahoo.com>:
>>> >
>>> >
>>> > Yes, 'env->regs[R_EDX]' should give you what you want. This of course
>>> > presumes the CPUState ptr is named env...
>>> >
>>> > For an example, see here:
>>> >
>>> > https://github.com/moyix/panda/blob/master/qemu/panda_
>>> plugins/syscalls/syscalls.cpp#L332
>>> >
>>> >
>>> >
>>> >
>>> > On Monday, December 8, 2014 6:12 AM, Simone Mazzoni
>>> > <simone.mazzoni13 at gmail.com> wrote:
>>> >
>>> >
>>> > Hello yrp,
>>> >
>>> > I solved my problem by disabling kvm. This allows me to read the
>>> content
>>> > of EAX register in order to read the data every time a system call is
>>> > invoked.
>>> >
>>> > Now I’m trying to find a way to get information about the arguments of
>>> > every system call. If I’m not wrong, the address of the first
>>> > parameter/argument of a system call is pushed in the EDX register. Is
>>> this
>>> > right? There is a way to retrive information about the parameters of
>>> each
>>> > system call invoked by the system?
>>> >
>>> > Tnaks,
>>> > Simone
>>> > -----------------------------------------------------
>>> > Simone Mazzoni
>>> > Cell: 340 5210441
>>> > E-Mail: simone.mazzoni13 at gmail.com
>>> > skype: mazzoni.s
>>> >
>>> > Il giorno 03/dic/2014, alle ore 21:28, - yrp <yrp604 at yahoo.com> ha
>>> > scritto:
>>> >
>>> > Hi Simone,
>>> >
>>> > I believe the syscalls plugin used to create the list of syscalls when
>>> it
>>> > was still coupled with the fdtracker plugin. Currently I think it only
>>> > provides an API for you to add your own hook before/after syscall
>>> execution
>>> > and in the Linux case, the ability to set a hook on any particular
>>> syscall.
>>> >
>>> > There are two proper ways to accomplish what you're looking for. First,
>>> > you could write a small plugin that uses the API defined in
>>> syscalls_int.h.
>>> > Alternatively, you could look at the format of the gen_syscalls_*
>>> files and
>>> > port them from linux to windows which should be relatively straight
>>> forward
>>> > as it's all just syscall prototypes. Finally, for a third option you
>>> could
>>> > modify the syscalls plugin around line 330. The last option is
>>> probably the
>>> > least "clean" but fastest.
>>> >
>>> > Hope this helps,
>>> > yrp
>>> >
>>> >
>>> > On Wednesday, December 3, 2014 9:50 AM, Simone Mazzoni
>>> > <simone.mazzoni13 at gmail.com> wrote:
>>> >
>>> >
>>> > Hello,
>>> >
>>> > I have a problem in using the “syscall” plugin provided in PANDA.
>>> >
>>> > I succesfully compiled PANDA following the compile.txt instruction.
>>> >
>>> > I want now to use PANDA to scan all the system calls on a Windows 7 VM.
>>> >
>>> > I run the Windows 7 VM with this command: “./qemu-system-x86_64 -hda
>>> > ../../../qemuwin7.img -enable-kvm -m 1024 -monitor stdio -loadvm booted
>>> > -panda syscalls” and the system replies with this message
>>> >
>>> > adding
>>> > /home/parallels/Desktop/Tesi/panda-master/qemu/x86_64-
>>> softmmu/panda_plugins/panda_syscalls.so
>>> > to panda_plugin_files 0
>>> > loading
>>> > /home/parallels/Desktop/Tesi/panda-master/qemu/x86_64-
>>> softmmu/panda_plugins/panda_syscalls.so
>>> > warning: Plugin 'syscalls' uses argument: -panda-arg
>>> syscalls:file=<file>
>>> > using default log file syscalls.txt
>>> > Success
>>> > QEMU 1.0,1 monitor - type 'help' for more information
>>> > (qemu) SaveVM v3 format forces exact matches between devices on load
>>> and
>>> > save, including on replay.
>>> >
>>> > So it seems that the plugin is succesfully loaded.
>>> > The message says also that the default log file “syscalls.txt” will be
>>> > used, so I expect to see some line in this file after running some
>>> programs
>>> > in the Windows 7 VM, but the file remains blank, so it seems that the
>>> plugin
>>> > is not working.
>>> >
>>> > Where are my errors? How can I effectively trace all the system calls
>>> > invocations of the guest Windows 7 system?
>>> >
>>> > Thanks
>>> >
>>> > Simone
>>> >
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > panda-users mailing list
>>> > panda-users at mit.edu
>>> > http://mailman.mit.edu/mailman/listinfo/panda-users
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > panda-users mailing list
>>> > panda-users at mit.edu
>>> > http://mailman.mit.edu/mailman/listinfo/panda-users
>>> >
>>> >
>>> >
>>> >
>>>
>>
>> _______________________________________________
>> panda-users mailing list
>> panda-users at mit.edu
>> http://mailman.mit.edu/mailman/listinfo/panda-users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/panda-users/attachments/20150105/f00ece71/attachment-0001.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Schermata del 2015-01-04 150247.png
Type: image/png
Size: 201060 bytes
Desc: not available
Url : http://mailman.mit.edu/mailman/private/panda-users/attachments/20150105/f00ece71/attachment-0001.png


More information about the panda-users mailing list