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