jmp

本文地址: https://www.laruence.com/2020/06/27/5963.html 转载请注明出处 PHP8 alpha1已经在昨天发布，相信关于JIT是大家最关心的，它到底怎么用，有什么要注意的，以及性能提升到底咋样？ 首先，我们来看一张图: 左图是PHP8之前的Opcache流程示意图， 右图是PHP8中的Opcache示意图， 可以看出几个关键点: PHP8的JIT是在Opcache之中提供的 目前PHP8只支持x86架构的CPU JIT是在原来Opcache优化的优化基础之上进行优化的，不是替代 事实上JIT共用了很多原来Opcache做优化的基础数据结构，比如data flow graph, call graph, SSA等，关于这部分，后续如果有时间，可以单独在写一个文章来介绍，今天就只是着重在使用层面。 下载安装好以后，除掉原有的opcache配置以外，对于JIT我们需要添加如下配置到php.ini： opcache.jit=1205 opcache.jit_buffer_size=64M opcache.jit这个配置看起来稍微有点复杂，我来解释下, 这个配置由4个独立的数字组成，从左到右分别是( 请注意，这个是基于目前alpha1的版本设置，一些配置可能会随着后续版本做微调 ): 是否在生成机器码点时候使用AVX指令, 需要CPU支持: 0:

摘要 Borland Object Pascal 对象模型（现在已经正是命名为 Delphi 语言）与其他 OOP 语言一样，都提供了一些基础服务： 如对象创建服务、对象释放服务、对象识别服务、对象信息服务，除此之外在编译器和 VCL framework 级别上提供了一些额外的服务，例如对象消息分派服务。 前言 　　首先说一下，Delphi 对象模型涉及的概念非常多，因此在这篇笔记中，我无法将所有的知识点都点到，只是理出一条线方便后来人。可以说这部分内容不是很容易搞懂的，建议大家多看 VCL 源码，它可真是一座金山，有你挖不完的金子，每次你都会有意外收获的。另外有些概念恐怕看源码也不见得搞得懂，这时候你可以通过 Debug 看看反汇编的结果，通常会看到编译器为你做了很多幕后工作。有了这种钻研精神，我想恐怕没有什么问题解决不了的。 正文 Delphi 中万物之源是 TObject，不管你自定义的类是否指明了所继承的父类，一定都是 TObject 的子孙，一样具有 TObject 定义的所有特性[3]。由于在 TObject 中已经提供了大部分的对象基础服务，因此继承类自然而然也就具备了这些对象服务，强烈建议每一个学 Delphi 的朋友都要仔细研习一下 TObject 的源码。 　　一个对象的生命周期是从它被创建那一刻开始。通常我们都用类似 TMyObject.Create

自制操作系统Antz day10——实现shell(上) AntzUhl 2018-10-10 16:25 阅读:192 评论:0 Linux内核源码分析 day01——内存寻址 AntzUhl 2018-08-05 13:38 阅读:111 评论:0 后端必备的Linux知识 AntzUhl 2018-08-05 09:45 阅读:190 评论:0 自制操作系统Antz day09——实现内核 (下) 实现图形化界面 AntzUhl 2018-08-03 13:22 阅读:485 评论:5 自制操作系统Antz day08——实现内核 (中) 扩展内核 AntzUhl 2018-08-01 14:56 阅读:262 评论:2 自制操作系统Antz day07——实现内核 (上) AntzUhl 2018-07-31 15:15 阅读:383 评论:3 自制操作系统Antz day06——内核初步，引入c语言 AntzUhl 2018-07-30 16:44 阅读:609 评论:4 自制操作系统Antz day05——深入理解保护模式与进入方法 AntzUhl 2018-07-29 14:21 阅读:226 评论:0 自制操作系统Antz day04——进入保护模式 (下) 实现内核并从硬盘载入 AntzUhl 2018-07-28 21:26 阅读:285 评论:4

寄存器 上一章笔记是从CPU执行指令的角度8086CPU的逻辑结构、形成物理地址的方法、相关的寄存器以及一些指令。这章节从访问内存的角度学习几个寄存器。 内存中字的存储 CPU中，用16 位寄存器来存储一个字。高8位存放高位字节，低8位存放低位字节。在内存中存储时，由于 内存单元是字节单元（一个单元存放一个字节） ，则一个字要用两个地址连续的内存单元来存放，这个字的低位字节存放在低地址单元中，高位字节存放在高地址单元中。 用0、1两个内存单元存放数据20000(4E20H) 。0 、1两个内存单元用来存储一个字，内存中字的存储单元可以看作一个起始地址为0的字单元（存放一个字的内存单元，由0、1两个字节单元组成）。对千这个字单元来说，0号单元是低地址单元，1号单元是高地址单元，则字型数据4E20H的低位字节存放在0号单元中，高位字节存放在1号单元中。同理，将2、3号单元看作一个字单元，它的起始地址为2。在这个字单元中存放数据18(0012H)，则在2 号单元中存放低位字节12H，在3号单元中存放高位字节00H。 字单元的概念：字单元，即存放一个字型数据(16位)的内存单元，由两个地址连续的内存单元组成。高地址内存单元中存放字型数据的高位字节，低地址内存单元中存放字型数据的低位字节。 DS和[address] CPU要读写一个内存单元的时候，必须先给出这个内存单元的地址。

深入特权级转移 A.深入理解调用门 1.调用门用于向高特权级的代码段转移 2.调用门描述符的特权级低于当前特权级 关于调用门的注意事项 1.调用门支持特权级同级转移 2.调用门同级转移被处理为普通函数调用或直接跳转 3.CALL通过调用门能提升特权级，jmp通过调用门只能同级转移 4.通过调用门特权级返回(retf)时，对目标代码段以及栈段进行特权级检查，对相关段寄存器强制清零(指向高特权级数据的段寄存器) 代码 %include "inc.asm" org 0x9000 jmp ENTRY_SEGMENT [section .gdt] ; GDT definition ; 段基址， 段界限， 段属性 GDT_ENTRY : Descriptor 0, 0, 0 CODE32_DESC : Descriptor 0, Code32SegLen - 1, DA_C + DA_32 + DA_DPL2 VIDEO_DESC : Descriptor 0xB8000, 0x07FFF, DA_DRWA + DA_32 + DA_DPL2 DATA32_DESC_0 : Descriptor 0, Data32SegLen0 - 1, DA_DR + DA_32 + DA_DPL0 DATA32_DESC_2 : Descriptor 0, Data32SegLen2 - 1, DA_DR

寄存器 CPU由运算器、 控制器、 寄存器等器件构成，这些器件靠内部总线相连。内部总线实现CPU内部各个器件之间的联系， 外部总线实现CPU和主板上其他器件的联系。 简单地说， 在CPU中： 运算器进行信息处理； 寄存器进行信息存储； 控制器控制各种器件进行工作； 内部总线连接各种器件， 在它们之间进行数据的传送。 对于汇编程序员来说， CPU中的主要部件是寄存器。 寄存器是CPU中程序员可以用指令读写的部件。 程序员通过改变各种寄存器中的内容来实现对CPU的控制。不同的CPU, 寄存器的个数、 结构是不相同的。 AX――累加器（Accumulator），使用频度最高 BX――基址寄存器（Base Register），常存放存储器地址 CX――计数器（Count Register），常作为计数器 DX――数据寄存器（Data Register），存放数据 SI――源变址寄存器（Source Index），常保存存储单元地址 DI――目的变址寄存器（Destination Index），常保存存储单元地址 BP――基址指针寄存器（Base Pointer），表示堆栈区域中的基地址 SP――堆栈指针寄存器（Stack Pointer），指示堆栈区域的栈顶地址 IP――指令指针寄存器（Instruction Pointer），指示要执行指令所在存储单元的地址。IP寄存器是一个专用寄存器。

Rootkit需要及时发现是否有程序抓它，而侦测程序本身也需要时刻警惕Rootkit的注入，左右互搏。 侦测程序发现Rootkit的手段是非常多的，前面我介绍过通过内核text段互相调用的地址范围来静态扫描的方式： https://blog.csdn.net/dog250/article/details/105474909 本文我将介绍一种动态trace stack的方式来捕捉内核函数的调用异常。 以一个中性程序为例来讲吧。无关褒贬善恶。 上个月，我实现了一个功能，统计被iptables在INPUT链上DROP掉的数据包的数量： https://blog.csdn.net/dog250/article/details/105206753 具体细节请看那篇文章吧。 我的意思是，如何查出ip_local_deliver的中间被hook了呢？ 这其实很难，但也不是没有办法。 假设在不考虑性能损耗的情况下，我为内核的每一个函数头部添加一个jmp stub，在该stub中dump当前的stack，那么只要该stack的RBP下面附近有非内核text段地址区间范围的地址，那就需要详查，排除掉回调函数，剩下的就是非法的。 内核text段地址区间大致就是： ffffffff81000000 T _text .. . ffffffff81649abb T _etext 我们摆出DROP统计里的例子

因为qemu内置了gdbserver，所以我们可以用gdb调试qemu虚拟机上执行的代码，而且不受客户机系统限制。 以下内容是我调试 grub 0.97 时的一份笔记。 准备 qemu, gdb,以及一份带grub的虚拟机镜像，一份grub源码。 调试过程 启动虚拟机 $ sudo qemu-system-x86_64 -s -S -m 256 -hda test.img 然后使用gdb连接 $ gdb (gdb) target remote localhost: 1234 (gdb) set architecture i8086 (gdb) break * 0x7c00 (gdb) cont 一开始CPU是工作在实模式下，为了gdb显示正常我们把架构设置为i8086 BIOS会把MBR加载到内存0x7c00处，我们在这里下断点，然后执行 查看一下当前的反汇编代码 (gdb) x/ 4i $pc => 0x7c00 : jmp 0x7c4a 0x7c02 : nop 0x7c03 : add %al,(%bx,% si) 0x7c05 : add %al,(%bx,%si) 显示的是 att 风格的汇编代码，如果不习惯可以切换成 intel 风格的。 (gdb) set disassembly- flavor intel (gdb) x / 4i $pc => 0x7c00 :

记录一下在用python爬取百度链接中遇到的坑： 1.获取百度搜索页面中的域名URL BeautifulSoup获取a标签中href属性后，链接为百度url，利用request直接访问默认会直接进行跳转，无法获取所需域名 此时需要将requests的allow_redirects属性设置为False，禁止进行跳转，requests默认会进行跳转 再使用.headers['Location']获取最后链接:final_url = baidu_url.headers['Location'] 2.百度中的链接返回不统一 获取到实际域名链接后，发现还有一些奇怪的东西 访问后发现非site搜集域名 突然想到，很有可能是百度的广告 那就需要筛选出包含baidu.php?的链接去剔除掉 a="baidu.php?" b="url" if a in b:来进行筛选 3.百度安全验证绕过 当在百度搜索链接中加入pn页码参数时，便会直接出现百度安全验证（第一次访问就会出现，并不存在请求频繁） 但发现当手动在浏览器去百度进行site语法请求时，并不会出现百度安全验证码，猜想应该是有在HTTP请求头或者参数中漏掉一些参数　　 对HTTP请求参数进行一系列不可描述的操作之后，发现还需要"bs"、"rsv_jmp"两个参数 未添加这两个参数时,还存在验证，未获得任何返回数据 添加之后，已成功获取url 4

简介 KiUserExceptionDispatcher 是SEH分发器的用户模式的负责函数。当一个异常发生的时候，该异常将生成一个异常事件，内核检查该异常是否是由于执行用户模式代码导致的。如果是这样的话，内核修改栈上的trap frame，因此当内核从中断或者异常返回的时候，线程将从KiUserExceptionDispatcher 函数执行而不是导致异常的指令。内核将另外安排几个参数(一个 PCONTEXT 和一个 PEXCEPTION_RECORD)，它们描述了异常发生时机器的状态，而且在线程返回到用户模式之前被传递给KiUserExceptionDispatcher 函数。 一旦内核模式栈展开，而且指令转移到用户模式的KiUserExceptionDispatcher 函数，该函数通过调用一个本地的函数RtlDispatchException来处理异常，RtlDispatchException是用户模式异常处理逻辑中的核心函数。如果异常被成功分发的话(也就是SHE 链表中有一个函数宣称可以处理该异常)， RtlDispatchException调用RtlRestoreContext 函数实现最终的用户模式上下文的设置，该函数只是加载给定的上下文中的寄存器到到处理器的体系结构执行状态中。 否则，通过调用 NtRaiseException 函数，异常重新被提交到内核模式