在笔者上一篇文章《驱动开发：内核实现SSDT挂钩与摘钩》中介绍了如何对SSDT函数进行Hook挂钩与摘钩的，本章将继续实现一个新功能，如何检测SSDT函数是否挂钩，要实现检测挂钩状态有两种方式，第一种方式则是类似于《驱动开发：摘除InlineHook内核钩子》文章中所演示的通过读取函数的前16个字节与原始字节做对比来判断挂钩状态，另一种方式则是通过对比函数的当前地址与起源地址进行判断，为了提高检测准确性本章将采用两种方式混合检测。具体原理，通过解析内核文件PE结构找到导出表，依次计算出每一个内核函数的RVA相对偏移，通过与内核模块基址相加此相对偏移得到函数的原始地址，然后再动态获取函数当前地址
1.查看服务器已安装的所有内核版本awk-F\''$1=="menuentry"{printi++":"$2}'/etc/grub2.cfg0:CentOSLinux(3.10.0-1160.83.1.el7.x86_64)7(Core)1:CentOSLinux(3.10.0-1160.80.1.el7.x86_64)7(Core)2:CentOSLinux(3.10.0-1127.el7.x86_64)7(Core)3:CentOSLinux(3.10.0-1160.83.1.el7.x86_64.debug)7(Core)4:CentOSLinux(3.10.0-1160.80.1.el
在某些时候我们需要读写的进程可能存在虚拟内存保护机制，在该机制下用户的CR3以及MDL读写将直接失效，从而导致无法读取到正确的数据，本章我们将继续研究如何实现物理级别的寻址读写。首先，驱动中的物理页读写是指在驱动中直接读写物理内存页（而不是虚拟内存页）。这种方式的优点是它能够更快地访问内存，因为它避免了虚拟内存管理的开销，通过直接读写物理内存，驱动程序可以绕过虚拟内存的保护机制，获得对系统中内存的更高级别的访问权限。想要实现物理页读写，第一步则是需要找到UserDirectoryTableBase的实际偏移地址，你一定会问这是个什么？别着急，听我来慢慢解释；在操作系统中，每个进程都有一个KPR
子曰：“不学礼，无以立;不学诗，无以言”《论语》：季氏篇百篇博客分析｜本篇为：(远程登录篇)|内核如何接待远方的客人设备驱动相关篇为:v67.03鸿蒙内核源码分析(字符设备)|绝大多数设备都是这类v74.01鸿蒙内核源码分析(控制台)|一个让很多人模糊的概念v75.01鸿蒙内核源码分析(远程登录)|内核如何接待远方的客人什么是远程登录？每个人都有上门做客的经历，抖音也一直在教我们做人，做客不要空手去，总得带点东西，而对中国人你就不能送钟，不能送梨，最好也别送鞋，因他们与终离邪谐音，犯忌讳。这是人情世故，叫礼仪，是中华文明圈的共识，是相互交流信任的基础。那互联网圈有没有这种共识呢？
在笔者上一篇文章《内核RIP劫持实现DLL注入》介绍了通过劫持RIP指针控制程序执行流实现插入DLL的目的，本章将继续探索全新的注入方式，通过NtCreateThreadEx这个内核函数实现注入DLL的目的，需要注意的是该函数在微软系统中未被导出使用时需要首先得到该函数的入口地址，NtCreateThreadEx函数最终会调用ZwCreateThread，本章在寻找函数的方式上有所不同，前一章通过内存定位的方法得到所需地址，本章则是通过解析导出表实现。内核导出表远程线程是一种实现DLL注入的常见技术之一。通过使用该技术，注入代码可以利用目标进程的导出表中已有的函数来加载DLL，并在远程线程中执
摘要：内存调测方法旨在辅助定位动态内存相关问题，提供了基础的动态内存池信息统计手段，向用户呈现内存池水线、碎片率等信息。本文分享自华为云社区《鸿蒙轻内核-内存调测-内存信息统计》，作者：zhushy。内存调测方法旨在辅助定位动态内存相关问题，提供了基础的动态内存池信息统计手段，向用户呈现内存池水线、碎片率等信息；提供了内存泄漏检测手段，方便用户准确定位存在内存泄漏的代码行，也可以辅助分析系统各个模块内存的使用情况；提供了踩内存检测手段，可以辅助定位越界踩内存的场景。本文分析下内存信息统计。1、基础概念内存信息包括内存池大小、内存使用量、剩余内存大小、最大空闲内存、内存水线、内存节点数统计、碎片
我在一家使用Linux构建嵌入式系统的公司工作。从历史上看，我们一直使用CVS来存储我们的内核工作。我们的内核最终成为以下内容的集合:我们专有硬件的驱动程序随机修复我们使用的Linux部分非专有硬件驱动程序为我们的应用定制Linux的随机yukkyhack我们正处于这样一个阶段，我们希望将一些较旧的内核重新定位到较新的版本上，并将我们陈旧的CVS工作流程修复为基于变更集的东西。显而易见的选择是git。我正在努力想出一个合理的工作流程。我已经为我们的一个内核导出了我们的CVS存储库，并且在适当的基本Linus内核之上有一组变更集。我从这里去哪里？我想要一个中央存储库，供所有开发人员提交更
我在一家使用Linux构建嵌入式系统的公司工作。从历史上看，我们一直使用CVS来存储我们的内核工作。我们的内核最终成为以下内容的集合:我们专有硬件的驱动程序随机修复我们使用的Linux部分非专有硬件驱动程序为我们的应用定制Linux的随机yukkyhack我们正处于这样一个阶段，我们希望将一些较旧的内核重新定位到较新的版本上，并将我们陈旧的CVS工作流程修复为基于变更集的东西。显而易见的选择是git。我正在努力想出一个合理的工作流程。我已经为我们的一个内核导出了我们的CVS存储库，并且在适当的基本Linus内核之上有一组变更集。我从这里去哪里？我想要一个中央存储库，供所有开发人员提交更
6月24日消息，Canonical于今天宣布，代号为ManticMinotaur的Ubuntu23.10发行版本已升级基于LinuxKernel6.3内核。Ubuntu23.10于今年4月下旬进入开发阶段，初期基于和Ubuntu23.04（LunarLobster）相同的LinuxKernel6.2内核，在开发2个月之后，每日构建ISO镜像现升级到6.3版本。Canonical计划于2023年10月发布Ubuntu23.10发行版，后续可能还会根据情况，进一步升级LinuxKernel，候选版本预估将于8月底/9月初推出。IT之家此前报道，LinuxKernel6.3在架构方面，为ARM和RI
在笔者上一篇文章《驱动开发：内核层InlineHook挂钩函数》中介绍了通过替换函数头部代码的方式实现Hook挂钩，对于ARK工具来说实现扫描与摘除InlineHook钩子也是最基本的功能，此类功能的实现一般可在应用层进行，而驱动层只需要保留一个读写字节的函数即可，将复杂的流程放在应用层实现是一个非常明智的选择，与《驱动开发：内核实现进程反汇编》中所使用的读写驱动基本一致，本篇文章中的驱动只保留两个功能，控制信号IOCTL_GET_CUR_CODE用于读取函数的前16个字节的内存，信号IOCTL_SET_ORI_CODE则用于设置前16个字节的内存。之所以是前16个字节是因为一般的内联Hook
