Comments (13)
Original comment by [email protected]
on 26 Aug 2010 at 11:29
from volatility.
Hey guys,
I was able to get the ssdt plugin working for Win7. Here's what I did:
1) From ssdt.ssdt_types, I removed the following lines and added them to
xp_sp2_x86_vtypes.py:
# '_ETHREAD' : [ None, {
# 'ThreadListEntry' : [ 0x22c, ['_LIST_ENTRY']],
#} ],
# '_KTHREAD' : [ None, {
# 'ServiceTable' : [ 0xe0, ['pointer', ['_SERVICE_DESCRIPTOR_TABLE']]],
#} ],
The proper offsets for XPSP3, Vista, and 7 are already in their respective
files, so they are OK. However, I had to change the ServiceTable from
pointer->void to pointer->_SERVICE_DESCRIPTOR_TABLE in all of them.
2) Changed ssdt.syscalls into a list of dictionaries, similar to this:
http://miscellaneouz.googlecode.com/svn/trunk/winsyscalls/winsyscalls.py. I
modified that a tiny bit so there is one entry for each table (so syscalls[0]
is for native and syscalls[1] is for gui). The dic keys are syscall names, and
the values are lists of SSDT function indexes for various OSs. The index is -1
if a given function doesn't exist in the SSDT for an OS.
3) The proper values are chosen based on the Volatility profile in use. I
really don't know if this is how you want to keep it, so I haven't filled in
the win32k info yet.
4) In the attached ssdt.py there are a few other mods - one for speed and one
for some extra sanity checks.
Thoughts?
Original comment by [email protected]
on 11 Nov 2010 at 8:52
Attachments:
from volatility.
Is there any way to pull the SSDT from the pdb files?
Original comment by [email protected]
on 11 Nov 2010 at 9:18
from volatility.
BDG has a script
(http://code.google.com/p/pdbparse/source/browse/get_syscall_table.py?spec=svn55
&r=55) which seems to work, at least for the XPSP3 system that I used for
testing:
$ python get_syscall_table.py ntoskrnl.exe ntoskrnl.pdb
Ordinal 0x0000 Name: NtAcceptConnectPort Args: 6 (0x18 bytes) Offset: 0xb21f1
Ordinal 0x0001 Name: NtAccessCheck Args: 8 (0x20 bytes) Offset: 0xa22d1
Ordinal 0x0002 Name: NtAccessCheckAndAuditAlarm Args: 11 (0x2c bytes) Offset:
0xb55e8
[...]
This tool requires the NT and Win32k files though (not just the PDBs). I'm not
sure if there's a way to pull straight from the PDB.
Original comment by [email protected]
on 11 Nov 2010 at 11:07
from volatility.
You can pull the SSDT from a combination of the PE and PDB for ntoskrnl or
win32k. Basically, you find the offset of KiServiceTable or W32pServiceTable
using the PDB, then go look in the PE file for that table.
KiServiceLimit/W32pServiceLimit will then tell you how many entries to read.
These are the pointers to the system calls themselves, and you can then look up
the symbol associated with that address to get the name of the system call.
I have a script that does this, but I have only tested it on XP 32 bit:
http://code.google.com/p/pdbparse/source/browse/get_syscall_table.py
Original comment by [email protected]
on 11 Nov 2010 at 11:09
from volatility.
I just tested with ntoskrnl.exe/ntkrnlmp.pdb from a Win7 machine and it worked
fine. So what should we do here...gather the exe and pdb files from the NT
module and Win32k module from all OS's we want the ssdt module to support? Put
them in some location that everyone can access?
Any comments on the format of the ssdt.syscalls...should it be kept as I have
it or should the lists be separated into profiles?
Original comment by [email protected]
on 11 Nov 2010 at 11:23
from volatility.
I'm just making my way through the code, so I'm still learning exactly what the
SSDT is and how it works, but it strikes me that if the data's per profile, we
should probably store it per-profile, and if it's per-DLL-per-profile then we
should probably still have it split into per profile data. It's only if the
data's shared across profiles that it might be work keeping it all together.
If it's going to be a core plugin, then it's not a problem keeping it in the
non-generated areas, until we can ensure automatic generation (like the vtypes
at the moment).
If we think that'll be hard to manage, or that automatic generation isn't on
the cards, then it might be worth having SSDT data tables (again per profile),
which can be read in by the plugin from a resource directory somewhere (or just
more python files if people are happy with that).
Original comment by [email protected]
on 11 Nov 2010 at 11:28
from volatility.
Also, just to mention, this might tie in with issue 6, in that both need a way
of storing offsets/data from specific EXEs/DLLs. I was envisaging doing that
through volatiltity magic constants, but I haven't decided if that's the best
way or whether there should be some special storage system for multiple options
per profile (different DLLs on essentially the same system)...
Original comment by [email protected]
on 11 Nov 2010 at 11:30
from volatility.
Ok, so (since I seem to have forgotten to say it in my first comments), great
work! 5:) I've integrated some of the changes from your file. Until we get
the XPSP2 autogenerated files, I've included the two bits that *would* be
autogenerated into the current XPSP2 profile.
I've left the ServiceTable entry as a pointer to void, since that's what the
other autogenerated values will show. We've got two options:
* the first is to overlay on top of the profiles, changing the pointer to void
to a pointer to _SERVICE_DESCRIPTOR_TABLE, but then we'll need to include the
_SERVICE_DESCRIPTOR_TABLE for each profile.
* If the structures are the same for every profile, then the better (and
current option), is to use dereference_as on the pointer, rather than just
dereference.
Finally I added the additional checks (such as checking ServiceLimit, etc), so
thanks for those!
Once we figure out the best format for storing the tables, we can get the it
all integrated, and have another multi-platform plugin! Yay! 5:)
Original comment by [email protected]
on 12 Nov 2010 at 12:42
from volatility.
Excellent, this sounds good. As far as I know, _SERVICE_DESCRIPTOR_TABLE is the
same on all platforms, so dereference_as may be the best fit. Thanks!
Original comment by [email protected]
on 12 Nov 2010 at 2:36
from volatility.
Original comment by [email protected]
on 23 Nov 2010 at 8:45
from volatility.
This is just about done, pending a few minutes of verification tomorrow. By
noon we should have patches so that ssdt works accurately on all profiles for
which Volatility current supports.
Original comment by [email protected]
on 21 Jan 2011 at 6:36
from volatility.
Excellent, all committed (r603) after splitting out the tables (since they
rather swamp the profile itself, which I'd like to keep a clear list of the
tweaks required). That's another one... FIXED! 5:)
Original comment by [email protected]
on 21 Jan 2011 at 9:03
- Changed state: Fixed
from volatility.
Related Issues (20)
- python tools/mac/convert.py converted-10.9.4.64bit.dwarfdump > 10.9.4.64bit.vtypes results in KeyError: 'AT_data_member_location' HOT 3
- Volatility 2.4 fails to decompress win8 hiberfil.sys HOT 2
- Cannot run the 'make' command HOT 19
- Unable to obtain password hashes HOT 1
- KiFastSystemCall I want to know where is next step? HOT 2
- Error when I make profile in Window 8 Pro (64 bits) HOT 1
- Except psscan no other cmds are working HOT 1
- Getting several "no such option" errors HOT 1
- Volatility was functioning, now errors out HOT 1
- Running VF from Jython HOT 2
- Failed to import volatility.plugins.overlays.linux.linux (ValueError: too many values to unpack) HOT 2
- File new issues on github: https://github.com/volatilityfoundation/volatility/issues HOT 17
- yarascan fails to ececute grep expression (attached) HOT 4
- imageinfo takes forever HOT 1
- How to know the device is using by how many processes in the computer system ? HOT 1
- Error adding new plugin in 2.3.1 HOT 2
- Cant run volatility command Pslist from Eclipse(python IDE) HOT 1
- "This command does not support the profile" Error HOT 1
- Volatility Standalone for Windows incorrectly states profile is invalid HOT 2
- Volatility /tools/linux 'make' not working
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from volatility.