6:31 p.m.
Glad I could help!
Yep, I've seen this before many times ;-)
All the best,
-gleeda
-----Original Message-----
From: Mike Lambert <dragonforen(a)hotmail.com>
Date: Mon, 27 Feb 2012 17:02:15
To: <jamie.levy(a)gmail.com>
Subject: RE: [Vol-users] stings input file format question
My thanks! Well you called that one! I was using Encase's "Export" to output
a text file of the offsets of the hits from the search result tab. Encase outputs unicode
text.
I just need to put a new step in the process, convert it to ANSI before running it with
the strings command.
And it does have a funky befinning of file marker....
You must have seen this before?
Best,
Mike
Date: Mon, 27 Feb 2012 16:39:08 -0500
Subject: Re: [Vol-users] stings input file format question
From: jamie.levy(a)gmail.com
To: dragonforen(a)hotmail.com
hrmmmmm I don't see anything obviously wrong here... But since you
said these offsets are from EnCase, how were they obtained? By
EnScript to a file, copy+paste from the console or some other method?
I'm just curious if the offsets were exported in ASCII or EnCase's
default UTF-16. Also sometimes when exporting in unicode, there's a
funky corrupt BOM that EnCase uses that might be messing things up...
I'm just trying to think of things that might have gone wrong here.
Maybe you could try copy and pasting a few of these "Ypycub" entries
into a new text file and running the strings plugin again to see.
All the best,
-gleeda
On Mon, Feb 27, 2012 at 4:06 PM, Mike Lambert <dragonforen(a)hotmail.com> wrote:
I am mystified why I see the following: in one
case I get output from
strings and the other I get an input file format error. I have tried this
with 1.3 and 2.0 and get the same result. It takes 1.3 a looonnngg time to
return the error, 2.0 returs the error quickly.
I thought the reason may be length, so I broke up the Ypycub offsets into
increasingly smaller input files; no success was achived with the smaller
input files.
I don't see a format difference in these 2 files.
The offsets come from an Encase search of 120225b.mem. It is a 458MB
WinXPSP3x86 image converted from hiberfil.sys.
Vol 1.3 example: The same result is seen with Vol 2.0
The input file is:
357229672:Glows
280642408:Glows
257105340:Glows
113457472:Glows
357230696:Glows
C:\Python27\Volatility-1.3_Beta>python volatility strings -f
e:\tests\120225b\IRinfo\120225b.mem -s 120225b_Glows_offsets.txt
357229672 [kernel:df864468 ] Glows
280642408 [1456:45b8368 ] Glows
257105340 [kernel:e1ec1dbc ] Glows
113457472 [1456:2ac0940 ] Glows
357230696 [kernel:df864868 ] Glows
----------------------cut-here-------------------------
The input file is:
7744388:Ypycub
10830274:Ypycub
70385414:Ypycub
70918297:Ypycub
70918649:Ypycub
73375514:Ypycub
91390974:Ypycub
104879126:Ypycub
104879154:Ypycub
132968006:Ypycub
215776800:Ypycub
232868024:Ypycub
232869190:Ypycub
237434963:Ypycub
237434991:Ypycub
256642118:Ypycub
285030170:Ypycub
310449659:Ypycub
310449687:Ypycub
314178656:Ypycub
325974496:Ypycub
327972307:Ypycub
327972335:Ypycub
338814062:Ypycub
338814854:Ypycub
339229856:Ypycub
339763304:Ypycub
339763544:Ypycub
339893168:Ypycub
340101984:Ypycub
343215259:Ypycub
343215287:Ypycub
357229759:Ypycub
361836122:Ypycub
367889650:Ypycub
455348611:Ypycub
455348639:Ypycub
C:\Python27\Volatility-1.3_Beta>python volatility strings -f
e:\tests\120225b\IRinfo\120225b.mem -s 120225b_Ypycub_offsets.txt
Usage: strings [options] (see --help)
volatility: error: String file format invalid.
Thanks for any assistance.
Mike
_______________________________________________
Vol-users mailing list
Vol-users(a)volatilesystems.com
http://lists.volatilesystems.com/mailman/listinfo/vol-users
--
PGP Fingerprint: 2E87 17A1 EC10 1E3E 11D3 64C2 196B 2AB5 27A4 AC92
12:37 p.m.
New subject: stings input file format question
Since someone requested it, I updated the Command Reference wiki to
include info on using EnCase keywords for string offsets:
http://code.google.com/p/volatility/wiki/CommandReference#strings
On Mon, Feb 27, 2012 at 6:31 PM, Jamie Levy <jamie.levy(a)gmail.com> wrote:
Glad I could help!
Yep, I've seen this before many times ;-)
All the best,
-gleeda
________________________________
From: Mike Lambert <dragonforen(a)hotmail.com>
Date: Mon, 27 Feb 2012 17:02:15 -0600
To: <jamie.levy(a)gmail.com>
Subject: RE: [Vol-users] stings input file format question
My thanks! Well you called that one! I was using Encase's "Export" to
output
a text file of the offsets of the hits from the search result tab. Encase
outputs unicode text.
I just need to put a new step in the process, convert it to ANSI before
running it with the strings command.
And it does have a funky befinning of file marker....
You must have seen this before?
Best,
Mike
> Date: Mon, 27 Feb 2012 16:39:08 -0500
> Subject: Re: [Vol-users] stings input file format question
> From: jamie.levy(a)gmail.com
> To: dragonforen(a)hotmail.com
>
> hrmmmmm I don't see anything obviously wrong here... But since you
> said these offsets are from EnCase, how were they obtained? By
> EnScript to a file, copy+paste from the console or some other method?
> I'm just curious if the offsets were exported in ASCII or EnCase's
> default UTF-16. Also sometimes when exporting in unicode, there's a
> funky corrupt BOM that EnCase uses that might be messing things up...
> I'm just trying to think of things that might have gone wrong here.
>
> Maybe you could try copy and pasting a few of these "Ypycub" entries
> into a new text file and running the strings plugin again to see.
>
> All the best,
>
> -gleeda
>
>
> On Mon, Feb 27, 2012 at 4:06 PM, Mike Lambert <dragonforen(a)hotmail.com>
> wrote:
> > I am mystified why I see the following: in one case I get output from
> > strings and the other I get an input file format error. I have tried
> > this
> > with 1.3 and 2.0 and get the same result. It takes 1.3 a looonnngg time
> > to
> > return the error, 2.0 returs the error quickly.
> >
> > I thought the reason may be length, so I broke up the Ypycub offsets
> > into
> > increasingly smaller input files; no success was achived with the
> > smaller
> > input files.
> > I don't see a format difference in these 2 files.
> >
> > The offsets come from an Encase search of 120225b.mem. It is a 458MB
> > WinXPSP3x86 image converted from hiberfil.sys.
> >
> >
> > Vol 1.3 example: The same result is seen with Vol 2.0
> >
> > The input file is:
> >
> > 357229672:Glows
> > 280642408:Glows
> > 257105340:Glows
> > 113457472:Glows
> > 357230696:Glows
> >
> >
> > C:\Python27\Volatility-1.3_Beta>python volatility strings -f
> > e:\tests\120225b\IRinfo\120225b.mem -s 120225b_Glows_offsets.txt
> >
> > 357229672 [kernel:df864468 ] Glows
> > 280642408 [1456:45b8368 ] Glows
> > 257105340 [kernel:e1ec1dbc ] Glows
> > 113457472 [1456:2ac0940 ] Glows
> > 357230696 [kernel:df864868 ] Glows
> >
> > ----------------------cut-here-------------------------
> > The input file is:
> >
> > 7744388:Ypycub
> > 10830274:Ypycub
> > 70385414:Ypycub
> > 70918297:Ypycub
> > 70918649:Ypycub
> > 73375514:Ypycub
> > 91390974:Ypycub
> > 104879126:Ypycub
> > 104879154:Ypycub
> > 132968006:Ypycub
> > 215776800:Ypycub
> > 232868024:Ypycub
> > 232869190:Ypycub
> > 237434963:Ypycub
> > 237434991:Ypycub
> > 256642118:Ypycub
> > 285030170:Ypycub
> > 310449659:Ypycub
> > 310449687:Ypycub
> > 314178656:Ypycub
> > 325974496:Ypycub
> > 327972307:Ypycub
> > 327972335:Ypycub
> > 338814062:Ypycub
> > 338814854:Ypycub
> > 339229856:Ypycub
> > 339763304:Ypycub
> > 339763544:Ypycub
> > 339893168:Ypycub
> > 340101984:Ypycub
> > 343215259:Ypycub
> > 343215287:Ypycub
> > 357229759:Ypycub
> > 361836122:Ypycub
> > 367889650:Ypycub
> > 455348611:Ypycub
> > 455348639:Ypycub
> >
> >
> > C:\Python27\Volatility-1.3_Beta>python volatility strings -f
> > e:\tests\120225b\IRinfo\120225b.mem -s 120225b_Ypycub_offsets.txt
> >
> > Usage: strings [options] (see --help)
> > volatility: error: String file format invalid.
> >
> >
> > Thanks for any assistance.
> >
> > Mike
> >
> >
> >
> >
> >
> > _______________________________________________
> > Vol-users mailing list
> > Vol-users(a)volatilityfoundation.org
> > http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
> >
>
>
>
> --
> PGP Fingerprint: 2E87 17A1 EC10 1E3E 11D3 64C2 196B 2AB5 27A4 AC92
--
PGP Fingerprint: 2E87 17A1 EC10 1E3E 11D3 64C2 196B 2AB5 27A4 AC92
12:43 p.m.
New subject: stings input file format question
Very cool. I looked at it. You might want to mention that if they delete the first line
("Offsets") and then Save As 'ANSI', that will solve the problem. It is
now part of my process.
Thanks!
Date: Wed, 29 Feb 2012 12:37:02 -0500
Subject: Re: [Vol-users] stings input file format question
From: jamie.levy(a)gmail.com
To: vol-users(a)volatilityfoundation.org
Since someone requested it, I updated the Command Reference wiki to
include info on using EnCase keywords for string offsets:
http://code.google.com/p/volatility/wiki/CommandReference#strings
On Mon, Feb 27, 2012 at 6:31 PM, Jamie Levy <jamie.levy(a)gmail.com> wrote:
Glad I could help!
Yep, I've seen this before many times ;-)
All the best,
-gleeda
________________________________
From: Mike Lambert <dragonforen(a)hotmail.com>
Date: Mon, 27 Feb 2012 17:02:15 -0600
To: <jamie.levy(a)gmail.com>
Subject: RE: [Vol-users] stings input file format question
My thanks! Well you called that one! I was using Encase's "Export" to
output
a text file of the offsets of the hits from the search result tab. Encase
outputs unicode text.
I just need to put a new step in the process, convert it to ANSI before
running it with the strings command.
And it does have a funky befinning of file marker....
You must have seen this before?
Best,
Mike
> Date: Mon, 27 Feb 2012 16:39:08 -0500
> Subject: Re: [Vol-users] stings input file format question
> From: jamie.levy(a)gmail.com
> To: dragonforen(a)hotmail.com
>
> hrmmmmm I don't see anything obviously wrong here... But since you
> said these offsets are from EnCase, how were they obtained? By
> EnScript to a file, copy+paste from the console or some other method?
> I'm just curious if the offsets were exported in ASCII or EnCase's
> default UTF-16. Also sometimes when exporting in unicode, there's a
> funky corrupt BOM that EnCase uses that might be messing things up...
> I'm just trying to think of things that might have gone wrong here.
>
> Maybe you could try copy and pasting a few of these "Ypycub" entries
> into a new text file and running the strings plugin again to see.
>
> All the best,
>
> -gleeda
>
>
> On Mon, Feb 27, 2012 at 4:06 PM, Mike Lambert <dragonforen(a)hotmail.com>
> wrote:
> > I am mystified why I see the following: in one case I get output from
> > strings and the other I get an input file format error. I have tried
> > this
> > with 1.3 and 2.0 and get the same result. It takes 1.3 a looonnngg time
> > to
> > return the error, 2.0 returs the error quickly.
> >
> > I thought the reason may be length, so I broke up the Ypycub offsets
> > into
> > increasingly smaller input files; no success was achived with the
> > smaller
> > input files.
> > I don't see a format difference in these 2 files.
> >
> > The offsets come from an Encase search of 120225b.mem. It is a 458MB
> > WinXPSP3x86 image converted from hiberfil.sys.
> >
> >
> > Vol 1.3 example: The same result is seen with Vol 2.0
> >
> > The input file is:
> >
> > 357229672:Glows
> > 280642408:Glows
> > 257105340:Glows
> > 113457472:Glows
> > 357230696:Glows
> >
> >
> > C:\Python27\Volatility-1.3_Beta>python volatility strings -f
> > e:\tests\120225b\IRinfo\120225b.mem -s 120225b_Glows_offsets.txt
> >
> > 357229672 [kernel:df864468 ] Glows
> > 280642408 [1456:45b8368 ] Glows
> > 257105340 [kernel:e1ec1dbc ] Glows
> > 113457472 [1456:2ac0940 ] Glows
> > 357230696 [kernel:df864868 ] Glows
> >
> > ----------------------cut-here-------------------------
> > The input file is:
> >
> > 7744388:Ypycub
> > 10830274:Ypycub
> > 70385414:Ypycub
> > 70918297:Ypycub
> > 70918649:Ypycub
> > 73375514:Ypycub
> > 91390974:Ypycub
> > 104879126:Ypycub
> > 104879154:Ypycub
> > 132968006:Ypycub
> > 215776800:Ypycub
> > 232868024:Ypycub
> > 232869190:Ypycub
> > 237434963:Ypycub
> > 237434991:Ypycub
> > 256642118:Ypycub
> > 285030170:Ypycub
> > 310449659:Ypycub
> > 310449687:Ypycub
> > 314178656:Ypycub
> > 325974496:Ypycub
> > 327972307:Ypycub
> > 327972335:Ypycub
> > 338814062:Ypycub
> > 338814854:Ypycub
> > 339229856:Ypycub
> > 339763304:Ypycub
> > 339763544:Ypycub
> > 339893168:Ypycub
> > 340101984:Ypycub
> > 343215259:Ypycub
> > 343215287:Ypycub
> > 357229759:Ypycub
> > 361836122:Ypycub
> > 367889650:Ypycub
> > 455348611:Ypycub
> > 455348639:Ypycub
> >
> >
> > C:\Python27\Volatility-1.3_Beta>python volatility strings -f
> > e:\tests\120225b\IRinfo\120225b.mem -s 120225b_Ypycub_offsets.txt
> >
> > Usage: strings [options] (see --help)
> > volatility: error: String file format invalid.
> >
> >
> > Thanks for any assistance.
> >
> > Mike
> >
> >
> >
> >
> >
> > _______________________________________________
> > Vol-users mailing list
> > Vol-users(a)volatilityfoundation.org
> > http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
> >
>
>
>
> --
> PGP Fingerprint: 2E87 17A1 EC10 1E3E 11D3 64C2 196B 2AB5 27A4 AC92
--
PGP Fingerprint: 2E87 17A1 EC10 1E3E 11D3 64C2 196B 2AB5 27A4 AC92
_______________________________________________
Vol-users mailing list
Vol-users(a)volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
1:09 p.m.
New subject: stings input file format question
Good idea! Just updated it :-)
On Wed, Feb 29, 2012 at 12:43 PM, Mike Lambert <dragonforen(a)hotmail.com> wrote:
Very cool. I looked at it. You might want to mention
that if they delete the
first line ("Offsets") and then Save As 'ANSI', that will solve the
problem.
It is now part of my process.
Thanks!
--
PGP Fingerprint: 2E87 17A1 EC10 1E3E 11D3 64C2 196B 2AB5 27A4 AC92
Date: Wed, 29 Feb 2012 12:37:02 -0500
Subject: Re: [Vol-users] stings input file format
question
From: jamie.levy(a)gmail.com
To: vol-users(a)volatilityfoundation.org
>
> Since someone requested it, I updated the Command Reference wiki to
> include info on using EnCase keywords for string offsets:
>
> http://code.google.com/p/volatility/wiki/CommandReference#strings
>
>
>
> On Mon, Feb 27, 2012 at 6:31 PM, Jamie Levy <jamie.levy(a)gmail.com> wrote:
> > Glad I could help!
> >
> > Yep, I've seen this before many times ;-)
> >
> > All the best,
> >
> > -gleeda
> >
> > ________________________________
> > From: Mike Lambert <dragonforen(a)hotmail.com>
> > Date: Mon, 27 Feb 2012 17:02:15 -0600
> > To: <jamie.levy(a)gmail.com>
> > Subject: RE: [Vol-users] stings input file format question
> >
> > My thanks! Well you called that one! I was using Encase's "Export"
to
> > output
> > a text file of the offsets of the hits from the search result tab.
> > Encase
> > outputs unicode text.
> > I just need to put a new step in the process, convert it to ANSI before
> > running it with the strings command.
> > And it does have a funky befinning of file marker....
> >
> > You must have seen this before?
> >
> > Best,
> > Mike
> >
> >> Date: Mon, 27 Feb 2012 16:39:08 -0500
> >> Subject: Re: [Vol-users] stings input file format question
> >> From: jamie.levy(a)gmail.com
> >> To: dragonforen(a)hotmail.com
> >>
> >> hrmmmmm I don't see anything obviously wrong here... But since you
> >> said these offsets are from EnCase, how were they obtained? By
> >> EnScript to a file, copy+paste from the console or some other method?
> >> I'm just curious if the offsets were exported in ASCII or EnCase's
> >> default UTF-16. Also sometimes when exporting in unicode, there's a
> >> funky corrupt BOM that EnCase uses that might be messing things up...
> >> I'm just trying to think of things that might have gone wrong here.
> >>
> >> Maybe you could try copy and pasting a few of these "Ypycub"
entries
> >> into a new text file and running the strings plugin again to see.
> >>
> >> All the best,
> >>
> >> -gleeda
> >>
> >>
> >> On Mon, Feb 27, 2012 at 4:06 PM, Mike Lambert
<dragonforen(a)hotmail.com>
> >> wrote:
> >> > I am mystified why I see the following: in one case I get output from
> >> > strings and the other I get an input file format error. I have tried
> >> > this
> >> > with 1.3 and 2.0 and get the same result. It takes 1.3 a looonnngg
> >> > time
> >> > to
> >> > return the error, 2.0 returs the error quickly.
> >> >
> >> > I thought the reason may be length, so I broke up the Ypycub offsets
> >> > into
> >> > increasingly smaller input files; no success was achived with the
> >> > smaller
> >> > input files.
> >> > I don't see a format difference in these 2 files.
> >> >
> >> > The offsets come from an Encase search of 120225b.mem. It is a 458MB
> >> > WinXPSP3x86 image converted from hiberfil.sys.
> >> >
> >> >
> >> > Vol 1.3 example: The same result is seen with Vol 2.0
> >> >
> >> > The input file is:
> >> >
> >> > 357229672:Glows
> >> > 280642408:Glows
> >> > 257105340:Glows
> >> > 113457472:Glows
> >> > 357230696:Glows
> >> >
> >> >
> >> > C:\Python27\Volatility-1.3_Beta>python volatility strings -f
> >> > e:\tests\120225b\IRinfo\120225b.mem -s 120225b_Glows_offsets.txt
> >> >
> >> > 357229672 [kernel:df864468 ] Glows
> >> > 280642408 [1456:45b8368 ] Glows
> >> > 257105340 [kernel:e1ec1dbc ] Glows
> >> > 113457472 [1456:2ac0940 ] Glows
> >> > 357230696 [kernel:df864868 ] Glows
> >> >
> >> > ----------------------cut-here-------------------------
> >> > The input file is:
> >> >
> >> > 7744388:Ypycub
> >> > 10830274:Ypycub
> >> > 70385414:Ypycub
> >> > 70918297:Ypycub
> >> > 70918649:Ypycub
> >> > 73375514:Ypycub
> >> > 91390974:Ypycub
> >> > 104879126:Ypycub
> >> > 104879154:Ypycub
> >> > 132968006:Ypycub
> >> > 215776800:Ypycub
> >> > 232868024:Ypycub
> >> > 232869190:Ypycub
> >> > 237434963:Ypycub
> >> > 237434991:Ypycub
> >> > 256642118:Ypycub
> >> > 285030170:Ypycub
> >> > 310449659:Ypycub
> >> > 310449687:Ypycub
> >> > 314178656:Ypycub
> >> > 325974496:Ypycub
> >> > 327972307:Ypycub
> >> > 327972335:Ypycub
> >> > 338814062:Ypycub
> >> > 338814854:Ypycub
> >> > 339229856:Ypycub
> >> > 339763304:Ypycub
> >> > 339763544:Ypycub
> >> > 339893168:Ypycub
> >> > 340101984:Ypycub
> >> > 343215259:Ypycub
> >> > 343215287:Ypycub
> >> > 357229759:Ypycub
> >> > 361836122:Ypycub
> >> > 367889650:Ypycub
> >> > 455348611:Ypycub
> >> > 455348639:Ypycub
> >> >
> >> >
> >> > C:\Python27\Volatility-1.3_Beta>python volatility strings -f
> >> > e:\tests\120225b\IRinfo\120225b.mem -s 120225b_Ypycub_offsets.txt
> >> >
> >> > Usage: strings [options] (see --help)
> >> > volatility: error: String file format invalid.
> >> >
> >> >
> >> > Thanks for any assistance.
> >> >
> >> > Mike
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > Vol-users mailing list
> >> > Vol-users(a)volatilityfoundation.org
> >> > http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
> >> >
> >>
> >>
> >>
> >> --
> >> PGP Fingerprint: 2E87 17A1 EC10 1E3E 11D3 64C2 196B 2AB5 27A4 AC92
>
>
>
> --
> PGP Fingerprint: 2E87 17A1 EC10 1E3E 11D3 64C2 196B 2AB5 27A4 AC92
> _______________________________________________
> Vol-users mailing list
> Vol-users(a)volatilityfoundation.org
> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
4642
days inactive
4644
days old
vol-users@lists.volatilityfoundation.org
3 comments
2 participants
participants (2)
-
Jamie Levy -
Mike Lambert