[panda-users] Osi_linux plugin

Fri Apr 17 03:53:30 EDT 2015

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/20150417/92f6d67e/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/20150417/92f6d67e/attachment-0002.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/20150417/92f6d67e/attachment-0003.png