output not to stdout? driver not loading

[EricZimmerman]

in KAPE, we have a module for winpmem, but it is running and exiting immediately. i do not see any info being dumped to the console tho. when i run it directly, i get this output:

this is with 3.2, but 3.3 does the same thing.

any ideas? is winpmem writing to stdout?

[scudette]

Your error indicates that it can not start the driver. Are you running as admin?

What os version is this?

On Sat, Jul 13, 2019, 07:12 Eric notifications@github.com wrote:

in KAPE, we have a module for winpmem, but it is running and exiting immediately. i do not see any info being dumped to the console tho. when i run it directly, i get this output:

[image: image] https://user-images.githubusercontent.com/4265254/61158803-0cff8e80-a4c8-11e9-9eb1-99a296b44bac.png

this is with 3.2, but 3.3 does the same thing.

any ideas? is winpmem writing to stdout?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Velocidex/c-aff4/issues/126?email_source=notifications&email_token=AA5NRITTCRL7GHSQ3A4PHCLP7DXVDA5CNFSM4ICRND6KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4G67BUVQ, or mute the thread https://github.com/notifications/unsubscribe-auth/AA5NRIXSNIRCFKS5JSEWK6LP7DXVDANCNFSM4ICRND6A .

[EricZimmerman]

yep, windows 10, 1903, but its pending a reboot for an update. will try again after the update, but this doesnt speak to the stdout issue

will reboot in a sec and report back

[scudette]

Sorry what is the stdout issue? Adding the -dd outputs extra messages. If you want to dump the image to stdout you can specify "-" as the output.

There are more use cases on the doc site at https://winpmem.velocidex.com/

Thanks Mike

On Sat, Jul 13, 2019, 07:19 Eric notifications@github.com wrote:

yep, windows 10, 1903, but its pending a reboot for an update. will try again after the update, but this doesnt speak to the stdout issue

will reboot in a sec and report back

[image: image] https://user-images.githubusercontent.com/4265254/61159178-2a812800-a4c9-11e9-98c5-a53564d1e571.png

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Velocidex/c-aff4/issues/126?email_source=notifications&email_token=AA5NRIVQWGIAP4EVXH5QZTLP7DYODA5CNFSM4ICRND6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ243BQ#issuecomment-511036806, or mute the thread https://github.com/notifications/unsubscribe-auth/AA5NRIUVP7RYSQXGDORH3H3P7DYODANCNFSM4ICRND6A .

[scudette]

Reading more closely it said there windows failed to verity the signature for the driver. Are you using the latest release? Does it still have trouble verifying the latest driver?

On Sat, Jul 13, 2019, 07:19 Eric notifications@github.com wrote:

yep, windows 10, 1903, but its pending a reboot for an update. will try again after the update, but this doesnt speak to the stdout issue

will reboot in a sec and report back

[image: image] https://user-images.githubusercontent.com/4265254/61159178-2a812800-a4c9-11e9-98c5-a53564d1e571.png

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Velocidex/c-aff4/issues/126?email_source=notifications&email_token=AA5NRIVQWGIAP4EVXH5QZTLP7DYODA5CNFSM4ICRND6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ243BQ#issuecomment-511036806, or mute the thread https://github.com/notifications/unsubscribe-auth/AA5NRIUVP7RYSQXGDORH3H3P7DYODANCNFSM4ICRND6A .

[EricZimmerman]

bad news. after a reboot, same thing with 3.2 and 3.3

Please let me know what else youd like me to try, and about stdout

[EricZimmerman]

Sorry what is the stdout issue? Adding the -dd outputs extra messages. If you want to dump the image to stdout you can specify "-" as the output.

i want the info printed on the screen in a normal PS window to show up in KAPE when the --debug switch is used.

i would expect to see exactly what is shown in the screen shot above when used in KAPE, but no matter what, nothing shows up.

with --debug in KAPE, anything output by the program being called is displayed on the screen, yet nothing is shown, like this:

i would expect winpmem output to show up where the arrow is, but it never does.

you can see that kape is calling winpmem with these args, including -dd

Running 'winpmem_3.2.exe': -o C:\cases\KAPE-OUTPUT\Memory/memory.dmp --volume_format raw -dd

with or without --dd, nothing shows up when winpmem is run via KAPE that i can see

i tried it in cmd window too with same results.

Eric Capuano created this module, and i know he tested it, so this is strange to me. ill ping him to see if he can shed any light on things too

[scudette]

Hi Eric, as you know most programs log to stderr actually - when kape shells out to a program does it do anything with stderr? Perhaps it's not capturing it properly? We reserve stdout for actual image data so you can redirect the image to a pipe, copy over ssh etc.

On Sat, Jul 13, 2019, 10:51 Eric notifications@github.com wrote:

Sorry what is the stdout issue? Adding the -dd outputs extra messages. If you want to dump the image to stdout you can specify "-" as the output.

i want the info printed on the screen in a normal PS window to show up in KAPE when the --debug switch is used.

i would expect to see exactly what is shown in the screen shot above when used in KAPE, but no matter what, nothing shows up.

with --debug in KAPE, anything output by the program being called is displayed on the screen, yet nothing is shown, like this:

[image: image] https://user-images.githubusercontent.com/4265254/61164758-2d3e4600-a4e6-11e9-9e57-2246543cd97d.png

i would expect winpmem output to show up where the arrow is, but it never does.

you can see that kape is calling winpmem with these args, including -dd

Running 'winpmem_3.2.exe': -o C:\cases\KAPE-OUTPUT\Memory/memory.dmp --volume_format raw -dd

with or without --dd, nothing shows up when winpmem is run via KAPE that i can see

i tried it in cmd window too with same results.

Eric Capuano created this module, and i know he tested it, so this is strange to me. ill ping him to see if he can shed any light on things too

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Velocidex/c-aff4/issues/126?email_source=notifications&email_token=AA5NRISCP3II25KYYRW7DN3P7ERKRA5CNFSM4ICRND6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ3FWAQ#issuecomment-511073026, or mute the thread https://github.com/notifications/unsubscribe-auth/AA5NRIWXQVSVEHJQ7MBQUJTP7ERKRANCNFSM4ICRND6A .

[scudette]

Could you please check why your windows system refuse to verify the drivers? You can find the drivers under tools/pmem/resources/winpmem in this repo. Just right click on them and view the digital section part. Your screenshot shows that your windows refuses to load these drivers for some reason.

On Sat, Jul 13, 2019, 22:19 Michael Cohen scudette@gmail.com wrote:

Hi Eric, as you know most programs log to stderr actually - when kape shells out to a program does it do anything with stderr? Perhaps it's not capturing it properly? We reserve stdout for actual image data so you can redirect the image to a pipe, copy over ssh etc.

On Sat, Jul 13, 2019, 10:51 Eric notifications@github.com wrote:

Sorry what is the stdout issue? Adding the -dd outputs extra messages. If you want to dump the image to stdout you can specify "-" as the output.

i want the info printed on the screen in a normal PS window to show up in KAPE when the --debug switch is used.

i would expect to see exactly what is shown in the screen shot above when used in KAPE, but no matter what, nothing shows up.

with --debug in KAPE, anything output by the program being called is displayed on the screen, yet nothing is shown, like this:

[image: image] https://user-images.githubusercontent.com/4265254/61164758-2d3e4600-a4e6-11e9-9e57-2246543cd97d.png

i would expect winpmem output to show up where the arrow is, but it never does.

you can see that kape is calling winpmem with these args, including -dd

Running 'winpmem_3.2.exe': -o C:\cases\KAPE-OUTPUT\Memory/memory.dmp --volume_format raw -dd

with or without --dd, nothing shows up when winpmem is run via KAPE that i can see

i tried it in cmd window too with same results.

Eric Capuano created this module, and i know he tested it, so this is strange to me. ill ping him to see if he can shed any light on things too

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Velocidex/c-aff4/issues/126?email_source=notifications&email_token=AA5NRISCP3II25KYYRW7DN3P7ERKRA5CNFSM4ICRND6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ3FWAQ#issuecomment-511073026, or mute the thread https://github.com/notifications/unsubscribe-auth/AA5NRIWXQVSVEHJQ7MBQUJTP7ERKRANCNFSM4ICRND6A .

[EricZimmerman]

i do indeed capture both stdout and stderr. neither is coming across, and this is confirmed on a different machine where the memory capture works. see here:

https://github.com/EricZimmerman/KapeFiles/issues/93#issuecomment-511104727

this is the code i use for capturing and it works for things like tzworks which does goofy blends of stdout and stderr:

p.StartInfo.RedirectStandardError = true; p.StartInfo.RedirectStandardOutput = true;

and i wire up the event to dump the received output to my logs.

i have not seen any of the other 90 or so programs used in modules not capture stdout in KAPE

you can see this if you run the winpmem module in KAPE with --debug enabled. when this switch is on, all output from modules is shown on the screen and also end up in the console log file.

[EricZimmerman]

i will verify and explicitly test stderr case here soon.

the OutputDataReceived is what i currently am doing, but there is another for ErrorDataReceived i will test that with winpmem here next.

[EricZimmerman]

Could you please check why your windows system refuse to verify the drivers? You can find the drivers under tools/pmem/resources/winpmem in this repo. Just right click on them and view the digital section part. Your screenshot shows that your windows refuses to load these drivers for some reason.

i do not see anything out of the ordinary on any of the drivers i viewed the properties for. is there something specific i can do?

[scudette]

You can try to run winpmem with the -L switch which will cause it to load the driver and exit then examine the tmp files it creates which are the unpacked drivers. Is there something stopping those files from being extracted properly?

[EricZimmerman]

does not work. its deleting the driver at the end of the run =(

PS D:\Code\kape\kape\bin\Debug\net45\Modules\bin> .\winpmem_3.2.exe -L -dd 2019-07-13 08:48:27 I This is The WinPmem memory imager. version 3.2 2019-07-13 08:48:27 I Extracted 45368 bytes into file:///C:/Users/eric/AppData/Local/Temp/pmeCF93.tmp 2019-07-13 08:48:27 I Driver Unloaded. 2019-07-13 08:48:27 I Trying to load non-attestation signed driver. 2019-07-13 08:48:27 I Extracted 36176 bytes into file:///C:/Users/eric/AppData/Local/Temp/pmeCFB3.tmp 2019-07-13 08:48:27 I Driver Unloaded. 2019-07-13 08:48:27 E Error: StartService(), Cannot start the driver: Windows cannot verify the digital signature for this file. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source.

2019-07-13 08:48:27 E Imaging failed with error: -8 2019-07-13 08:48:27 I Removed C:\Users\eric\AppData\Local\Temp\pmeCF93.tmp 2019-07-13 08:48:27 I Removed C:\Users\eric\AppData\Local\Temp\pmeCFB3.tmp

[EricZimmerman]

something still does not make sense. if you use stdout for the image, shouldnt i see something related to that as well?

there is a specific value for -o, -, which says it pushes the data to stdout. i am not specifying - as the output file, so why isnt the feedback going to stdout in this case?

"-o </path/to/file>, --output </path/to/file> Output file to write to. If the file does not exist we create it. NOTE: If output is a directory we write an AFF4 Directory volume when imaging. If the output is '-' we write to stdout."

explicitly capturing standarderror did not change anything as far as seeing output in a VM (which works to capture the memory if run by itself.

dumping non errors to stderr seems counter-intuitive imo

[EricZimmerman]

for now we are working around this issue by having winpmem log to a file, but ideally it would use stdinfo and/or stderr in such a way that it can be captured properly

[EricZimmerman]

with log file creation on winpmem command line, this ends up in the log file specified (partial):

2019-07-13 13:05:22 I This is The WinPmem memory imager. version 3.2 2019-07-13 13:05:22 I Extracted 45368 bytes into file:///C:/Users/SANSDFIR/AppData/Local/Temp/pme27BE.tmp 2019-07-13 13:05:22 I Driver Unloaded. 2019-07-13 13:05:22 I Loaded Driver C:\Users\SANSDFIR\AppData\Local\Temp\pme27BE.tmp 2019-07-13 13:05:22 I Setting acquisition mode 2 2019-07-13 13:05:22 I CR3: 0x00001AA002 5 memory ranges: Start 0x00001000 - Length 0x0009E000 Start 0x00100000 - Length 0x00002000 Start 0x00103000 - Length 0xBFDDD000 Start 0xBFF00000 - Length 0x00100000 Start 0x100000000 - Length 0x140000000

2019-07-13 13:05:22 I Will write in raw format. 2019-07-13 13:05:22 I Setting acquisition mode 2 2019-07-13 13:05:22 I Dumping Range 0 (Starts at 0x001000, length 0x09e000 2019-07-13 13:05:22 I Dumping Range 1 (Starts at 0x100000, length 0x002000 2019-07-13 13:05:22 I Dumping Range 2 (Starts at 0x103000, length 0xbfddd000 2019-07-13 13:05:22 I Dumping Range 3 (Starts at 0xbff00000, length 0x100000 2019-07-13 13:05:22 I Dumping Range 4 (Starts at 0x100000000, length 0x140000000 2019-07-13 13:05:22 I Destination volume will be a flat file file:///C:/cases/KAPE-OUTPUT/Memory/memory.dmp. 2019-07-13 13:05:23 I Reading 9708000 151 MiB / 8191 (604 MiB/s) 2019-07-13 13:05:23 I Reading 18da8000 397 MiB / 8191 (986 MiB/s) 2019-07-13 13:05:23 I Reading 28640000 646 MiB / 8191 (994 MiB/s) 2019-07-13 13:05:23 I Reading 34e98000 846 MiB / 8191 (801 MiB/s) 2019-07-13 13:05:24 I Reading 412e8000 1042 MiB / 8191 (784 MiB/s) 2019-07-13 13:05:24 I Reading 4db50000 1243 MiB / 8191 (802 MiB/s) 2019-07-13 13:05:24 I Reading 5d408000 1492 MiB / 8191 (995 MiB/s) 2019-07-13 13:05:24 I Reading 6a050000 1696 MiB / 8191 (817 MiB/s) 2019-07-13 13:05:25 I Reading 762c0000 1890 MiB / 8191 (774 MiB/s) 2019-07-13 13:05:25 I Reading 82b28000 2091 MiB / 8191 (802 MiB/s) 2019-07-13 13:05:25 I Reading 915b0000 2325 MiB / 8191 (938 MiB/s) 2019-07-13 13:05:25 I Reading 9da68000 2522 MiB / 8191 (787 MiB/s) 2019-07-13 13:05:26 I Reading a9c88000 2716 MiB / 8191 (775 MiB/s) 2019-07-13 13:05:26 I Reading b8098000 2944 MiB / 8191 (912 MiB/s) 2019-07-13 13:05:26 I Reading c8a98000 3210 MiB / 8191 (1064 MiB/s) 2019-07-13 13:05:26 I Reading dd2f8000 3538 MiB / 8191 (1313 MiB/s) 2019-07-13 13:05:27 I Reading efe20000 3838 MiB / 8191 (1164 MiB/s)

this is what i want showing up on stdout ideally

[scudette]

I looked further into this and I can confirm that when output is not a terminal, logging is disabled.

This happens because we choose the spdlog::stderr_color_mt sink and on windows this creates a wincolor sink which writes color output to the console using WriteConsoleA. I dont event think this is smart enough to check for an actual console - I think calling WriteConsoleA on a non console handle will simply ignore it - which is why log messages are getting lost.

https://github.com/gabime/spdlog/blob/master/include/spdlog/details/spdlog_impl.h#L126

We worked around this bug in spdlog by checking if the output is a tty first then using the non color version of the sink.

[scudette]

Opened a bug upstream https://github.com/gabime/spdlog/issues/1147

[EricZimmerman]

Ok sounds good.

That will help for sure once fixed

[EricZimmerman]

this looks like it was fixed upstream a while ago. any status for it fixed with new version of winpmem?

[scudette]

Hi Eric, Yeah sorry I committed the fix but have not built a new rc. I will try to get one done in the next few days.

Thanks Mike

On Mon, Jul 29, 2019, 09:06 Eric notifications@github.com wrote:

this looks like it was fixed upstream a while ago. any status for it fixed with new version of winpmem?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Velocidex/c-aff4/issues/126?email_source=notifications&email_token=AA5NRIXJDDM23IWU7B5Q3Y3QB4IPDA5CNFSM4ICRND6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3BGBAI#issuecomment-516055169, or mute the thread https://github.com/notifications/unsubscribe-auth/AA5NRIXG3UEERXMKFKQICS3QB4IPDANCNFSM4ICRND6A .

[scudette]

There is a new release now which address this issue.

Thanks

Mike.

On 7/31/19 4:13 AM, Michael Cohen wrote:

Hi Eric,  Yeah sorry I committed the fix but have not built a new rc. I will try to get one done in the next few days.

Thanks Mike

On Mon, Jul 29, 2019, 09:06 Eric <notifications@github.com mailto:notifications@github.com> wrote:

this looks like it was fixed upstream a while ago. any status for
it fixed with new version of winpmem?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/Velocidex/c-aff4/issues/126?email_source=notifications&email_token=AA5NRIXJDDM23IWU7B5Q3Y3QB4IPDA5CNFSM4ICRND6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3BGBAI#issuecomment-516055169>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA5NRIXG3UEERXMKFKQICS3QB4IPDANCNFSM4ICRND6A>.

[marisogsg]

Hi,

good morning, write because I tried executed the last version "winpmem_v3.3.rc3.exe" but obtained the same error described in this issue.

I executed the same test in virtual machine and didn´t have problems.

The differences are: host: w10 compilance 19041.388 virtual machine: w10 compilance 17763.253

Please, can you help?

Thanks