QKD的物理原理 利用量子的测量特性来进行密钥方法而不是量子纠缠 基于以下物理原理 量子具有4种自旋 |0> |1> |+> |-> ，分别在两个测量基 十 和 X 上 |0> |1> 自旋的量子只能在测量基 十 上测准 |+> |-> 自旋的量子只能在测量基 X 上测准 使用错误测量基测量量子会扰动量子，使其在另一个测量基上的分量以1/2 1/2的概率分布到这个测量基，则只有1/2概率测准 使用错误测量基测量量子会使量子自旋改变 基于上述原理的密钥基本方法 Alice发送特定自旋的光子给Bob Bob选择随机测量基进行测量 Alice发送正确测量基 Bob将接收到的正确测量基与选择的测量基比较，判断是否选对测量基 Bob将测量基是否选择正确告知Alice 若测量基有效，则测量结果即为双方交换成功的秘密比特 进行若干次上述过程后，Alice和Bob就有了一组互相知道的密钥 抗第三方的原理 上面交换的过程是可以被监听的，第三方只要截获光子，根据Alice发送的正确测量基来获得测量结果后即可得到光子的状态并发送相同状态的光子给Bob 将以下QKD过程与上述进行比较： Alice发送特定自旋的光子给Bob Bob选择随机测量基进行测量 Bob发送选择的测量基 Alice将收到的测量基与正确测量基比较，结果告知Bob 若测量基有效，则测量结果即为双方交换成功的秘密比特 错误测量基会导致光子改变，因此若是第三方窃听了光子必然导致Bob收到的光子与Alice发出的不同，基于海森堡测不准原理，第三方不可能在不知道测量基的情况下复制出状态相同的光子。因此在第三方监听的情况下，第三方有1/2的概率选错测量基，1/2的概率由于测量使得光子自旋变化，这样就使得Bob收到的光子有1/4的概率与Alice发出时的状态不同。这为检测第三方监听提供了依据，但必须牺牲一部分交换结果来确认双方的结果是否相同才行。同时，若是第三方持续监听，将使得交换信道不可用。 从实现角度，由于光子的自旋即偏振，通过单光子发射器 发生的单光子通过偏振片即可生成垂直、水平、＋45°或－45°的偏振态。 BB84协议 Alice发送需要交换的密钥长度给Bob Alice发送一组特定自旋的光子给Bob Bob选择随机测量基进行测量这组光子 Bob发送选择的测量基序列 Alice将收到的测量基序列与正确测量基序列比较，将结果序列告知Bob 将结果序列为1的位上的测量结果作为本轮交换得到的密钥比特 重复几轮可以得到一个密钥序列...

第三次迁移博客 从开始的WordPress，到更轻量的 Typecho， 因为腾讯学生机到期的缘故，不得不对博客进行迁移，但是由于早期搭建博客的时候并没有使用docker对博客进行portable的管理，以及混乱的组织，以至于我并不想简单地把数据库简单地迁移到一个docker里然后在我的另一个vps继续使用，我对php并不熟悉，使用typecho是因为它轻量且支持markdown，仅此而已，但它的后台，评论，诸多动态的内容并不是我需要的东西，我只是需要一个生成器，把我的markdown生成为好看的html，然后剩下的交给websever。 因此我决定放弃原来博客的所有SEO，任其关闭而不做平滑迁移，把博客改成静态站。 比起html parser，写一个html generator简单得多，而一个基础markdown parser也并不困难，因此我尝试自己写并很快写出能输出原始html的demo，但很快我意识到，现成的静态生成器有相当多漂亮的主题，而如果自己造轮子，除了还要处理sitemap和rss的生成，还要在前端的主题上花费许多时间，这使我决定拥抱现成的生成器，hugo是个很棒的选择，它使用golang编写，比起nodejs，我更喜欢golang（但还不太想在逆向中看到它满屏的routine函数），然后我找到一个简洁的主题papermod，这就是这个新博客的由来。 我花费了半个下午学习hugo和这个主题的一些设置，感觉还有些不足，会在之后修改。 这里是一个TODO (issues) categories page 直接显示文章 toc 在侧边显示 about 页面 post 生成的工具 … 以及我将尝试使用正在学习的rust写一个webserver作为这个博客的server，我不指望它的性能能和nginx比，但他或许比nginx更安全，一个rust写的webserver托管一个静态站点，听起来将使任何对这个站点感兴趣的hacker望而却步，这很有趣，不是吗，至少我不会在心血来潮翻看log时发现一堆php-fpm溢出攻击的流量，以及翻看后台时满屏的垃圾评论，KEEP IT SIMPLE，简单使我快乐。...

本文在amd64平台使用以下编译器进行分析 gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2) 在c中，定义一个函数，往往是确定的参数类型和个数，并返回一个确定的类型 但每个程序员都写过的 printf(“hello world”); 却调用了一个非常异端的函数 int printf(const char* format, ...); printf作为一个格式化字符串函数，除了接收一个format串，还可以接收任意数量的任意类型的参数用来格式化，是个非常典型的变参函数 type VarArgFunc(type FixedArg1, type FixedArg2,...); 要了解格式化字符串的工作原理，绕不开变参这个点，而这也是格式化字符串漏洞的核心机制 如何在c中定义一个像printf一样的变参函数： #include <stdarg.h>int VarArgFunc(int dwFixedArg, ...){ va_list pArgs = NULL; va_start(pArgs, dwFixedArg); int dwVarArg = va_arg(pArgs, int); va_end(pArgs); } //可在头文件中声明函数为extern int VarArgFunc(int dwFixedArg, ...);，调用时用VarArgFunc(FixedArg, VarArg); 其实熟悉c函数调用约定(Calling convention)的话我们不难知道，函数的参数传递是约定好的，因此即使我们不定义显式定义一个经过编译器检查分配的形参，对应的寄存器和栈空间仍然可以被视作实参 首先以i386下__cdecl的典型栈传参为例，所有的参数按照从右到左的顺序依次压入栈，返回值在EAX中 并且由调用者清理栈 register int i=1; int j=2; calc(i,j,3); 主调函数(caller) push EAX ; 压入寄存器中的值 push byte[EBP+20] ; 压入栈上局部变量的值 (FASM/TASM syntax) push 3 ; 压入立即数 call calc ; 被调函数(callee)...

配置php-fpm如下 [global] error_log = /proc/self/fd/2 daemonize = no [www] access.log = /proc/self/fd/2 clear_env = no listen = 127.0.0.1:9000 pm = dynamic pm.max_children = 5 pm.start_servers = 1 pm.min_spare_servers = 1 pm.max_spare_servers = 1 将服务进程限制为1，方便调试 在页面中添加打印path_info <?php echo "hello world"; var_dump($_SERVER["PATH_INFO"]); 此时，由于一级路径即为index.php path_info应为空，但却打印出了PATH_INFO 使用tcpdump抓取nginx与php-fpm通过fastcgi通讯的流量 tcpdump -i any tcp -X port 9000 三次握手后在数据包中可以看到传递的path_info为空 判断修复只有一级路径的path时，确实存在过度回退path_info指针的异常 gdb attach 32 找到这个fcgi_accept_request函数调用点 init_request_info时会进行路径修复，修改pathinfo 在1127行后找到相关逻辑 pilen为0，slen为10，则env_path_info前移slen的长度，之后，在path_info中临时置零该位置。 即我们可以在这个位置获得一个临时的，前向越界写零操作 由于这个零很快就被改回old值，我们要想利用这个写零操作，最大的可能性就是在其间的两个fcgi操作中找到利用方式 FCGI_PUTENV(request, "ORIG_SCRIPT_NAME", orig_script_name); FCGI_PUTENV(request, "SCRIPT_NAME", env_path_info); 在fastcgi.h中找到相应宏定义 在gdb中 directory /usr/src/php 关联源码...

0x00 Setup 基础概念 vmlinux 是未压缩的可执行内核文件 vmlinuz 是压缩后的可执行文件 包括bzimage\zimage initrd (initial ramdisk)是用于启动时临时引导硬件到内核的临时文件系统 内核向下控制管理硬件，向上提供应用运行环境 源码阅读 https://elixir.bootlin.com 运行环境 apt-get install qemu-system 启动命令示例 qemu-system-x86_64 -initrd rootfs.cpio -kernel bzImage -append 'console=ttyS0 root=/dev/ram oops=panic panic=1' /dev/null -m 64M --nographic -smp cores=1,threads=1 -cpu kvm64,+smep 调试 -s 选项打开gdb:1234调试 qemu-system-i386 -kernel ./bzImage -append "console=ttyS0 oops=panic panic=1" -initrd ./rootfs -nographic -s gdb -q (gdb) set arch i386:x86-64 (gdb) target remote localhost:1234 文件系统 将busybox或其他文件系统通过cpio打包即可，qemu启动时直接作为initrd启动 启动后根目录下的init脚本会被执行 find . | cpio -o -H newc > ....