[panda-users] Osi_linux plugin

Sun Apr 19 10:04:25 EDT 2015

Hi Manolis,

I think I got the problem.
In my plugin I called the get_current_process() in a function executed
every time a PANDA_CB_INSN_EXEC callback was called. In the osi_test the
get_current_process() function is called every time is called
a PANDA_CB_BEFORE_BLOCK_EXEC callback. If i call the get_current_process()
within the PANDA_CB_BEFORE_BLOCK_EXEC callback, all works fine and I get
the name of the current process in execution.

Now I have another problem.
My original purpose is to track the system calls invoked by a specific
process.
In my windows version of the plugin, I do this thing by:
- intercept if the current instruction is SYSENTER (checking the op code in
the PANDA_CB_INSN_TRANSLATE callback)
- if I'm in SYSENTER, I call the get_current_process() function after
every PANDA_CB_INSN_EXEC
callback to check if the PID or PROCESS_NAME is the desired one, and if it
is, I print out the value of the EAX register.

I will put my plugin source code as attachment so as you can better
understand.

I tried to do the same in the plugin for linux using the osi_linux, but it
does not work. How can I accomplish my goal?

I have also another question, the PANDA_CB_INSN_EXEC callback, is called
before or after the PANDA_CB_BEFORE_BLOCK_EXEC?

Thanks.

- Simone

Il giorno ven 17 apr 2015 alle ore 21:39 Manolis Stamatogiannakis <
mstamat at gmail.com> ha scritto:

> For i386-softmmu + latest debian stable osi_linux should work out of the
> box. (This is the setup I used to develop it, so you shouldn't even have to
> extract new offsets.)
>
> Can you try using osi_test plugin instead of your plugin?
>
> Also, where does your LD_LIBRARY_PATH points to? Make sure it loads the
> PANDA plugins from i386-softmmu directory.
>
> M.
>
>
>
> 2015-04-17 11:14 GMT-07:00 Simone Mazzoni <simone.mazzoni13 at gmail.com>:
>
> Nope that time, I used x86_64-softmmu (for windows worked fine), but I
>> tried again with i386-softmmu and it is the same thing.
>> There must be a problem of offset as you said. I extracted the offsets
>> for osi_linux using the kernelinfo module, so I don't know what can be
>> wrong.
>>
>> The Guest OS I am working on is a Debian 7.8.0 32bit.
>>
>> I don't know how to solve.
>>
>> P.S: I am not using records but live execution (./qemu-system-i386 -m 1G
>> -monitor stdio -hda debian.iso -panda 'osi;osi_linux;my_plugin')
>>
>> Il giorno ven 17 apr 2015 alle ore 20:01 Manolis Stamatogiannakis <
>> mstamat at gmail.com> ha scritto:
>>
>>> Junk -> reading from the wrong location -> the offsets you are using do
>>> not match your setup.
>>>
>>> Did you recapture your traces on i386-softmmu?
>>>
>>>
>>>
>>> 2015-04-17 10:38 GMT-07:00 Simone Mazzoni <simone.mazzoni13 at gmail.com>:
>>>
>>> OK, I tried just now to retrieve the name of the current process when in
>>>> kernel mode (after a sysenter instruction OF35) but if I print the name or
>>>> the pid of the process, I get strange values. (Notice that I deleted the
>>>> rows where the process name is N/A)
>>>> Here an example of the output:
>>>>
>>>> I do the same this in windows and work just fine, but in linux seems
>>>> not to work. Any idea about the reason?
>>>>
>>>> Thanks.
>>>>
>>>> - Simone
>>>>
>>>> Il giorno ven 17 apr 2015 alle ore 17:56 Manolis Stamatogiannakis <
>>>> mstamat at gmail.com> ha scritto:
>>>>
>>>>> You need to call get_current_process() when your process runs in
>>>>> kernel mode. Since you are interested in syscalls, injecting the call in
>>>>> instrumentation after SYSENTER instruction would work.
>>>>>
>>>>> This is a known limitation of the current implementation. The problem
>>>>> is that calculating the task struct address of the running process while in
>>>>> user mode is complicated.
>>>>> It should be doable (debianwheezyx86intro does it), but requires to
>>>>> extract additional kernel version specific offsets. If you have time to
>>>>> investigate and fix this, it would be great.
>>>>>
>>>>> Working around this limitation isn't hard. Retrieve the process info
>>>>> when in kernel mode. Map the info to the physical address of the PGD (do a
>>>>> virt->phys conversion of the address in the OsiProc struct). Retrieve the
>>>>> info when you need it in user mode (PGD is stored in CR3 register).
>>>>>
>>>>> There was another discussion on the subject in a previous thread
>>>>> involving Igor, Brendan and myself.
>>>>>
>>>>> Cheers,
>>>>> M.
>>>>>
>>>>> 2015-04-17 0:53 GMT-07:00 Simone Mazzoni <simone.mazzoni13 at gmail.com>:
>>>>>
>>>>> Hi,
>>>>>>
>>>>>> I am a little confused at the moment.
>>>>>> Let me try to explain what is my purpose.
>>>>>>
>>>>>> I implemented a plugin that retrieve the syscall parameters from the
>>>>>> syscalls called by a specific process in windows. To do that I used the Osi
>>>>>> Plugin to intercept the current process in execution using the method "
>>>>>> OsiProc *current = get_current_process(env);" from the osi plugin,
>>>>>> and it works well.
>>>>>>
>>>>>> I need now to do the same thing for in a Linux x86 SO (Debian or
>>>>>> Ubuntu), so I tried to use the Osi plugin as well but I noticed that that
>>>>>> function return null at every execution. I thought that the problem is that
>>>>>> the way a process is represented in linux is different from the one in
>>>>>> windows, so I tried to use the osi_linux plugin together with the osi one
>>>>>> but up to now I wasn't able to run the osi plugin.
>>>>>>
>>>>>> Is this reasonable?
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> - Simone
>>>>>>
>>>>>> Il giorno gio 16 apr 2015 alle ore 21:04 Manolis Stamatogiannakis <
>>>>>> mstamat at gmail.com> ha scritto:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2015-04-16 11:06 GMT-07:00 Simone Mazzoni <
>>>>>>> simone.mazzoni13 at gmail.com>:
>>>>>>>
>>>>>>> 64bit?
>>>>>>>> The OSI plugin work only for x86 OSes, am I wrong?
>>>>>>>>
>>>>>>>
>>>>>>> The osi plugin is just a skeleton. It should work with anything at
>>>>>>> all.
>>>>>>>
>>>>>>> I think there was a mention in the list that the windows
>>>>>>> introspection would work only with 32bit windows - maybe this confused you.
>>>>>>> But this is mostly a limitation of qemu (IIRC it can't run 64bit windows in
>>>>>>> the version PANDA is based upon).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Anyway my host system is a 64bit OS while the OS I want introspect
>>>>>>>> is 32 bit. I hope it work.
>>>>>>>>
>>>>>>>
>>>>>>> I don't think it will work. A lot of arithmetic in the plugin
>>>>>>> requires to know the width of the address of the guest. It is assumed that
>>>>>>> this matches the address width of the qemu target (8bytes for
>>>>>>> x86_64-softmmu). This is set by the PTR macro in osi_linux.h.
>>>>>>>
>>>>>>> Maybe, you can make it work if you #define target_ulong as a 4byte
>>>>>>> long type when compiling osi_linux. If you have time to try this and it
>>>>>>> turns out it works, let us know.
>>>>>>>
>>>>>>> But unless you have already amassed a trove of PANDA traces from
>>>>>>> 32bit linux running on x86_64-softmmu, it would be simpler to just use
>>>>>>> i386-softmmu.
>>>>>>>
>>>>>>> M.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Thanks for the help,
>>>>>>>>
>>>>>>>> - Simone
>>>>>>>>
>>>>>>>> Il giorno gio 16 apr 2015 17:55 Manolis Stamatogiannakis <
>>>>>>>> mstamat at gmail.com> ha scritto:
>>>>>>>>
>>>>>>>>> There is a default kernel group hardwired in the source.
>>>>>>>>>
>>>>>>>>> You should point to the proper kernel group of your kernelinfo
>>>>>>>>> using the kconf_group parameter. You can also point to the exact location
>>>>>>>>> of your kernelinfo with the kconf_file parameter (but usually a softlink is
>>>>>>>>> faster :) : "osi;osi_linux:kconf_file=...,kconf_group=...;osi_test"
>>>>>>>>>
>>>>>>>>> Btw, you don't have to manually extract and parse the dmesg
>>>>>>>>> output. kernelinfo_parse.py script does this for you, so you only need to
>>>>>>>>> append its output to your kernelinfo file. Also, make sure that your guest
>>>>>>>>> OS is also 64 bit.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Manolis
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2015-04-16 7:51 GMT-07:00 Simone Mazzoni <
>>>>>>>>> simone.mazzoni13 at gmail.com>:
>>>>>>>>>
>>>>>>>>> Hi Manolis,
>>>>>>>>>>
>>>>>>>>>> I created the kernelinfo.conf file, but I do not understand where
>>>>>>>>>> I have to put it in order to make the osi_linux plugin work.
>>>>>>>>>> It gives me this error when I try to run panda with this command
>>>>>>>>>> line --> ./qemu-system-x86_64 -m 1G -monitor stdio -hda
>>>>>>>>>> ../../../challdeb.img -loadvm booted -panda 'osi;osi_linux;osi_test'
>>>>>>>>>>
>>>>>>>>>> What am I doing wrong?
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>>
>>>>>>>>>> -Simone
>>>>>>>>>>
>>>>>>>>>> Il giorno gio 16 apr 2015 alle ore 15:36 Simone Mazzoni <
>>>>>>>>>> simone.mazzoni13 at gmail.com> ha scritto:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I extracted the parameters from the OS kernel that I want
>>>>>>>>>>> introspect.
>>>>>>>>>>>
>>>>>>>>>>> The parameters are these:
>>>>>>>>>>>
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.872169]
>>>>>>>>>>> --KERNELINFO-BEGIN--
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873067] name = #1 SMP
>>>>>>>>>>> Debian 3.2.65-1+deb7u2 i686
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873114] task.size = 1060
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873249] #task.init_addr =
>>>>>>>>>>> 0xC13E2FE0
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873279] task.init_addr =
>>>>>>>>>>> 3242078176
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873310] task.task_offset
>>>>>>>>>>> = 0
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873356] task.tasks_offset
>>>>>>>>>>> = 212
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873394] task.pid_offset =
>>>>>>>>>>> 292
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873420] task.tgid_offset
>>>>>>>>>>> = 296
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873447]
>>>>>>>>>>> task.group_leader_offset = 328
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873475]
>>>>>>>>>>> task.thread_group_offset = 384
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873504]
>>>>>>>>>>> task.real_parent_offset = 304
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873532]
>>>>>>>>>>> task.parent_offset = 308
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873559] task.mm_offset =
>>>>>>>>>>> 240
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873586] task.stack_offset
>>>>>>>>>>> = 4
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873615]
>>>>>>>>>>> task.real_cred_offset = 504
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873642] task.cred_offset
>>>>>>>>>>> = 508
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873668] task.comm_offset
>>>>>>>>>>> = 516
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873693] task.comm_size =
>>>>>>>>>>> 16
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873722] cred.uid_offset =
>>>>>>>>>>> 4
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873749] cred.gid_offset =
>>>>>>>>>>> 8
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873774] cred.euid_offset
>>>>>>>>>>> = 20
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873813] cred.egid_offset
>>>>>>>>>>> = 24
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873842] mm.mmap_offset = 0
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873867] mm.pgd_offset = 36
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873901]
>>>>>>>>>>> mm.arg_start_offset = 152
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.873970]
>>>>>>>>>>> mm.start_brk_offset = 140
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.874004] mm.brk_offset =
>>>>>>>>>>> 144
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.874032]
>>>>>>>>>>> mm.start_stack_offset = 148
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.874078] vma.vm_mm_offset
>>>>>>>>>>> = 0
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.874104]
>>>>>>>>>>> vma.vm_start_offset = 4
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.874133] vma.vm_end_offset
>>>>>>>>>>> = 8
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.874161]
>>>>>>>>>>> vma.vm_next_offset = 12
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.874187]
>>>>>>>>>>> vma.vm_flags_offset = 28
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.874215]
>>>>>>>>>>> vma.vm_file_offset = 80
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.874242]
>>>>>>>>>>> fs.f_dentry_offset = 12
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.874268] fs.f_path_offset
>>>>>>>>>>> = 8
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.874293] fs.d_name_offset
>>>>>>>>>>> = 20
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.874320] fs.d_iname_offset
>>>>>>>>>>> = 36
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.874347]
>>>>>>>>>>> fs.d_parent_offset = 16
>>>>>>>>>>> Apr 14 22:38:24 polictf kernel: [ 3533.874369]
>>>>>>>>>>> ---KERNELINFO-END---
>>>>>>>>>>>
>>>>>>>>>>> At this point, if I am not wrong, I have to edit the
>>>>>>>>>>> kernelinfo.conf file with the new parameters. It is right or there are
>>>>>>>>>>> other things to do?
>>>>>>>>>>>
>>>>>>>>>>> Thanks.
>>>>>>>>>>>
>>>>>>>>>>> - Simone
>>>>>>>>>>>
>>>>>>>>>>> Il giorno mer 15 apr 2015 alle ore 20:41 Manolis
>>>>>>>>>>> Stamatogiannakis <mstamat at gmail.com> ha scritto:
>>>>>>>>>>>
>>>>>>>>>>>> When you run the plugin, kernelinfo.conf must exist in your
>>>>>>>>>>>> current directory. So just soft-link it from the source directory of the
>>>>>>>>>>>> plugin.
>>>>>>>>>>>>
>>>>>>>>>>>> In your case however, the stock kernelinfo.conf won't work
>>>>>>>>>>>> because it currently contains only information for the 32bit kernel used by
>>>>>>>>>>>> debian stable.
>>>>>>>>>>>> So you have to compile the kernelinfo module in a guest running
>>>>>>>>>>>> (ideally) the same kernel you want to introspect.
>>>>>>>>>>>> Then insert it into the kernel (insertion always fails) and use
>>>>>>>>>>>> the supplied python script to extract the offsets for that kernel.
>>>>>>>>>>>>
>>>>>>>>>>>> The offsets should then be appended to kernelinfo.conf. Also
>>>>>>>>>>>> make a pull request for the updated kernelinfo.conf when you do this.
>>>>>>>>>>>>
>>>>>>>>>>>> IIRC, the kernelinfo module had some glitches which prevented
>>>>>>>>>>>> it from compiling in recent kernels (e.g. 3.20). So if you encounter any
>>>>>>>>>>>> problems, drop me an email so that I expedit making a pull request for the
>>>>>>>>>>>> fixed version.
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> M.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> M.
>>>>>>>>>>>>
>>>>>>>>>>>> 2015-04-15 8:26 GMT-07:00 Simone Mazzoni <
>>>>>>>>>>>> simone.mazzoni13 at gmail.com>:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I tried to use the osi_linux plugin to get the current process
>>>>>>>>>>>>> in execution but it seems not to work.
>>>>>>>>>>>>> I tried to execute panda with -panda 'osi;osi_linux;osi_test'
>>>>>>>>>>>>> but it gives me the following error:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Any idea of the reason?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I noticed see that the plugin contain a "utils/kernelinfo"
>>>>>>>>>>>>> folder that should contain a script or something to extract the correct
>>>>>>>>>>>>> offset of the running kernel, but I do not understand how to use it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I tried running the osi_test on an Debian SO and on a Ubuntu
>>>>>>>>>>>>> 14.04 SO.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks for the help.
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Simone
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> 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/pipermail/panda-users/attachments/20150419/6cc62f69/attachment-0001.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Schermata 2015-04-15 alle 17.23.00.png
Type: image/png
Size: 121425 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/panda-users/attachments/20150419/6cc62f69/attachment-0003.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2015-04-17 19:34:38.png
Type: image/png
Size: 180200 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/panda-users/attachments/20150419/6cc62f69/attachment-0004.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2015-04-16 16:50:14.png
Type: image/png
Size: 96902 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/panda-users/attachments/20150419/6cc62f69/attachment-0005.png