[panda-users] Osi_linux plugin
Manolis Stamatogiannakis
mstamat at gmail.com
Fri Apr 17 14:01:12 EDT 2015
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/20150417/f563c023/attachment-0001.htm
-------------- 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/20150417/f563c023/attachment-0003.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/f563c023/attachment-0004.png
-------------- 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/f563c023/attachment-0005.png
More information about the panda-users
mailing list