[Vol-users] Why is this user-space data only in kernel space? #linux

Bridgey theGeek bridgeythegeek at gmail.com
Sun Jun 4 16:40:13 EDT 2017


Hi Andrew,

Thanks for the suggestion. I'd also done the search in 010 Editor looking
for the strings in a variety of encodings, but only found it as single byte
characters (I thought the strings were stored in UTF-8 so single-byte for
these characters.)

But, just to be sure I did do:
$ strings -el --radix=d LinuxMint-17.3-Mate-x64-61951b91.vmem | grep "adam"

But got no hits.

I've done this test with slightly different programs as well, for example
using a GtkEntry (which is of course a GtkTextBuffer behind the scenes),
and the same findings: only exists in kernel space.

Thanks again,
Adam

On 4 June 2017 at 21:14, Andrew Case <atcuno at gmail.com> wrote:

> Have you searched for strings in unicode? It seems like that API uses
> unicode strings in the background.
>
> If you are using 'strings' from linux/binutils then add '-el' to extract
> the unicode ones.
>
> You can also use linux_yarascan against the pid in question, just set
> the wide flag, e.g:
>
> python vol.py --profile=... -f ... -W -Y adam1adam2adam3 -p <pid>
>
> Thanks,
> Andrew (@attrc)
>
> On 06/04/2017 02:44 PM, Bridgey theGeek wrote:
> > Hi all,
> >
> > This is a "what don't I know?" question...
> >
> > I have a very simple C program:
> >
> > #include <gtk/gtk.h>
> > #include <stdio.h>
> >
> > int main(int argc, char **argv)
> > {
> >     GtkTextBuffer *buffer;
> >     buffer = gtk_text_buffer_new(NULL);
> >     gtk_text_buffer_set_text(buffer, "adam1adam2adam3", 15);
> >
> >     printf("buffer: %p\n", buffer);
> >
> >     getchar();
> >     return 0;
> > }
> >
> > Then the following to try and locate the strings in memory:
> >
> > ------------------------------------------------------------
> > $ strings --radix=d LinuxMint-17.3-Mate-x64-61951b91.vmem | fgrep
> > adam1adam2adam3 >/tmp/s
> > ------------------------------------------------------------
> > $ cat /tmp/s
> > 195393652 adam1adam2adam3
> > 204175816 adam1adam2adam3
> > 851998836 adam1adam2adam3
> > ------------------------------------------------------------
> > $ ~/src/volatility/vol.py -f LinuxMint-17.3-Mate-x64-61951b91.vmem
> > --profile LinuxMint173x64 linux_strings -s /tmp/s
> > Volatility Foundation Volatility Framework 2.6
> > 195393652 [kernel:88000ba57874] adam1adam2adam3
> > 204175816 [kernel:88000c2b79c8] adam1adam2adam3
> > 851998836 [kernel:880032c87874] adam1adam2adam3
> > ------------------------------------------------------------
> >
> > Why on earth would the string only be located in Kernel space??
> >
> > I've been digging into Gtk for quite some time now to try and solve this
> > and think I understand that in Gtk, text is stored as
> GtkTextLineSegments.
> > The memory for a GtkTextLineSegment is allocated via g_slice_alloc and
> the
> > actual text copied to the allocated space via an ordinary memcpy (See:
> > https://github.com/GNOME/gtk/blob/406db15066f121c2b9910691f92e58
> > 41b30e0311/gtk/gtktextsegment.c#L190-L210)
> >
> >
> > I've proved the text really is here by editing the text in the VMEM file
> in
> > a hex editor and then resuming the VM - sure enough the text is updated
> to
> > reflect the changes.
> >
> > I could just about understand the text being in Kernel space AND user
> space
> > because perhaps its sent to the X server or something, but it appears to
> > ONLY be in Kernel space.
> >
> > What don't I know??
> >
> > Many thanks,
> > Adam
> >
> >
> >
> > _______________________________________________
> > Vol-users mailing list
> > Vol-users at lists.volatilityfoundation.org
> > https://lists.volatilityfoundation.org/mailman/listinfo/vol-users
> >
> > One-click Unsubscribe:
> > https://lists.volatilityfoundation.org/mailman/options/vol-users/
> atcuno%40gmail.com?unsub=1&unsubconfirm=1
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.volatilityfoundation.org/pipermail/vol-users/attachments/20170604/369407e0/attachment.html>


More information about the Vol-users mailing list