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

Bridgey theGeek bridgeythegeek at gmail.com
Tue Jul 4 16:35:52 EDT 2017


So, still plodding on with this one... I think I've got to the "problem",
but I need some help explaining what I've found.

Consider...

$ vol.py -f LinuxMint-17.3-Mate-x64-61951b91.vmem --profile LinuxMint173x64
linux_volshell
--SNIP--
>>> cc(pid=2476)
Current context: process example-0, pid=2476 DTB=0x38159000
>>> find("thisisthetext", max=1, length=16)
0x004011a1  74 68 69 73 69 73 74 68 65 74 65 78 74 00 65 6e
thisisthetext.en

This looks good! "thisisthetext" is at 0x004011a1, comfortably in user
space.

Use linux_memmap to find the physical offset...
Task    Pid    Virtual    Physical    Size
example-0    2476    0x0000000000401000    0x0000000015504000    0x1000

So my text should be at physical address 0x15504000 + 0x1a1 = 0x155041a1 ==
357,581,217. So...

$ dd if=LinuxMint-17.3-Mate-x64-61951b91.vmem bs=1 skip=357581217 count=13
| xxd
13+0 records in
13+0 records out
13 bytes copied, 9.2586e-05 s, 140 kB/s
00000000: 7468 6973 6973 7468 6574 6578 74         thisisthetext

That seems to work out, so lets put that in a text file suitable for
strings...
$ echo "357581217 thisisthetext" >/tmp/s

and run linux_strings...
$ vol.py -f LinuxMint-17.3-Mate-x64-61951b91.vmem --profile LinuxMint173x64
linux_strings -s /tmp/s
Volatility Foundation Volatility Framework 2.6
357581217 [kernel:8800155041a1] thisisthetext

I don't expect the module to be kernel or the memory address to be that?!
What's happened??

A memmap of pid=1 (init) shows...
init                    1 0x0000880015400000 0x0000000015400000
0x200000

So I'd expect logical address 0x8800155041a1 to be at physical address
0x15400000 + 0x1041a1 = 0x155041a1...

...which is the same physical address as the one we saw from the memmap of
pid=2476 above!

A run of data in the physical file is mapped to kernel space AND user space
of a process. Is this normal?
If it is normal, why didn't linux_strings report both kernel AND example-0?

Any comments very gratefullyasd received!



On 4 June 2017 at 21:40, Bridgey theGeek <bridgeythegeek at gmail.com> wrote:

> 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/20170704/170f361b/attachment.html>


More information about the Vol-users mailing list