3:44 p.m.
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
4:14 p.m.
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(a)lists.volatilityfoundation.org
https://lists.volatilityfoundation.org/mailman/listinfo/vol-users
One-click Unsubscribe:
https://lists.volatilityfoundation.org/mailman/options/vol-users/atcuno%40g…
4:40 p.m.
New subject: Why is this user-space data only in kernel space? #linux
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(a)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(a)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
4:35 p.m.
New subject: Why is this user-space data only in kernel space? #linux
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(a)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(a)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(a)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
2690
days inactive
2720
days old
vol-users@lists.volatilityfoundation.org
3 comments
2 participants
participants (2)
-
Andrew Case -
Bridgey theGeek