Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automagic exception: Missing _ETHREAD kernel symbol for Win10x64_17134 memory image #135

Closed
johnlabuyfoy1024 opened this issue Nov 12, 2019 · 6 comments

Comments

@johnlabuyfoy1024
Copy link

volatility version = Volatility 3 Framework 1.0.0-beta.1
OS used to run Volatility = Linux kali 5.3.0-kali1-amd64 #1 SMP Debian 5.3.7-kali2 (2019-11-04) x86_64 GNU/Linux
Python version = Python 3.7.5
OS of target memory sample = Win10x64_17134
Command line = python3 vol.py -f /mnt/Labs/GBAKER-10L/data.lime windows.pslist.PsList

Error message =
Volatility 3 Framework 1.0.0-beta.1
WARNING volatility.framework.plugins: Automagic exception occured: ValueError: Symbol type not in nt_symbols1 SymbolTable: _ETHREAD

Unsatisfied requirement plugins.PsList.nt_symbols: Windows kernel symbols

A symbol table requirement was not fulfilled. Please verify that:
You have the correct symbol file for the requirement
The symbol file is under the correct directory or zip file
The symbol file is named appropriately or contains the correct banner

NOTE: I was able to successfully run the above command line on a different Windows 7 memory image. So, the https://downloads.volatilityfoundation.org/volatility3/symbols/windows.zip file was installed correctly.

@ikelos
Copy link
Member

ikelos commented Nov 12, 2019

Hiya, Thanks for the report! From the looks of it, the symbol table is the heart of the problem. It would help us to figure out what went wrong in this specific case if you could paste the output from running it with vol.py -vv rather than just vol.py. The exact line we're interested in would be one that looks something like:

DEBUG    volatility.framework.automagic.pdbscan: Using symbol library: ntkrnlpa.pdb/BD8F451F3E754ED8A34B50560CEB08E3-1

That will tell us which symbol table we're looking for. It's definitely a known issue that certain kernel symbol files that Microsoft publishes aren't complete (for example, I have a system with the above signature, that we do have symbols for in the symbol pack, but if you try to download them manually, the pdb no longer contains all the necessary data, and it comes up with the same warning you've encountered).

Once we know which symbol table it's trying to use we can examine the one in the pack, or even if it exists in the pack and figure out if we can create symbols for it or not... 5:)

@mattwhatkins
Copy link

mattwhatkins commented Nov 13, 2019

I have a Win10x64_18362 image and I'm getting the same issue. I tried downloading the symbols and extracting them manually, but I get the same error. This is a test VM so happy to perform any debugging steps on the live host.

DEBUG    volatility.framework.automagic.pdbscan: Using symbol library: ntkrnlmp.pdb/E0093F3AEF15D58168B753C9488A4043-1
Level 9  volatility.framework.configuration.requirements: TypeError - SymbolTableRequirement only accepts string labels: None
WARNING  volatility.framework.plugins: Automagic exception occured: ValueError: Symbol type not in nt_symbols1 SymbolTable: _ETHREAD

Let me know if you'd rather I create a separate issue for this

@ikelos
Copy link
Member

ikelos commented Nov 13, 2019

Errr, leave it in this thread for the moment please. So E0093F3AEF15D58168B753C9488A4043-1 doesn't produce any types, only symbols. I need to check if that's an issue with the pdb file (in which case there's not much we can do) or whether the pdb converter is just missing a bunch of types...

ikelos added a commit that referenced this issue Nov 13, 2019
Turns out that #133 exposed a mistake in how we were using the end_bit
field (and it should have been picked up in review, my bad).
Essentially we were masking based on the length of the end_bit after
*already* shifting by the start_bit.  We should mask then shift, not the
other way around.

May well fix issue #135 (pdb generation will have been affected by
this).
@ikelos
Copy link
Member

ikelos commented Nov 13, 2019

So it turns out this was due to a recent pull request that I didn't properly review (I checked the code, which was right, but completely missed that we did things in the wrong order already and it just so happened it worked out fine because of the mistake which #133 correctly fixed).

Unfortunately, this means that some generated symbol tables will now be invalid and will need to be re-generated. Please clear out your volatility/symbols/windows directory (the windows.zip file should be fine, and you can re-unpack the contents of that if you unpacked it in the first place.

Any windows JSON symbol files generated in the last couple of days will need to be removed and will be rebuilt from the internet.

Please could you test this? @mattwhatkins I know this will fix your issue, @johnlabuyfoy1024 I suspect this will fix yours but I never found out which PDB you were testing it against...

I leave this open for a week or so unless I get told otherwise, in case someone's still experiencing it even with the fix from commit 648cded5...

@mattwhatkins
Copy link

This works for me, windows.info and pstree coming back OK now :) (Malfind is erroring, so I'll see if I can work that out, otherwise submit a separate bug report)

Thanks!

@johnlabuyfoy1024
Copy link
Author

My issue is now resolved after downloading & installing the latest windows.zip from https://downloads.volatilityfoundation.org/volatility3/symbols/windows.zip

PID PPID ImageFileName Offset(V) Threads Handles SessionId Wow64 CreateTime ExitTime

4 0 System 0xd10263712440 196 - N/A False 2019-08-14 18:27:46.000000 N/A
96 4 Registry 0xd102637e4040 3 - N/A False 2019-08-14 18:27:44.000000 N/A
448 4 smss.exe 0xd102768ef040 5 - N/A False 2019-08-14 18:27:46.000000 N/A
716 544 csrss.exe 0xd10277dab280 13 - 0 False 2019-08-14 18:27:50.000000 N/A
804 544 wininit.exe 0xd10278867080 5 - 0 False 2019-08-14 18:27:51.000000 N/A
812 796 csrss.exe 0xd1027886c080 14 - 1 False 2019-08-14 18:27:51.000000 N/A
884 804 services.exe 0xd1027883b580 21 - 0 False 2019-08-14 18:27:51.000000 N/A
916 796 winlogon.exe 0xd102788e3340 5 - 1 False 2019-08-14 18:27:51.000000 N/A
980 804 lsass.exe 0xd1027886a080 13 - 0 False 2019-08-14 18:27:51.000000 N/A

Thank you ikelos!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants