很多站长朋友们都不太清楚php.gdbinit，今天小编就来给大家整理php.gdbinit，希望对各位有所帮助，具体内容如下：
本文目录一览： 1、 linux下gdb怎么不执行.gdbinit 2、 如何调试PHP的Core之获取基本信息 3、 逆向需要的工具汇总（持续更新中） linux下gdb怎么不执行.gdbinit运用以下2个命令即可：next //执行下一行源代码，但并不进入调用函数内部
step //执行下一行源代码，进入函数内部，这个时候，可以在调用函数里面加断点。
gdb中的函数调用：
call name 调用和执行一个函数（gdb) call gen_and_sork（1234,1,0)（gdb) call printf（“abcd”）=4finish 结束执行当前函数，显示其返回值（如果有的话）
如何调试PHP的Core之获取基本信息首先, 让我们生成一个供我们举例子的Core文件:
<?phpfunction recurse($num) { recurse(++$num);} recurse(0);
运行这个PHP文件:
$ php test.phpSegmentation fault (core dumped)
这个PHP因为无线递归, 会导致爆栈, 从而造成 segment fault而在PHP的当前工作目录产生Coredump文件(如果你的系统没有产生Coredump文件, 那请查询ulimit的相关设置).
好, 现在, 让我们删除掉这个test.php, 忘掉上面的代码, 我们现在仅有的是这个Core文件, 任务是, 找出这个Core产生的原因, 以及发生时候的状态.
首先, 让我们用gdb打开这个core文件:
$ gdb php -c core.31656
会看到很多的信息, 首先让我们注意这段:
Core was generated by `php test.php'.Program terminated with signal 11, Segmentation fault.
他告诉我们Core发生的原因:”Segmentation fault”.
一般来说, 这种Core是最常见的, 解引用空指针, double free, 以及爆栈等等, 都会触发SIGSEGV, 继而默认的产生Coredump.
现在让我们看看Core发生时刻的堆栈:
#0 execute (op_array=0xdc9a70) at /home/laruence/package/php-5.2.14/Zend/zend_vm_execute.h:5353 memset(EX(CVs), 0, sizeof(zval**) * op_array->last_var);(gdb) bt#0 execute (op_array=0xdc9a70) at /home/laruence/package/php-5.2.14/Zend/zend_vm_execute.h:53#1 0x00000000006ea263 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fbf400210) at /home/laruence/package/php-5.2.14/Zend/zend_vm_execute.h:234#2 0x00000000006e9f61 in execute (op_array=0xdc9a70) at /home/laruence/package/php-5.2.14/Zend/zend_vm_execute.h:92#3 0x00000000006ea263 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fbf400440) at /home/laruence/package/php-5.2.14/Zend/zend_vm_execute.h:234#4 0x00000000006e9f61 in execute (op_array=0xdc9a70) at /home/laruence/package/php-5.2.14/Zend/zend_vm_execute.h:92#5 0x00000000006ea263 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fbf400670) at /home/laruence/package/php-5.2.14/Zend/zend_vm_execute.h:234.....
不停的按回车, 可以看到堆栈很深, 不停的是zend_do_fcall_common_helper_SPEC和execute的重复, 那么这基本就能断定是因为产生了无穷大的递归(不能一定说是无穷递归, 比如我之前文章中介绍深悉正则(pcre)最大回溯/递归限制). 从而造成爆栈产生的Core.
Ok, 那么现在让我们看看, Core发生在PHP的什么函数中, 在PHP中, 对于FCALL_* Opcode的handler来说, execute_data代表了当前函数调用的一个State, 这个State中包含了信息:
(gdb)f 1#1 0x00000000006ea263 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fbf400210) at /home/laruence/package/php-5.2.14/Zend/zend_vm_execute.h:234234 zend_execute(EG(active_op_array) TSRMLS_CC);(gdb) p execute_data->function_state.function->common->function_name$3 = 0x2a95b65a78 "recurse"(gdb) p execute_data->function_state.function->op_array->filename$4 = 0x2a95b632a0 "/home/laruence/test.php"(gdb) p execute_data->function_state.function->op_array->line_start$5 = 2
现在我们得到, 在调用的PHP函数是recurse, 这个函数定义在/home/laruence/test.php的第二行
经过重复验证几个frame, 我们可以看出, 一直是在重复调用这个PHP函数.
要注意的是, 为了介绍查看执行信息的原理, 我才采用原生的gdb的print来查看, 其实我们还可以使用PHP源代码中提供的.gdbinit(gdb命令编写脚本), 来简单的获取到上面的信息:
(gdb) source /home/laruence/package/php-5.2.14/.gdbinit(gdb) zbacktrace[0xbf400210] recurse() /home/laruence/test.php:3[0xbf400440] recurse() /home/laruence/test.php:3[0xbf400670] recurse() /home/laruence/test.php:3[0xbf4008a0] recurse() /home/laruence/test.php:3[0xbf400ad0] recurse() /home/laruence/test.php:3[0xbf400d00] recurse() /home/laruence/test.php:3[0xbf400f30] recurse() /home/laruence/test.php:3[0xbf401160] recurse() /home/laruence/test.php:3.....
关于.gdbinit, 是一段小小的脚本文件, 定义了一些方便我们去调试PHP的Core, 大家也可以用文本编辑器打开, 看看里面定义的一些快捷的命令, 一般来说, 我常用的有:
zbacktraceprint_ht**系列zmemcheck
OK, 回归正题, 我们现在知道, 问题发生在/home/laruence/test.php的recurse函数的递归调用上了.
现在, 让我们来看看, 在调用这个函数的时候的参数是什么?
PHP的参数传递是依靠一个全局Stack来完成的, 也就是EG(argument_stack), EG在非多线程情况下就是executor_globals, 它保持了很多执行状态. 而argument_statck就是参数的传递栈, 保存着对应PHP函数调用层数相当的调用参数.
要注意的是, 这个PHP函数调用堆栈(层数)不和gdb所看到的backtrace简单的一一对应, 所以参数也不能直接和gdb的backtrace对应起来, 需要单独分析:
//先看看, 最后一次函数调用的参数数目是多少(gdb) p (int )*(executor_globals->argument_stack->top_element - 2)$13 = 1 //再看看, 最后一次函数调用的参数是什么(gdb) p **(zval **)(executor_globals->argument_stack->top_element - 3)$2 = {value = {lval = 22445, dval = 1.1089303420906779e-319, str = {val = 0x57ad <Address 0x57ad out of bounds>, len = 7}, ht = 0x57ad, obj = {handle = 22445, handlers = 0x7}}, refcount = 2, type = 1 '\001', is_ref = 0 '\0'}
好, 我们现在得到, 最后一次调用的参数是一个整数, 数值是22445
到了这一步, 我们就得到了这个Core发生的时刻的PHP层面的相关信息, 接下来, 就可以交给对应的PHP开发工程师来排查, 这个参数下, 可能造成的无穷大递归的原因, 从而修复这个问题..
后记: 调试PHP的Core是一个需要丰富经验的过程, 也许我今天介绍的这个例子太简单, 但是只要经常去挑战, 在遇到不懂的相关的知识的时候, 勇于去追根究底, 我相信大家终都可以成PHP Core杀手..
转载
逆向需要的工具汇总（持续更新中）一、砸壳工具
dumpdecrypted:
Clutch:
二、界面分析工具
Reveal:
三、监控工具
snoop-it:
introspy:
四、静态分析工具
IDA:
Hopper:
五、动态调试工具
lldb:
六、动态脚本工具
cycript:
frida:
七、抓包工具
BurpSuite:
Charles:
Wireshark:
八、Mac工具
MachOView:
九、导出头文件工具
class-dump:
十、THEOS越狱开发工具包
thoes:
十一、文件管理工具
Filza ios设备查看文件系统
iFunBox/iExplorer mac设备查看ios设备的文件系统
十二、debugserver (动态调试,附加子进程)
十三、常用Tweak.xm预处理指令
十四、符号表恢复工具（restore-symbol）
其他工具：
iOSOpenDev:
insert_dylib:
iTerm:
Alfred:
iTools:
更新：2018-8-16
phantomjs ：提供一个浏览器环境的命令行接口，相当于"虚拟浏览器"。
PhantomJS官方地址： 。
PhantomJS官方API： 。
PhantomJS官方示例： 。
PhantomJS GitHub： 。
参考文档：
MonkeyDev ：
这里我就直接copy功能点了：
原有iOSOpenDev的升级，非越狱插件开发集成神器！
frida-ios-dump ：一键砸壳工具，非常的好用。
Hookzz ：通过Hookzz可以快速找到调用的方法，理清程序调用逻辑。
源码：
文档：
关于php.gdbinit的介绍到此就结束了，不知道本篇文章是否对您有帮助呢？如果你还想了解更多此类信息，记得收藏关注本站，我们会不定期更新哦。
查看更多关于php.gdbinit的简单介绍的详细内容...