im trying to use your Kmod_example but everytime i try i get this

`sudo ./kmod_example
Using Mode: MODE_EXTERNAL
Mapping VM memory, this will take a second...
Mem: 7efb75200000 | Size: 6d6000000
AddressSanitizer:DEADLYSIGNAL

==7296==ERROR: AddressSanitizer: SEGV on unknown address 0x7efb75200000 (pc 0x7f3c1c5a76c4 bp 0x7fff9f6b3c90 sp 0x7fff9f6b3418 T0)
==7296==The signal is caused by a READ memory access.
#0 0x7f3c1c5a76c3 (/lib/x86_64-linux-gnu/libc.so.6+0xbb6c3)
#1 0x4dc41d (/home/alec/ree/vmread/build/kmod_example+0x4dc41d)
#2 0x52f5db (/home/alec/ree/vmread/build/kmod_example+0x52f5db)
#3 0x51db67 (/home/alec/ree/vmread/build/kmod_example+0x51db67)
#4 0x51cc2d (/home/alec/ree/vmread/build/kmod_example+0x51cc2d)
#5 0x52c7d9 (/home/alec/ree/vmread/build/kmod_example+0x52c7d9)
#6 0x52a0fc (/home/alec/ree/vmread/build/kmod_example+0x52a0fc)
#7 0x53531c (/home/alec/ree/vmread/build/kmod_example+0x53531c)
#8 0x7f3c1c50db27 (/lib/x86_64-linux-gnu/libc.so.6+0x21b27)
#9 0x41daf9 (/home/alec/ree/vmread/build/kmod_example+0x41daf9)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/lib/x86_64-linux-gnu/libc.so.6+0xbb6c3)
==7296==ABORTING
`

i have tried changing the compiler to clang different versions of clang and different versions of gcc and g++ but to no avail. I know 2 other people who are having the same issue.

Hey,

I'm having Initialization error 8 when trying to initialize the win context.
It appears that the GetNTBuild function returns 0.
I'm currently on WIN10 ver 2004 build 19041.264

I've created a library that communicates from usermode to VM and back to usermode over sockets but I'm getting some pretty bad performance (ESP is very slow) and not really sure how I can improve it in anyway.

I know this question isn't directly pointed at a issue with the repo but maybe someone can help and I will open source it.

This is my process:

User mode (Send read request over socket with the data: source address, destination address and size in a packet)

VM (read data using source address and size with vmread library and store address in a buffer)

VM (write data from buffer using vmread library back to user mode destination address with correct size)

User mode now has access to the memory within the process of itself and can draw information to screen.

But this is the point where performance is really bad. I'm guessing its because for every read request I do two operations a read and write but not 100% sure.

More information... I'm using the kernel mode driver

delete me

I'm trying to get the exports for win32kbase.sys and I'm not sure the best route to take.

I've tried reusing existing methods for getting a module list on the System process and its size is always 0, any advice?

What's MODE_DMA for? I'm not seeing it used in anywhere besides line#127 in wintools.c

Hi,

I've encountered a strange infinite loop regression when finding module information for the "svchost.exe" process. (Guest: Windows 10 1909)

I've pinned it down to this section of code. FillModuleInfo64 sets the head to 0x0 and an infinite loop occurs.
https://github.com/Heep042/vmread/blob/master/wintools.c#L677

A temporary "fix" would be to limit the number iterations if the head becomes null.

Thanks.

Process list doesn't show up in Windows 1903. I've set the VM to run as root. Followed the other instructions in the thread and haven't had any luck.

xxx:~/Code/vmread/build$ sudo ./example
Using Mode: MODE_EXTERNAL
PML4: 1aa000 | KernelEntry: fffff80242aca900
Kernel Base: fffff80242000000 (2000000)
PsInitialSystemProcess: fffff8024256f3a0 (256f3a0)
System (PID 4): ffffd586c827d080 (17c27d080)
NT Version: 1000
Process List:

xxx:~/Code/vmread$ ./inject
[New LWP 3999]
[New LWP 4004]
[New LWP 4006]
[New LWP 4007]
[New LWP 4008]
[New LWP 4010]
[New LWP 4011]
[New LWP 4027]
[New LWP 4028]
[New LWP 4030]
[New LWP 4031]
[New LWP 4111]
[New LWP 4112]
[New LWP 4113]
[New LWP 4114]
[New LWP 4115]
[New LWP 4116]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007fcccd118cf6 in __GI_ppoll (fds=0x55c62f550e00, nfds=76, timeout=, sigmask=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:39
39 ../sysdeps/unix/sysv/linux/ppoll.c: No such file or directory.
[Thread 0x7fcb827fc700 (LWP 4115) exited]
[Thread 0x7fcb81ffb700 (LWP 4116) exited]
[Thread 0x7fcb82ffd700 (LWP 4114) exited]
[Thread 0x7fcb837fe700 (LWP 4113) exited]
[Thread 0x7fcb83fff700 (LWP 4112) exited]
[Thread 0x7fcb97cfc700 (LWP 4111) exited]
[Thread 0x7fcb95af5700 (LWP 4031) exited]
[Thread 0x7fcb963f7700 (LWP 4030) exited]
[Thread 0x7fcb96bf8700 (LWP 4028) exited]
[Thread 0x7fcb973f9700 (LWP 4027) exited]
[Thread 0x7fccbd7ff700 (LWP 4011) exited]
[Thread 0x7fccbe3ff700 (LWP 4010) exited]
[Thread 0x7fccbeffc700 (LWP 4008) exited]
[Thread 0x7fccbf7fd700 (LWP 4007) exited]
[Thread 0x7fccbfffe700 (LWP 4006) exited]
[Thread 0x7fccc07ff700 (LWP 4004) exited]
[Thread 0x7fccc4805700 (LWP 3999) exited]
[Inferior 1 (process 3986) exited with code 01]
The program being debugged exited while in a function called from GDB.
Evaluation of the expression containing the function
(__dlopen) will be abandoned.
$1 = "Injection failed!"
You can't do that without a process to debug.
The program is not being run.

I've checked /tmp/ permissions, library permissions as well. Inject just closes down the vm entirely.

WriteList performs heap allocations when queueing data to be written. The solution to this problem is to hold an expandable buffer that would keep the written data tightly packed without constantly querying the heap and improving the cache performance.

Nevermind. Forgot Sudo

Are there any plans to update the windows 10 offsets for the 1909 update?

It appears that on Windows 10 version 1903 the export table of the kernel is not parseable. This is a serious issue that breaks initialization process.

During boot:

Using Mode: MODE_EXTERNAL
PML4:   1ad000  | KernelEntry:  fffff8047e2ca9a0
Kernel Base:    fffff8047d800000 (2e00000)
ntHeader64:     0x7fffb5b67248  1
ParseExportTable: 994dd8 - 992000 + b64 * 4 > 177bb
ParseExportTable: 0
PsInitialSystemProcess: fffff8047dd6f3a0 (336f3a0)
System (PID 4): ffffd7846aa79040 (471c79040)
NT Version:     1000
NT Build:       18362
Process List:
0004    System
0174    smss.exe

After boot:

Using Mode: MODE_EXTERNAL
PML4:   1ad000  | KernelEntry:  fffff8047e2ca9a0
Kernel Base:    fffff8049265a000 (82e00000)
ntHeader64:     0x7ffca86f40d8  1
ParseExportTable: 1 - 992000 + 8091d510 * 4 > 177bb
ParseExportTable: 4
Initialization error: 5 

Notice the kernel base changing. There might be a workaround inside the security settings, but that is far from ideal.

I am new to meson and ninja, this is what I have installed:

• Ubuntu 18.04 LTS
• gcc 7.3.0
• meson 0.50.0
• ninja 1.8.2

I clone this repo and I ran meson build and then ninja.
First thing I noticed was that your default_option seems to be off:
default_options : ['c_std=c99', 'c++_std=c++11']
shouldn't it be?
'cpp_std=c++11'

Then I fail building due to:
//'-Wno-old-style-cast', '-Wno-missing-prototypes', '-Weverything'
cc1: error: command line option ‘-Wno-old-style-cast’ is valid for C++/ObjC++ but not for C [-Werror]

Removing the above I hit errors like this:
../wintools.c:25: undefined reference to pmparser_parse'`

Solved it by adding pmparser.c:
base_files = ['mem.c', 'wintools.c', 'pmparser.c']

So just curious what is going on?

Thanks for the library it is working very well.

I'm trying to run the example injection method to get faster READ&WRITE operations because currently in external mode its not fast enough for what I need it for so I'm testing the example in this project but where I run the injection script sudo ./inject everything crashes and I have cycle the power.

Win is 1903, is there some alternative method for reading faster or what could possibly be the cause of the crash using the example?

Sometimes the process disappears from the list until I restart the game. When this happens it also doesn't show up in kvm_explorer. No idea why this is happening, not much happens between when It was working fine and then suddenly disappears. I notice it after restarting my hack a lot when coding.

Also, any plans to add memory page enumeration? I forked cheat engine's ceserver and made it use vmread and I can use CE browse memory, but page enum is needed to scan and low level windows is way over my head and I don't think I can do it myself.

Thanks for the cool lib :)

EDIT: For whatever reason, opening task manager fixes it. Decent enough workaround I guess

Hello all,

Some of you may have noticed that version 2004 of W10 is yet to get support, also, the kernel module has effectively been broken by the new kernel version. The changes needed to fix these issues are not big, but right now I'm in a delicate situation.

I have been cowriting a new tool for memory introspection for a couple months already, which would provide everything vmread can do better, and so, so much more, such as ability to work with DMA devices, dump files, and more. As it currently stands, our target is to release it around the end of the summer, and due to most of the effort being put in the new project, a bit of maintenance vacuum has formed.

It is unlikely that I will be able to go and fix 2004 support, and an extra pair of hands would be wonderful for the project. So this is a call for anyone interested in maintaining the project for a while, it would mostly involve just fixing the 2 issues for now, but afterwards, as long as the project stays to its core, I will not intervene regarding the way it was decided to be developed. EOLing it altogether would also be fine after the summer, it's just these 1-3 months that are important.

Thank you for your understanding
-Auri

Archlinux,
uname -r == 5.8.5-arch1-1,
had to modify kmem.c a bit to compile.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9740ca4e95b43b91a4a848694a20d01ba6818f7b
Had to use this instead of trying to access mm->mmap_sem.

Had to #include <linux/vmalloc.h>

Hi, I am learning and I am wondering if you would have any time to talk about your vmread library and kernel module.

Host: Fedora 31
Kernel: 5.5.11
Guest: Windows 10 1909

I made a preload lib. I tried making couple read calls without problems. Then I run into a segmentation fault.
gdb tells me it breaks at

Thread 3 "renderThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff2c63700 (LWP 19614)]
0x00007ffff7f1c5c5 in MemRead (data=0xfe8000018080fe80, localAddr=140737266436856, remoteAddr=1527623114814600480, len=8) at src/vmmem.cpp:39
39		remote.iov_base = (void*)(data->mapsStart + KFIX2(remoteAddr));

because the remoteAddr is too huge. Going back I noticed something unusual:

the dirBase changed from VMemRead to VTranslate, which seems impossible looking at code.

I'm not sure if this is the root cause but it looks weird from my understanding.

uintptr_t genv = PatternScan::FindPattern("E8 ? ? ? ? 48 8B ? ? ? ? ? 48 8D ? ? ? ? ? 48 8B ? ? ? ? ? 48 8B ? FF 50 78", minAddress, maxAddress); + 0x07; fprintf(out,"Searching for Pattern: \n"); fprintf(out, "%s\n", pattern.c_str()); fprintf(out,"Found Pattern: \n"); for (int z = 0; z < 32; z++) fprintf(out,"%02x ", i.Read<unsigned char>(genv+z)); fprintf(out, "\n");
Output:

Searching for Pattern:
E8 ?? ?? ?? ?? 48 8B ?? ?? ?? ?? ?? 48 8D ?? ?? ?? ?? ?? 48 8B ?? ?? ?? ?? ?? 48 8B ?? FF 50 78

Found Pattern:
e8 a6 8a 00 00 48 8b c8 48 85 c0 75 07 ff 15 f8 fd 01 00 cc 48 83 c0 27 48 83 e0 e0 48 89 48 f8

As you can see here, it doesn't seem to follow the pattern after the first ??.

Running Windows 10 LTSC,

The external method returns the following:

Using Mode: MODE_EXTERNAL
PML4:	1aa000	| KernelEntry:	fffff80580c27460
Kernel Base:	fffff8058021f000 (1e1f000)
PsInitialSystemProcess:	fffff805806e42e0 (22e42e0)
System (PID 4):	ffff8e056d87b1c0 (0)
NT Version:	1000
Process List:

The injection method simply crashes Qemu.

[New LWP 1081]
[New LWP 1090]
[New LWP 1091]
[New LWP 1094]
[New LWP 1097]
[New LWP 1098]
[New LWP 1101]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007f4208df27d6 in __GI_ppoll (fds=0x55a299d9fc00, nfds=13, timeout=<optimized out>, sigmask=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:39
39	../sysdeps/unix/sysv/linux/ppoll.c: No such file or directory.

Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
0x00007f420c2864f1 in ?? () from target:/lib64/ld-linux-x86-64.so.2
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on".
Evaluation of the expression containing the function
(__dlclose) will be abandoned.
When the function is done executing, GDB will silently stop.
[Inferior 1 (process 1059) detached]

Possibly caused by the wrong offsets?

Guess the longer name is somewhere else

kallsyms_lookup_name has been unexported from use for out-of-tree modules. This effectively breaks the kernel module.

In kernel 5.6.2+ and above I get the following compilation error

make
touch "/home/compute/vmread/build/vmread_kmod/Makefile"
make -C /lib/modules/5.6.3-zen1-1-zen/build M=/home/compute/vmread/build/vmread_kmod src=/home/compute/vmread modules
make[1]: Entering directory '/usr/lib/modules/5.6.3-zen1-1-zen/build'
  CC [M]  /home/compute/vmread/build/vmread_kmod/kmem.o
/home/compute/vmread/kmem.c: In function ‘vmreadinit’:
/home/compute/vmread/kmem.c:37:30: error: passing argument 4 of ‘proc_create’ from incompatible pointer type [-Werror=incompatible-pointer-types]
   37 |  proc_create("vmread", 0, 0, &fops);
      |                              ^~~~~
      |                              |
      |                              const struct file_operations *
In file included from /home/compute/vmread/kmem.c:3:
./include/linux/proc_fs.h:64:24: note: expected ‘const struct proc_ops *’ but argument is of type ‘const struct file_operations *’
   64 | struct proc_dir_entry *proc_create(const char *name, umode_t mode, struct proc_dir_entry *parent, const struct proc_ops *proc_ops);
      |                        ^~~~~~~~~~~
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:268: /home/compute/vmread/build/vmread_kmod/kmem.o] Error 1
make[1]: *** [Makefile:1683: /home/compute/vmread/build/vmread_kmod] Error 2
make[1]: Leaving directory '/usr/lib/modules/5.6.3-zen1-1-zen/build'
make: *** [Makefile:11: all] Error 2

After changing line 37 to file_create I get the following

make
touch "/home/compute/vmread/build/vmread_kmod/Makefile"
make -C /lib/modules/5.6.3-zen1-1-zen/build M=/home/compute/vmread/build/vmread_kmod src=/home/compute/vmread modules
make[1]: Entering directory '/usr/lib/modules/5.6.3-zen1-1-zen/build'
  CC [M]  /home/compute/vmread/build/vmread_kmod/kmem.o
/home/compute/vmread/kmem.c: In function ‘vmreadinit’:
/home/compute/vmread/kmem.c:37:2: error: implicit declaration of function ‘file_create’ [-Werror=implicit-function-declaration]
   37 |  file_create("vmread", 0, 0, &fops);
      |  ^~~~~~~~~~~
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:268: /home/compute/vmread/build/vmread_kmod/kmem.o] Error 1
make[1]: *** [Makefile:1683: /home/compute/vmread/build/vmread_kmod] Error 2
make[1]: Leaving directory '/usr/lib/modules/5.6.3-zen1-1-zen/build'
make: *** [Makefile:11: all] Error 2

Fresh install of win10 Home (International UK English if that somehow matters). Running on a second gen threadripper setup where everything is pinned to be run in numa nodeset 1.

VM is setup with 14 cores and 12GB of RAM.

I was originally running to exit code 1 when running the example until I moved the qemu process under my account.

Now I am running into exit code 3 and I really have no idea where to start the debugging process. I tried investigating the CheckLow function, CLion likes to believe there is unreachable code which can't be right.

I tried bypassing this check just to see, and it immediately fails with an exit code of 4, which is expected but I had to try.