7:50 a.m.
Hello!
malfind found some suspicious regions and printed the disassembly so I went into volshell
to get more information, but what exactly can someone do with this disassembly? As far as
I know, there are no symbols, no way to view what is in the registers or these memory
addresses, and when I try to disassemble the few CALLs I can, I get a "Memory
unreadable" error.
>> dis(0x08070000,512)
0x8070000 55
PUSH EBP
0x8070001 8bec MOV EBP, ESP
0x8070003 83c4ec ADD ESP, -0x14
0x8070006 56 PUSH ESI
0x8070007 57 PUSH EDI
0x8070008 8b4508 MOV EAX, [EBP+0x8]
0x807000b 8bf0 MOV ESI, EAX
0x807000d 8d7dec LEA EDI, [EBP-0x14]
0x8070010 a5 MOVSD
0x8070011 a5 MOVSD
0x8070012 a5 MOVSD
0x8070013 a5 MOVSD
0x8070014 a5 MOVSD
0x8070015 ff75f8 PUSH DWORD [EBP-0x8]
0x8070018 ff55f4 CALL DWORD [EBP-0xc]
0x807001b ff75fc PUSH DWORD [EBP-0x4]
0x807001e 50 PUSH EAX
0x807001f ff55f0 CALL DWORD [EBP-0x10]
0x8070022 50 PUSH EAX
0x8070023 ff55ec CALL DWORD [EBP-0x14]
0x8070026 5f POP EDI
0x8070027 5e POP ESI
0x8070028 8be5 MOV ESP, EBP
0x807002a 5d POP EBP
0x807002b c20400 RET 0x4
0x807002e 8bc0 MOV EAX, EAX
0x8070030 53 PUSH EBX
0x8070031 56 PUSH ESI
0x8070032 57 PUSH EDI
0x8070033 55 PUSH EBP
0x8070034 83c4e8 ADD ESP, -0x18
0x8070037 8be9 MOV EBP, ECX
0x8070039 8bfa MOV EDI, EDX
0x807003b 8bd8 MOV EBX, EAX
0x807003d 33f6 XOR ESI, ESI
0x807003f 6800334000 PUSH DWORD 0x403300
0x8070044 6814334000 PUSH DWORD 0x403314
0x8070049 e85efaffff CALL 0x806faac
0x807004e 50 PUSH EAX
0x807004f e860faffff CALL 0x806fab4
0x8070054 8944240c MOV [ESP+0xc], EAX
0x8070058 6820334000 PUSH DWORD 0x403320
0x807005d 6814334000 PUSH DWORD 0x403314
0x8070062 e845faffff CALL 0x806faac
0x8070067 50 PUSH EAX
0x8070068 e847faffff CALL 0x806fab4
0x807006d 89442408 MOV [ESP+0x8], EAX
0x8070071 6830334000 PUSH DWORD 0x403330
0x8070076 6814334000 PUSH DWORD 0x403314
0x807007b e82cfaffff CALL 0x806faac
0x8070080 50 PUSH EAX
0x8070081 e82efaffff CALL 0x806fab4
0x8070086 89442404 MOV [ESP+0x4], EAX
0x807008a 8bd5 MOV EDX, EBP
0x807008c 8bc3 MOV EAX, EBX
0x807008e 0000 ADD [EAX], AL
0x8070090 0000 ADD [EAX], AL
0x8070092 0000 ADD [EAX], AL
0x8070094 0000 ADD [EAX], AL
0x8070096 0000 ADD [EAX], AL
0x8070098 0000 ADD [EAX], AL
0x807009a 0000 ADD [EAX], AL
0x807009c 0000 ADD [EAX], AL
0x807009e 0000 ADD [EAX], AL
[snip]
>> dis(0x806faac)
>> db(0x806faac)
Memory unreadable at 0806faac
>>
12:50 a.m.
The last set of registers used by a particular process will be saved
in some OS-specific method as that data is needed next time the
process is scheduled, with the correct information in the profile, you
should just be able to pull those values from Volatility. This will at
least give you a starting point and one set of registers.
You can also use this data to reconstruct a full or partial stack
backtrace, which may lead you on a better path of analysis,
particularly for single-threaded apps. To do this you need to know
some valid stack location (which you can get from the registers), and
the calling convention being used, which is usually easy enough to
figure out. From there you want to walk the stack backwards,
accounting for local variables and function parameters in order to
find saved return addresses, which will point you the functions you
want.
Assuming you have the correct dtb set, which will need to be done on a
per-process basis, then it means the address simply isn't mapped or
that you have some configuration wrong (maybe send your whole
session?)
If the binary has no symbols, both on-disk and/or in-memory then you
will need to find interesting code paths to analyze on your own, which
the stack backtrace method I discussed before may help.
On Sun, Apr 8, 2012 at 6:50 AM, fd ksdf <olroy123(a)yahoo.com> wrote:
Hello!
malfind found some suspicious regions and printed the disassembly so I went
into volshell to get more information, but what exactly can someone do with
this disassembly? As far as I know, there are no symbols, no way to view
what is in the registers or these memory addresses, and when I try to
disassemble the few CALLs I can, I get a "Memory unreadable" error.
>> dis(0x08070000,512)
0x8070000 55
PUSH EBP
0x8070001 8bec MOV EBP, ESP
0x8070003 83c4ec ADD ESP, -0x14
0x8070006 56 PUSH ESI
0x8070007 57 PUSH EDI
0x8070008 8b4508 MOV EAX, [EBP+0x8]
0x807000b 8bf0 MOV ESI, EAX
0x807000d 8d7dec LEA EDI, [EBP-0x14]
0x8070010 a5 MOVSD
0x8070011 a5 MOVSD
0x8070012 a5 MOVSD
0x8070013 a5 MOVSD
0x8070014 a5 MOVSD
0x8070015 ff75f8 PUSH DWORD [EBP-0x8]
0x8070018 ff55f4 CALL DWORD [EBP-0xc]
0x807001b ff75fc PUSH DWORD [EBP-0x4]
0x807001e 50 PUSH EAX
0x807001f ff55f0 CALL DWORD [EBP-0x10]
0x8070022 50 PUSH EAX
0x8070023 ff55ec CALL DWORD [EBP-0x14]
0x8070026 5f POP EDI
0x8070027 5e POP ESI
0x8070028 8be5 MOV ESP, EBP
0x807002a 5d POP EBP
0x807002b c20400 RET 0x4
0x807002e 8bc0 MOV EAX, EAX
0x8070030 53 PUSH EBX
0x8070031 56 PUSH ESI
0x8070032 57 PUSH EDI
0x8070033 55 PUSH EBP
0x8070034 83c4e8 ADD ESP, -0x18
0x8070037 8be9 MOV EBP, ECX
0x8070039 8bfa MOV EDI, EDX
0x807003b 8bd8 MOV EBX, EAX
0x807003d 33f6 XOR ESI, ESI
0x807003f 6800334000 PUSH DWORD 0x403300
0x8070044 6814334000 PUSH DWORD 0x403314
0x8070049 e85efaffff CALL 0x806faac
0x807004e 50 PUSH EAX
0x807004f e860faffff CALL 0x806fab4
0x8070054 8944240c MOV [ESP+0xc], EAX
0x8070058 6820334000 PUSH DWORD 0x403320
0x807005d 6814334000 PUSH DWORD 0x403314
0x8070062 e845faffff CALL 0x806faac
0x8070067 50 PUSH EAX
0x8070068 e847faffff CALL 0x806fab4
0x807006d 89442408 MOV [ESP+0x8], EAX
0x8070071 6830334000 PUSH DWORD 0x403330
0x8070076 6814334000 PUSH DWORD 0x403314
0x807007b e82cfaffff CALL 0x806faac
0x8070080 50 PUSH EAX
0x8070081 e82efaffff CALL 0x806fab4
0x8070086 89442404 MOV [ESP+0x4], EAX
0x807008a 8bd5 MOV EDX, EBP
0x807008c 8bc3 MOV EAX, EBX
0x807008e 0000 ADD [EAX], AL
0x8070090 0000 ADD [EAX], AL
0x8070092 0000 ADD [EAX], AL
0x8070094 0000 ADD [EAX], AL
0x8070096 0000 ADD [EAX], AL
0x8070098 0000 ADD [EAX], AL
0x807009a 0000 ADD [EAX], AL
0x807009c 0000 ADD [EAX], AL
0x807009e 0000 ADD [EAX], AL
[snip]
>> dis(0x806faac)
>> db(0x806faac)
Memory unreadable at 0806faac
>>
_______________________________________________
Vol-users mailing list
Vol-users(a)volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
10:07 a.m.
Hello,
On Sun, Apr 8, 2012 at 7:50 AM, fd ksdf <olroy123(a)yahoo.com> wrote:
Hello!
malfind found some suspicious regions and printed the disassembly so I went
into volshell to get more information, but what exactly can someone do with
this disassembly?
The same thing anyone ever does with a disassembly ;-)
Malfind will locate private (i.e. not backed by a file, no DLL),
committed, executable memory, but interpretation of the instructions
is up to a human.
As Andrew said yesterday, your best bet is to find some code paths
that lead to the region in question. Thread registers at the time of
the memory dump may be available in _ETHREAD.Tcb.TrapFrame (see
"Investigating Windows Threads with Volatility" [1]) which may help
you reconstruct some state, and Carl Pulley's stack backtrace plugin
[2] can give you some guidance.
Regarding symbols, if the memory you're analyzing is part of a dll,
exe, sys, then extract the PE with dlldump, procexedump, or moddump
respectively and look at the debug section to get the PDB path which
will give you symbols (or just load the extracted PE in IDA Pro and
let it resolve the symbols for you). If the memory you're analyzing is
*not* part of a dll, exe, sys (for example shell code or a block of
injected functions) then you can't expect to have symbols anyway
(though it'd be cool if attackers supplied symbols with shell code
;-))
The memory unreadable error is because 0x806f000-0x806ffff is paged to
disk (i.e. not memory resident at the time the dump was acquired).
Luckily, most malicious code spans more than two pages (0x2000) so
don't be discouraged by one missing page. Instead, dump the whole vad
region (using the vaddump command) and analyze it as a whole. What you
see below is just the instructions at the start of the range
0x8070000, not the whole thing.
Also if this is injected code, there's a chance its been injected into
more than one process, so you might check if the missing page is
available in the memory of another process.
Hope it helps and good luck!
MHL
[1]. http://mnin.blogspot.com/2011/04/investigating-windows-threads-with.html
[2]. https://github.com/carlpulley/volatility/blob/master/exportstack.py
As far as I know, there are no symbols, no way to view
what is in the registers or these memory addresses, and when I try to
disassemble the few CALLs I can, I get a "Memory unreadable" error.
>> dis(0x08070000,512)
0x8070000 55
PUSH EBP
0x8070001 8bec MOV EBP, ESP
0x8070003 83c4ec ADD ESP, -0x14
0x8070006 56 PUSH ESI
0x8070007 57 PUSH EDI
0x8070008 8b4508 MOV EAX, [EBP+0x8]
0x807000b 8bf0 MOV ESI, EAX
0x807000d 8d7dec LEA EDI, [EBP-0x14]
0x8070010 a5 MOVSD
0x8070011 a5 MOVSD
0x8070012 a5 MOVSD
0x8070013 a5 MOVSD
0x8070014 a5 MOVSD
0x8070015 ff75f8 PUSH DWORD [EBP-0x8]
0x8070018 ff55f4 CALL DWORD [EBP-0xc]
0x807001b ff75fc PUSH DWORD [EBP-0x4]
0x807001e 50 PUSH EAX
0x807001f ff55f0 CALL DWORD [EBP-0x10]
0x8070022 50 PUSH EAX
0x8070023 ff55ec CALL DWORD [EBP-0x14]
0x8070026 5f POP EDI
0x8070027 5e POP ESI
0x8070028 8be5 MOV ESP, EBP
0x807002a 5d POP EBP
0x807002b c20400 RET 0x4
0x807002e 8bc0 MOV EAX, EAX
0x8070030 53 PUSH EBX
0x8070031 56 PUSH ESI
0x8070032 57 PUSH EDI
0x8070033 55 PUSH EBP
0x8070034 83c4e8 ADD ESP, -0x18
0x8070037 8be9 MOV EBP, ECX
0x8070039 8bfa MOV EDI, EDX
0x807003b 8bd8 MOV EBX, EAX
0x807003d 33f6 XOR ESI, ESI
0x807003f 6800334000 PUSH DWORD 0x403300
0x8070044 6814334000 PUSH DWORD 0x403314
0x8070049 e85efaffff CALL 0x806faac
0x807004e 50 PUSH EAX
0x807004f e860faffff CALL 0x806fab4
0x8070054 8944240c MOV [ESP+0xc], EAX
0x8070058 6820334000 PUSH DWORD 0x403320
0x807005d 6814334000 PUSH DWORD 0x403314
0x8070062 e845faffff CALL 0x806faac
0x8070067 50 PUSH EAX
0x8070068 e847faffff CALL 0x806fab4
0x807006d 89442408 MOV [ESP+0x8], EAX
0x8070071 6830334000 PUSH DWORD 0x403330
0x8070076 6814334000 PUSH DWORD 0x403314
0x807007b e82cfaffff CALL 0x806faac
0x8070080 50 PUSH EAX
0x8070081 e82efaffff CALL 0x806fab4
0x8070086 89442404 MOV [ESP+0x4], EAX
0x807008a 8bd5 MOV EDX, EBP
0x807008c 8bc3 MOV EAX, EBX
0x807008e 0000 ADD [EAX], AL
0x8070090 0000 ADD [EAX], AL
0x8070092 0000 ADD [EAX], AL
0x8070094 0000 ADD [EAX], AL
0x8070096 0000 ADD [EAX], AL
0x8070098 0000 ADD [EAX], AL
0x807009a 0000 ADD [EAX], AL
0x807009c 0000 ADD [EAX], AL
0x807009e 0000 ADD [EAX], AL
[snip]
>> dis(0x806faac)
>> db(0x806faac)
Memory unreadable at 0806faac
>>
_______________________________________________
Vol-users mailing list
Vol-users(a)volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
9:43 p.m.
Thanks for the thorough replies! I should of known part of it got paged. That's
probably a sign I need to finish reading Windows Internals. :)
This is the first piece of malware I'm analyzing and I loaded it into Olly today and
could see it decrypting a PE file from the the resource section. Pretty freaking cool!
I'll play around with Volatility again tomorrow...
Thanks again for setting me straight!
________________________________
From: Michael Hale Ligh <michael.hale(a)gmail.com>
To: fd ksdf <olroy123(a)yahoo.com>
Cc: "vol-users(a)volatilityfoundation.org"
<vol-users(a)volatilityfoundation.org>
Sent: Monday, April 9, 2012 10:07 AM
Subject: Re: [Vol-users] Analyzing diasassembly with little information
Hello,
The same thing anyone ever does with a disassembly ;-)
Malfind will locate private (i.e. not backed by a file, no DLL),
committed, executable memory, but interpretation of the instructions
is up to a human.
As Andrew said yesterday, your best bet is to find some code paths
that lead to the region in question. Thread registers at the time of
the memory dump may be available in _ETHREAD.Tcb.TrapFrame (see
"Investigating Windows Threads with Volatility" [1]) which may help
you reconstruct some state, and Carl Pulley's stack backtrace plugin
[2] can give you some guidance.
Regarding symbols, if the memory you're analyzing is part of a dll,
exe, sys, then extract the PE with dlldump, procexedump, or moddump
respectively and look at the debug section to get the PDB path which
will give you symbols (or just load the extracted PE in IDA Pro and
let it resolve the symbols for you). If the memory you're analyzing is
*not* part of a dll, exe, sys (for example shell code or a block of
injected functions) then you can't expect to have symbols anyway
(though it'd be cool if attackers supplied symbols with shell code
;-))
The memory unreadable error is because 0x806f000-0x806ffff is paged to
disk (i.e. not memory resident at the time the dump was acquired).
Luckily, most malicious code spans more than two pages (0x2000) so
don't be discouraged by one missing page. Instead, dump the whole vad
region (using the vaddump command) and analyze it as a whole. What you
see below is just the instructions at the start of the range
0x8070000, not the whole thing.
Also if this is injected code, there's a chance its been injected into
more than one process, so you might check if the missing page is
available in the memory of another process.
Hope it helps and good luck!
MHL
_______________________________________________
Vol-users mailing list
Vol-users(a)volatilityfoundation.org
http://lists.volatilesystems.com/mailman/listinfo/vol-users
4740
days inactive
4743
days old
vol-users@lists.volatilityfoundation.org
3 comments
3 participants
participants (3)
-
Andrew Case -
fd ksdf -
Michael Hale Ligh