逆向做linker的注入，非常有意思。 linker是在程序运行的时候，在OS层面上链接程序所需动态库的程序，C程序通常由GLIBC在/usr/lib或/lib下的ld.so担当。一个通常的，基于Linux x64架构的程序，file abc的信息会是 abc: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=0b7e41efb88e9213eb3244793a7928bafdd20654, stripped 其中interpreter /lib64/ld-linux-x86-64.so.2指明了将要使用的linker路径。......»
在做逆向作业的时候遇到一个问题:把从内存读回的数据用 char a[1000] LOOP printf("%x",a); 的方式输出到屏幕，再转储成二进制的话，总会出现数据丢失的情况。由于输出文件是一个MP3文件，一旦有数据丢失就意味着文件结构破坏，无法解析。 后来发现使用 LOOP printf("%c",a); 的方式打印，直接就可以得到完好的二进制文件，./decrypt2 > file.mp3的结果甚至可以直接播放。于是研究了一下使用printf格式化为%x和%c的差异。 用例文件 #include <stdio.h> int main() { int a = 0x99; unsigned char b[4] = {0x4,0x0,0x0,0x1}; printf("int a =......»
尝试复现Bypassing ASLR – Part I中的实验，在Kali x64和Ubuntu 16.04.2 x64上均失败，在nebula live CD(Ubuntu 11.10 x86)上完全成功(连偏移地址都完全一致，代码直接复制使用)。作者使用的是Ubuntu 12.04 x86环境，因此符合预期。 脆弱代码: #include <stdio.h> #include <string.h> /* Eventhough shell() function isnt invoked directly, its needed here since 'system@PLT' and 'exit@PLT' stub code should be present in executable to successfully exploit it. */ voi......»
路由上俩虚拟网段: 192.168.3.0/24，网关192.168.3.1 192.168.10.0/24，网关192.168.10.1 两个网段互通，因此机器之间可以相互ping通。 然而在192.168.3.76的机器上以桥接方式假设的虚拟机(192.168.3.57)，却无法被192.168.10.11的机器ping通。反之，192.168.3.57也无法ping通任何在192.168.10.0网段的机器。 由于不是80端口访问，而是ping不通，显然问题出在3.57设备的底层。 先把CentOS的firewalld关闭: # systemctl disable firewalld 并没有用。 然后查看iptable: # iptables -nv -L 也没有对其他网段有阻止。 最后想到会不会是虚拟机的原因，因为虽然网关上看起来是两台机器，但其实只有一块网......»
缓冲区溢出的基础前提，在于可以通过控制strcpy()或strcat()甚至printf()，来覆盖堆栈里的返回地址。之前的实验里，其实只实现了最简单的溢出方式，即跳转的地址在当前程序栈(text segment)内，也就是只能执行程序内存在的功能，攻击的效果有限。更普遍的堆栈溢出攻击，应该是能够任意代码执行，也就意味着能够调用自定的攻击函数。 严格说来，溢出跳转应包含几个层次: 跳转目标在同一个程序栈，通过修改当前进程(Process)的返回地址，来非法跳转到目标地址； 跳转目标在另外的存储空间，需要借用已经加载的动态库，来间接跳转。由于libc作为C程序的基础动态库，被所有的C程序共用，所以许多情况下会利用libc函数的返回地址作为跳板目标。这种方式又分为几个难度: 程序编译时不包含NX(No-eXecute, -z execstack)选项，使得在内存的数据区可以执行......»