Investigate around a memory area

newer

older

windows plugin - handles - what...

Re: [Vol-users] Analyzing memory...

Massimo Canonico

9 May 2016 9 May '16

11:32 a.m.

Hi all, I'm quite sure that there is a "standard procedure" in order to investigate a specific area of the memory once you found something useful in a specific address, but my research on volatility doc does not help me much. Here the problem. I was able to find out with yarascan and -W option (Andrew and Michael, thanks again!), where the password of a specific app is stored (see after my signature for the complete yarascan output). From this output, I can see that the password is stored from address 0xb2f771f0. I would like to see: - what is stored before the password - if this memory area is related to a specific file In other words, I would like to investigate how the app stored the password hoping that the password is always store with some criteria. Of course, I have several memory dumps, with different passwords set. The yarascan outputs (that shows me only something *after *the password) do not help me. Thanks in advance for all your help, Massimo (Here is the yarascan output. The password set is "mypassword2016") Task: ject.otr.app.im pid 1691 rule r1 addr 0xb2f771f0 0xb2f771f0 6d 00 79 00 70 00 61 00 73 00 73 00 77 00 6f 00 m.y.p.a.s.s.w.o. 0xb2f77200 72 00 64 00 32 00 30 00 31 00 36 00 00 00 00 00 r.d.2.0.1.6..... 0xb2f77210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f77220 00 00 00 00 43 04 00 00 f0 4a b5 b2 00 00 00 00 ....C....J...... 0xb2f77230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f77240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f77250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f77260 08 ff f9 b2 00 00 00 00 00 00 00 00 78 df fa b2 ............x... 0xb2f77270 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f77280 38 47 ef b2 f0 e8 d8 b2 68 76 f7 b2 00 00 00 00 8G......hv...... 0xb2f77290 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f772a0 00 00 00 00 00 ed f1 b2 68 9c f9 b2 00 00 00 00 ........h....... 0xb2f772b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f772c0 d8 e4 e2 b2 00 00 00 00 68 01 00 00 00 00 00 00 ........h....... 0xb2f772d0 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ................ 0xb2f772e0 ff ff ff ff ff ff ff ff a6 02 00 80 68 01 00 40 ............h..@

Attachments:

attachment.html (text/html — 3.0 KB)

Show replies by date

9 May 9 May

12:33 p.m.

Hi Massimo, Why you don't use volshell if you have the offset ? Chakib

...

Le 9 mai 2016 à 17:32, Massimo Canonico <mex(a)di.unipmn.it> a écrit : Hi all, I'm quite sure that there is a "standard procedure" in order to investigate a specific area of the memory once you found something useful in a specific address, but my research on volatility doc does not help me much. Here the problem. I was able to find out with yarascan and -W option (Andrew and Michael, thanks again!), where the password of a specific app is stored (see after my signature for the complete yarascan output). From this output, I can see that the password is stored from address 0xb2f771f0. I would like to see: - what is stored before the password - if this memory area is related to a specific file In other words, I would like to investigate how the app stored the password hoping that the password is always store with some criteria. Of course, I have several memory dumps, with different passwords set. The yarascan outputs (that shows me only something after the password) do not help me. Thanks in advance for all your help, Massimo (Here is the yarascan output. The password set is "mypassword2016") Task: ject.otr.app.im pid 1691 rule r1 addr 0xb2f771f0 0xb2f771f0 6d 00 79 00 70 00 61 00 73 00 73 00 77 00 6f 00 m.y.p.a.s.s.w.o. 0xb2f77200 72 00 64 00 32 00 30 00 31 00 36 00 00 00 00 00 r.d.2.0.1.6..... 0xb2f77210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f77220 00 00 00 00 43 04 00 00 f0 4a b5 b2 00 00 00 00 ....C....J...... 0xb2f77230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f77240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f77250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f77260 08 ff f9 b2 00 00 00 00 00 00 00 00 78 df fa b2 ............x... 0xb2f77270 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f77280 38 47 ef b2 f0 e8 d8 b2 68 76 f7 b2 00 00 00 00 8G......hv...... 0xb2f77290 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f772a0 00 00 00 00 00 ed f1 b2 68 9c f9 b2 00 00 00 00 ........h....... 0xb2f772b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f772c0 d8 e4 e2 b2 00 00 00 00 68 01 00 00 00 00 00 00 ........h....... 0xb2f772d0 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ................ 0xb2f772e0 ff ff ff ff ff ff ff ff a6 02 00 80 68 01 00 40 ............h..@ _______________________________________________ Vol-users mailing list Vol-users(a)volatilityfoundation.org http://lists.volatilityfoundation.org/mailman/listinfo/vol-users

Bridgey theGeek

6:58 p.m.

Massimo, You are essentially asking the question, "I've found something important in memory. How do I know what it means?" It's the question we all ask, so welcome to the club! :) There's (probably) no easy answer I'm afraid. MHL's suggestion of reading 'The Art of Memory Forensics' is an important one. (And there's of course the Volatility training courses.) As a quick try, you could use the vadinfo plugin with the --addr parameter. You might get luck with your memory address being mapped to a file. Even if it's not mapped to a file, focusing on a specific VAD might help you figure out what's going on. Good luck! Adam On 9 May 2016 at 17:33, Te <tecko92(a)gmail.com> wrote:

...

Hi Massimo, Why you don't use volshell if you have the offset ? Chakib Le 9 mai 2016 à 17:32, Massimo Canonico <mex(a)di.unipmn.it> a écrit : Hi all, I'm quite sure that there is a "standard procedure" in order to investigate a specific area of the memory once you found something useful in a specific address, but my research on volatility doc does not help me much. Here the problem. I was able to find out with yarascan and -W option (Andrew and Michael, thanks again!), where the password of a specific app is stored (see after my signature for the complete yarascan output). From this output, I can see that the password is stored from address 0xb2f771f0. I would like to see: - what is stored before the password - if this memory area is related to a specific file In other words, I would like to investigate how the app stored the password hoping that the password is always store with some criteria. Of course, I have several memory dumps, with different passwords set. The yarascan outputs (that shows me only something *after *the password) do not help me. Thanks in advance for all your help, Massimo (Here is the yarascan output. The password set is "mypassword2016") Task: ject.otr.app.im pid 1691 rule r1 addr 0xb2f771f0 0xb2f771f0 6d 00 79 00 70 00 61 00 73 00 73 00 77 00 6f 00 m.y.p.a.s.s.w.o. 0xb2f77200 72 00 64 00 32 00 30 00 31 00 36 00 00 00 00 00 r.d.2.0.1.6..... 0xb2f77210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f77220 00 00 00 00 43 04 00 00 f0 4a b5 b2 00 00 00 00 ....C....J...... 0xb2f77230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f77240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f77250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f77260 08 ff f9 b2 00 00 00 00 00 00 00 00 78 df fa b2 ............x... 0xb2f77270 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f77280 38 47 ef b2 f0 e8 d8 b2 68 76 f7 b2 00 00 00 00 8G......hv...... 0xb2f77290 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f772a0 00 00 00 00 00 ed f1 b2 68 9c f9 b2 00 00 00 00 ........h....... 0xb2f772b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f772c0 d8 e4 e2 b2 00 00 00 00 68 01 00 00 00 00 00 00 ........h....... 0xb2f772d0 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ................ 0xb2f772e0 ff ff ff ff ff ff ff ff a6 02 00 80 68 01 00 40 ............h..@ _______________________________________________ Vol-users mailing list Vol-users(a)volatilityfoundation.org http://lists.volatilityfoundation.org/mailman/listinfo/vol-users _______________________________________________ Vol-users mailing list Vol-users(a)volatilityfoundation.org http://lists.volatilityfoundation.org/mailman/listinfo/vol-users

Michael Ligh

7:05 p.m.

Thanks Adam! Vadinfo is a good one, however its for Windows, so use linux_proc_maps for Linux systems or mac_proc_maps for Mac. MHL On 5/9/16 3:58 PM, Bridgey theGeek wrote:

...

Hi all, I'm quite sure that there is a "standard procedure" in order to investigate a specific area of the memory once you found something useful in a specific address, but my research on volatility doc does not help me much. Here the problem. I was able to find out with yarascan and -W option (Andrew and Michael, thanks again!), where the password of a specific app is stored (see after my signature for the complete yarascan output). From this output, I can see that the password is stored from address 0xb2f771f0. I would like to see: - what is stored before the password - if this memory area is related to a specific file In other words, I would like to investigate how the app stored the password hoping that the password is always store with some criteria. Of course, I have several memory dumps, with different passwords set. The yarascan outputs (that shows me only something *after *the password) do not help me. Thanks in advance for all your help, Massimo (Here is the yarascan output. The password set is "mypassword2016") Task: ject.otr.app.im <http://ject.otr.app.im> pid 1691 rule r1 addr 0xb2f771f0 0xb2f771f0 6d 00 79 00 70 00 61 00 73 00 73 00 77 00 6f 00 m.y.p.a.s.s.w.o. 0xb2f77200 72 00 64 00 32 00 30 00 31 00 36 00 00 00 00 00 r.d.2.0.1.6..... 0xb2f77210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f77220 00 00 00 00 43 04 00 00 f0 4a b5 b2 00 00 00 00 ....C....J...... 0xb2f77230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f77240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f77250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f77260 08 ff f9 b2 00 00 00 00 00 00 00 00 78 df fa b2 ............x... 0xb2f77270 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f77280 38 47 ef b2 f0 e8 d8 b2 68 76 f7 b2 00 00 00 00 8G......hv...... 0xb2f77290 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f772a0 00 00 00 00 00 ed f1 b2 68 9c f9 b2 00 00 00 00 ........h....... 0xb2f772b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xb2f772c0 d8 e4 e2 b2 00 00 00 00 68 01 00 00 00 00 00 00 ........h....... 0xb2f772d0 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ................ 0xb2f772e0 ff ff ff ff ff ff ff ff a6 02 00 80 68 01 00 40 ............h..@ _______________________________________________ Vol-users mailing list Vol-users(a)volatilityfoundation.org <mailto:Vol-users@volatilesystems.com> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users

_______________________________________________ Vol-users mailing list Vol-users(a)volatilityfoundation.org <mailto:Vol-users@volatilityfoundation.org> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users _______________________________________________ Vol-users mailing list Vol-users(a)volatilityfoundation.org http://lists.volatilityfoundation.org/mailman/listinfo/vol-users

Michael Ligh

12:37 p.m.

The -R (reverse) and -s (size) options to yarascan will let you specify the amount of data in the preview and where to start previewing (i.e. 512 bytes behind the hit). Otherwise, you can use volshell to interactively explore memory. Note the cc() option in volshell to change contexts into a particular process's private address space. The Art of Memory Forensics book is a good resource to pick up on Volatility commands. Cheers, MHL On 5/9/16 8:32 AM, Massimo Canonico wrote:

...

3466

days inactive

3466

days old

vol-users@lists.volatilityfoundation.org

Manage subscription

4 comments

4 participants

tags (0)

participants (4)

Bridgey theGeek
Massimo Canonico
Michael Ligh
Te