Closed naderhabbbab closed 3 years ago
I have a suspicion that it may be due to a slightly corrupt memory dump; DumpIt dumps take a few seconds to grab and things may change around in memory during that time leading to potential errors like this; But I really want to double check on things to see to that it's not buggy code of mine...
thank you 1- it fail to analyze the network connection 2- it windows 10 1909 3- it not a live memory it was dump memory 4- it was used to capture the memory using FTK imager , and the machine was VM 5- when i execute the command it mount the image once i click on the folder of net to check the connection its become unmounted .
how ever it test it with different memory image was been taken by winpemem and it work fine with no issue or error , it could be due to FTK imager something happen
MemProcFS should work fine with FTK imager memory dumps. Sometimes there may be issues with parsing the dumps if things have changed in memory during capture.
MemProcFS should however not unmount the image when looking at network connections even though there may be issues though. This is clearly an issue.
Are you able to share the FTK imager dump so I may look into this and fix it; or does it contain sensitive information? If it's possible to share can you please zip it and put it on google drive or something and send me an email to pcileech@frizk.net
I fully understand if you're unable to share the dump; but that would make things very hard for me to fix; whilst having the dump would allow me to relatively easy to find the issue.
Would it be possible to take a peek at that memory dump you had issues with. I'd rather fix this issue and to do that I unfortunately need to be able to reproduce it If it's not possible can you please let me know so I atleast know it's not possible.
Thank You.
Hi ,
Thank you how ever I’ve asked my management it will be hard to give a sample , I have found another memory which produce same issue it’s from a ctf challenge if this will help I can tell you the name of the challenge to verify it .
Best regards
On Thu, 3 Dec 2020 at 8:39 PM Ulf Frisk notifications@github.com wrote:
Would it be possible to take a peek at that memory dump you had issues with. I'd rather fix this issue and to do that I unfortunately need to be able to reproduce it If it's not possible can you please let me know so I atleast know it's not possible.
Thank You.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ufrisk/MemProcFS/issues/48#issuecomment-738168959, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ5AN44LWMUPXXLKWLVMHTSS7EMFANCNFSM4T5SX62A .
-- Mobile
thanks, it's unfortunate but fully understandable. at least I know then.
yes, having a memory image in which I can reproduce the crash/unmount behavior would be equally good. if I can download this memory image from somewhere it would be super nice :)
Thank you for your understanding. Here is the link for it it https://dfirmadness.com/the-stolen-szechuan-sauce/
On Thu, 3 Dec 2020 at 10:42 PM Ulf Frisk notifications@github.com wrote:
thanks, it's unfortunate but fully understandable. at least I know then.
yes, having a memory image in which I can reproduce the crash/unmount behavior would be equally good. if I can download this memory image from somewhere it would be super nice :)
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ufrisk/MemProcFS/issues/48#issuecomment-738251327, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ5AN6AA7TU5QSU5IVUOILSS7SZFANCNFSM4T5SX62A .
-- Mobile
Thanks. It's a good challenge. The issue happened one time for me on latest 3.5 version; but since then I haven't been able to replicate it. Except for this one time I haven't been able to induce a crash.
I found a few other issues (mainly some reads of compressed memory failing) with these challenge images though so it's been good; The memory images are otherwise quite horrible; it's a low memory system with lots of compressed memory and page file (which I also support); but it seems like acquisition was on the system and not through instantaneous snapshot and that it took some time so there is plenty of drift in the compressed memory manager which leads to lots of corrupted memory even tho I managed to lower the amount of corruption to some bug fixes :)
I'm assuming this is why your network analysis fails; but it's super strange it's not failing for me. My one and only crash was also not related to the network parsing. I'll continue testing; and with a little bit of luck it will work better in my new release next week; which btw is quite good at detecting the malware in that challenge :)
It would be good to know if the issue persists for you in my next release; I'm aiming for Monday or Tuesday; but we'll see...
Awesome, thanks!
On Sat, 5 Dec 2020 at 8:23 PM Ulf Frisk notifications@github.com wrote:
Thanks. It's a good challenge. The issue happened one time for me on latest 3.5 version; but since then I haven't been able to replicate it. Except for this one time I haven't been able to induce a crash.
I found a few other issues (mainly some reads of compressed memory failing) with these challenge images though so it's been good; The memory images are otherwise quite horrible; it's a low memory system with lots of compressed memory and page file (which I also support); but it seems like acquisition was one one the system and not through instantaneous snapshot and that it took some time so there is plenty of drift in the compressed memory manager which leads to lots of corrupted memory even tho I managed to lower the amount of corruption to some bug fixes :)
I'm assuming this is why your network analysis fails; but it's super strange it's not failing for me. My one and only crash was also not related to the network parsing. I'll continue testing; and with a little bit of luck it will work better in my new release next week; which btw is quite good at detecting the malware in that challenge :)
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ufrisk/MemProcFS/issues/48#issuecomment-739323764, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ5ANZMOWAJVLMM7R3R2F3STJUATANCNFSM4T5SX62A .
-- Mobile
Thanks for the dump. I've located the issue which was due to some over stringent validation. I'll make the new release available early next week (have a bunch of other features as well).
Thank You for the help on this one :)
Can you please try the new release. With a bit of luck the problem may have gone away. I was unable to reliably replicate it with the challenge memory dumps (which was working) so I'm not totally sure.
Will do, thanks! You’ve done great work
On Mon, 7 Dec 2020 at 10:52 AM Ulf Frisk notifications@github.com wrote:
Can you please try the new release. With a bit of luck the problem may have gone away. I was unable to reliably replicate it with the challenge memory dumps (which was working) so I'm not totally sure.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ufrisk/MemProcFS/issues/48#issuecomment-739739845, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ5AN2MU5CIAQECUIBRXPLSTSCSFANCNFSM4T5SX62A .
-- Mobile
I'm closing issue since I'm assuming it was resolved since i haven't head back. If the issue is still around please let me know.
after execute the command and i want to check network connection the following error happen the exit
VmmNet_TcpE_GetAddressEPs: UNEXPECTED POOL HDR: ' àÿÿ' EXPECT: 'HTab' AT VA: 0xffffe0005fee5ff0 VmmNet_TcpE_GetAddressEPs: UNEXPECTED POOL HDR: ' àÿÿ' EXPECT: 'HTab' AT VA: 0xffffe0005fee87f0 VmmNet_TcpE_GetAddressEPs: UNEXPECTED POOL HDR: ' àÿÿ' EXPECT: 'HTab' AT VA: 0xffffe0005fee47f0 VmmNet_TcpE_GetAddressEPs: UNEXPECTED POOL HDR: ' àÿÿ' EXPECT: 'HTab' AT VA: 0xffffe0005ff717f0
using the lateset MemProcFS version + all dependency