-
-
[原创]vmware外部读写内存也没那么神秘
-
发表于: 2024-12-24 01:19
-
老外玩已经把这个玩的很明白了，而且这个技术是很老的技术，看雪论坛很早之前有人发过xp相关的信息。具体帖子我忘记了（跟追中木马病毒先关的xp时代）
主要是使用老外开源的项目，老外还挺贴心支持各种语言调用
工作原理是搜索vmware-vmx进程内的内核结构头，对内核我个人研究不深，
大概就是搜索一个特征头，得到process数据链，再根据数据遍历出所有需要的数据 进程数据，然后根据进程数据得到物理内存地址，再修改或读取，可以获取到进程id和模块地址，还有API地址
读写内存有一定限制，比如我个人测试他会无法获取到普通程序new出来的内存数据，有可能是我虚拟机分配的内存只有2G，然后内存被写入文件了，跟dma局限相似吧，因为内存被写入到系统缓存文件里，就无法读写了。
那么就要设置系统关闭内存缓存
既这个位置
如果关闭了这个，虚拟机挂机就很鸡肋了。除非你内存真的超多。
至于如何实现执行，作者也给出了解决方案，具体代码我没查看，确实对内核了解很少。
主要是通过写内存，写入挂钩代码到内核的一个函数，执行后对内存某个位置写入标记。外部不断循环检测标记，执行过了就恢复原本代码。
R3层也类似，比如挂钩游戏中的PeekMessageW函数，挂钩代码必须是可执行区域。一般是pe文件的后的0x1000个字节找一个函数基本不怎么被调用的，
然后再找一个可写的内存地址，比如我找到的USER32Base + 0x1a9ff8（每个人系统版本不一样），
先在USER32Base + 0x1000 写入一段判断USER32Base + 0x1a9ff8是否为0，如果为0则调用VirtualAllocEx，再储存到USER32Base +0x1a9ff8上。
尽量分配一个相对合理的大小吧，程序外部可以一直读USER32Base + 0x1a9ff8是否为0.不为0则读取指针然后恢复代码
他这个只能读写内存，无法申请内存和执行，通过这些手段就拥有了申请内存能力了，之后在自己申请的内存区去写入更复杂的shellcode。 第一次挂钩代码必须写在现有模块上，比如USER32.dll或者其他模块有执行权的，不然没地方下手（上面的方法主要目的就是要得到一段自己申请的内存地址有执行权）
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
