写着玩-系统调用与API
0x00 口胡
这本书快完了,加快效率。。。
0x01 系统调用
由于系统有限的资源有可能被多个不同的应用程序同时访问,因此,如果不加以保护,那么各个应用程序难免产生冲突。现代OS采取的策略是将这些可能产生冲突的系统资源给保护起来,然后给我们提供相应的接口去让我们按照OS所能接受的范围去操纵这些资源,这些接口就是所谓的系统调用。系统调用是较底层的接口,我们所写的用户层的程序以及运行库这种,它的一些函数都是对系统调用的封装。当然,我们可以直接使用系统调用
系统调用往往通过中断来实现,比如linux使用0x80号中断作为系统调用的入口,windows采用0x2e号中断作为系统调用入口。
对于windows来讲,系统调用实际上不是它与应用程序的最终接口,而是API,我们暂可以把API与系统调用等同起来,API的数量从最初的450个增加到了现在的数千个。
对于linux来说,系统调用由0x80中断完成,各个通用寄存器用于传递参数(如我们熟悉的用EAX传递功能号)我们完全可以绕过glibc的fopen、fread、fclose(这些函数也是封装的系统调用)打开读取和关闭文件,而直接使用open()、read()和close()来实现文件的读取,就不举例了。
我们可以使用linux的man命令查看每个系统调用的详细说明,比如查看read(参数2表示系统调用手册):1
$ man 2 read
系统调用的弊端
不到万不得已,不要直接用系统调用写程序,使用不便和不跨平台(不兼容)
运行库已经帮助我们把系统调用给封装好了,C语言的标准库是跨平台的,就是说他会把平台的差异(即使系统调用符号、实现不同)给屏蔽掉,提供给我们统一的接口,这个接口是统一的功能:
感谢写C标准库的人,使他们使我们的编程变得简单。但是为了保证跨平台性,它只能取所有的平台,所有的OS都支持的功能
关于中断的详细分析,可以去看我写的两篇OS相关的,这里就不啰嗦了。
linux的新型系统调用机制
关于dd命令
也就是说想要dump内存的话,可以通过dd命令,借助/proc/pid/mem的内存快照来达到dump pid对应进程的任意地址处的内存内容
0x02 Windows API
没有什么是加层解决不了的,如果有,就再来一层
Windows API 是指Windows操作系统提供给应用程序开发者的最底层的、最直接与Windows打交道的接口。Windows操作系统下,CRT是建立在Windows API之上的,另外还有很多对Windows API的各种包装库,MFC就是很著名的一种以C++形式封装的库。
其中有一个头文件”Windows.h”包含了Windows API的核心部分,只要我们在程序里面包含了它,就可以使用Windows API的核心部分了。
模块相当于在API的基础上又封装了一层,从而提供更加集成化的功能。
API的核心就是:
不管内核如何改变接口,只要维持API层面的接口不变,理论上所有的应用程序都不用重新编译就可以正常运行,这也是Windows API存在的主要原因,解决兼容性的问题就交给具体的API实现了,我们只需要最后的API接口,我们只需要知道这个接口可以达到什么样的目的就ok了。
0xFF 最终结
此书的最后一章主要讲解了如何去实现一个自己的迷你运行库(miniCRT),以及在最初的架构上如何对其进行扩展,对此没什么兴趣,所以就不谈这一章了。
后面还有一些手册类的东西,比如ELF文件结构中的常见段的一个简要功能介绍,GCC(编译器)命令行参数参考、ld(GNU链接器)命令行参数参考、objdump(GNU目标文件可执行文件查看器)命令行参数参考、cl(MSVC编译器)命令行参数参考、link(MSVC链接器)命令行参数参考、dumpbin(MSVC的COFF/PE文件查看器)
到这,程序员的修养大法这本书就算做完笔记了,也算是给了自己一个交代。
挺不错的一本书,讲了很多理论干货,也算是自己读的比较认真的一本书了。
接下来会去读其他的书,毕竟书是有体系的,跟着书学也能够让自己沉下心来,光看帖子,浏览网站学习容易浮躁,果然还是要打牢理论基础。
接下来的计划就是读C++反汇编与逆向分析这本书,挑战是在最短的时间内干完此书,继续人丑就该多读书系列。
就酱。