[panda-users] Linux 32bit records always in kernel space

[Sergej Schmidt]

On 10/02/2017 11:24 AM, aicardi at eurecom.fr wrote:
> Hello everyone,
>
> I'm having troubles in performing some analyses on Linux 32bit executables.
>
> I would like to trace the execution of a particular process which I  
> know the PID of. To do so, I registered a callback for  
> PANDA_CB_AFTER_BLOCK_EXEC. Every time it is called I check whether the  
> basic block belongs to the target process or not by calling  
> 'get_current_process' and comparing the current process' PID against  
> the target one (if the result of get_current_process is not NULL).
>
> The problem is that I noticed that every 'good' basic block had a  
> program counter (tb->pc of the struct TranslationBlock *tb) which was  
> always higher than 0xC0000000 (and so in kernel space, right?).
>
> Then I discovered that the reason for that was that every time a basic  
> block was in user space (tb->pc < 0xC0000000) get_current_process  
> returned a NULL value.
>
> To be sure of that I tried recording a simple hello world C program  
> which I compiled with the -Wl,-Ttext-segment=0x12340000 option, just  
> to be able to spot the program counter with that particular value  
> among all the tb->pc that I printed during the execution. The  
> corresponding return value for get_current_process in the same basic  
> block was always NULL.
>
> Can anyone tell me why this happens?
>
> Thank you in advance,
> samaicardi
>
> -------------------------------------------------------------------------------
> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
>
>
> _______________________________________________
> panda-users mailing list
> panda-users at mit.edu
> http://mailman.mit.edu/mailman/listinfo/panda-users

Hello samaicardi,

I had a similar problem a while ago. I'll try to rephrase what I was
told on IRC.

Depending on where you are, in regards to the context,
get_current_process() might not be able to return a valid value (or at
least no correct PID). I tried to call get_current_process() after
syscalls, which were still in kernel context and therefore, it didn't
work. I don't know how PANDA_CB_AFTER_BLOCK_EXEC behaves, but I assume
you have a similar problem.

My solution was to hold a global variable with the current PID and
change it as soon as the ASID changes:

>   panda_cb pcb = { .asid_changed = my_on_asid_change /* here I just
> asign my global PID-var with current PID
> */};                               
>   panda_register_callback(self, PANDA_CB_ASID_CHANGED, pcb); 
Every time $EVENT happened (in my case syscall), I checked the global
PID-variable for a match.

If you have a callback on PANDA_CB_AFTER_BLOCK_EXEC, the asid should
stay the same. My assumption is based upon PANDA translating code
BBL-wise and the ASID can change only before respectively after a BBL
was executed. However, I am not sure if it is possible that the context
can be changed during a BBL. Anybody?
My solution is somewhat more performance-frendly since, the
get_current_process() is not called during every BBL_EXEC, but I just
saw that the file taint plugin checks for current PID _before_ BBL_EXEC
https://github.com/panda-re/panda/blob/master/panda/plugins/file_taint/file_taint.cpp#L559.

Maybe try out both.

Those are assumption I have worked with, so far successful. I hope
somebody with more PANDA-experience will correct me, if necessary.

Regards,
Sergej


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
Url : http://mailman.mit.edu/pipermail/panda-users/attachments/20171002/ca610366/attachment.bin