之前一直在考虑，不同的内核源码编译出来的ko文件，区别到底是什么？

能不能不编译内核加载内核模块呢？最近逆向分析了linux内核ko模块的结构，事实证明，是可以的。

我在这里给大家分享一些我的心得。

首先分析一个最简单的hello.ko，Makefile就不写了，因为需要尽可能简单，加一行去除调试信息的objcopy -g hello.ko就好。

hello.c

#include <linux/module.h>

#include <linux/kernel.h>

#include <linux/init.h>

static int __init hello_init(void){

printk(KERN_EMERG "\nhello init.\n");

return 0;

}

static void __exit hello_exit(void){

printk(KERN_EMERG "\nhello exit.\n");

}

module_init(hello_init);

module_exit(hello_exit);

MODULE_LICENSE("GPL");

可以看到编译后的ko文件只有2.4Kb。

我这里准备好一个基于arm架构板子交叉编译好的linux3.6.33的linux内核，正经的烧进去，后续简称now kernel。

在胡乱修改make menuconfig的模块结构之后，重新在另一个无关的目录编译另外一个linux内核，后续简称fake kernel。

首先我先把基于fake kernel编译的hello.ko拷贝到我的板子上正在使用的now kernel上，然后执行：insmod hello.ko。

结果什么都没有发生，没有报错，没有执行，没有打印？？？

首先确定了一点，不基于同一套内核源码编译的内核模块是无法直接加载的。那是什么导致了加载失败呢？我们先用二进制编辑器打开刚刚编译的ko文件。

可以看到内核ko文件就是个标准的elf格式的文件，那么我们用readelf读一下ko文件的结构。

readelf -a hello.ko

ELF Header:

Magic:   7f 45 4c 46 01 01 01 6100 00 00 00 00 00 00 00

Class:                            ELF32

Data:                             2's complement, little endian

Version:                          1 (current)

OS/ABI:                           ARM

ABIVersion:                       0

Type:                              REL (Relocatable file)

Machine:                          ARM

Version:                          0x1

Entry point address:              0x0

Start of program headers:         0 (bytes into file)

Start of p headers:         904 (bytes into file)

Flags:                            0x600, GNU EABI, software FP, VFP

Size of this header:              52 (bytes)

Size of program headers:          0 (bytes)

Number of program headers:        0

Size of p headers:          40 (bytes)

Number of p headers:        19

Section header string table index: 16

Section Headers:

[Nr] Name              Type            Addr     Off   Size   ES Flg Lk Inf Al

[0]                   NULL            00000000 000000 000000 00      0  0  0

[1] .text             PROGBITS        00000000 000034 000000 00  AX 0   0  1

[2] .exit.text        PROGBITS        00000000 000034 00001c 00  AX 0   0  4

[3] .rel.exit.text    REL             00000000 000904 000010 08     17  2  4

[4] .init.text        PROGBITS        00000000 000050 000020 00  AX 0   0  4

[5] .rel.init.text    REL             00000000 000914 000010 08     17  4  4

[6] .modinfo          PROGBITS        00000000 000070 000060 00   A  0   0  4

[7] .rodata.str1.4    PROGBITS        00000000 0000d0 000028 01 AMS  0  0  4

[8] .data             PROGBITS        00000000 0000f8 000000 00  WA 0   0  1

[9] .gnu.linkonce.thi PROGBITS       00000000 0000f8 000150 00  WA  0  0  4

[10].rel.gnu.linkonce REL            00000000 000924 000010 08    17   9  4

[11] .note.gnu.build-i NOTE           00000000 000248 000024 00   A  0  0  4

[12] .bss              NOBITS          00000000 00026c 000000 00  WA 0   0  1

[13] .comment          PROGBITS        00000000 00026c 000056 00      0  0  1

[14] .note.GNU-stack  PROGBITS        00000000 0002c2000000 00      0   0  1

[15] .ARM.attributes  ARM_ATTRIBUTES  00000000 0002c2000010 00      0   0  1

[16] .shstrtab         STRTAB          00000000 0002d2 0000b6 00      0  0  1

[17] .symtab           SYMTAB          00000000 000680 0001f0 10     18 27  4

[18] .strtab           STRTAB          00000000 000870 000091 00      0  0  1

Key to Flags:

W(write), A (alloc), X (execute), M (merge), S (strings)

I(info), L (link order), G (group), x (unknown)

O(extra OS processing required) o (OS specific), p (processor specific)

There are no p groups in this file.

There are no program headers in this file.

Relocation p '.rel.exit.text' atoffset 0x904 contains 2 entries:

Offset    Info    Type            Sym.Value  Sym. Name

00000010 00001e01 R_ARM_PC24       00000000   printk

00000018 00000102 R_ARM_ABS32      00000000   .rodata.str1.4

Relocation p '.rel.init.text' atoffset 0x914 contains 2 entries:

Offset    Info    Type            Sym.Value  Sym. Name

00000010 00001e01 R_ARM_PC24       00000000   printk

0000001c 00000102 R_ARM_ABS32      00000000   .rodata.str1.4

Relocation p'.rel.gnu.linkonce.this_module' at offset 0x924 contains 2 entries:

Offset    Info    Type            Sym.Value  Sym. Name

000000d4 00001d02 R_ARM_ABS32      00000000   init_module

00000140 00001c02 R_ARM_ABS32      00000000   cleanup_module

There are no unwind ps in this file.

Symbol table '.symtab' contains 31 entries:

Num:    Value  Size Type   Bind   Vis      Ndx Name

0: 00000000     0 NOTYPE  LOCAL DEFAULT  UND

1:00000000     0 SECTION LOCAL  DEFAULT   7

2: 00000000     0 NOTYPE  LOCAL DEFAULT    2 $a

3: 00000000    28 FUNC    LOCAL DEFAULT    2 hello_exit

4: 00000018     0 NOTYPE  LOCAL DEFAULT    2 $d

5: 00000000     0 NOTYPE  LOCAL DEFAULT    4 $a

6: 00000000    32 FUNC    LOCAL DEFAULT    4 hello_init

7: 0000001c     0 NOTYPE  LOCAL DEFAULT    4 $d

8: 00000000     0 NOTYPE  LOCAL DEFAULT    6 $d

9: 00000000    12 OBJECT  LOCAL DEFAULT    6 __mod_license18

10:00000000     0 NOTYPE  LOCAL DEFAULT    7 $d

11: 0000000c     0 NOTYPE  LOCAL DEFAULT    6 $d

12: 0000000c    35 OBJECT  LOCAL DEFAULT    6 __mod_srcversion23

13: 00000030     9 OBJECT  LOCAL DEFAULT    6 __module_depends

14: 0000003c    34 OBJECT  LOCAL DEFAULT    6 __mod_vermagic5

15: 00000000     0 NOTYPE  LOCAL DEFAULT    9 $d

16: 00000000     0 SECTIONLOCAL  DEFAULT    1

17: 00000000     0 SECTIONLOCAL  DEFAULT    2

18: 00000000     0 SECTIONLOCAL  DEFAULT    4

19: 00000000     0 SECTIONLOCAL  DEFAULT    6

20: 00000000     0 SECTIONLOCAL  DEFAULT    8

21: 00000000     0 SECTIONLOCAL  DEFAULT    9

22: 00000000     0 SECTIONLOCAL  DEFAULT   11

23: 00000000     0 SECTIONLOCAL  DEFAULT   12

24: 00000000     0 SECTIONLOCAL  DEFAULT   13

25: 00000000     0 SECTIONLOCAL  DEFAULT   14

26: 00000000     0 SECTIONLOCAL  DEFAULT   15

27: 00000000   336 OBJECT  GLOBAL DEFAULT    9 __this_module

28: 00000000    28 FUNC    GLOBAL DEFAULT    2 cleanup_module

29: 00000000    32 FUNC    GLOBAL DEFAULT    4 init_module

30: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND printk

No version information found in this file.

Notes at offset 0x00000248 with length 0x00000024:

Owner              Data size       Description

GNU         0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring)

Attribute Section: aeabi

File Attributes

下面我们读一下这个二进制文件，elf头52个字节，也就是读到0x34。elf结构网上资料很多，这里就不赘述了。

可以看到0x34个字节的elf头之后紧跟着0D C0 A0 E1 00 D8 2D E9  04 B0 4C E2  04 00 9F E5 FE FF FF EB

对照上面readelf的输出，开头零地址对应的是.text段，相对文件的跳转位置是0x34，

接下来使用objdump工具逆向读取一下后面的arm汇编段。

objdump -S hello.ko

00000000 <cleanup_module>:

0:      e1a0c00d     mov       ip, sp

4:      e92dd800     push       {fp, ip, lr, pc}

8:      e24cb004     sub  fp, ip, #4       ;0x4

c:       e59f0004     ldr   r0, [pc, #4]   ;18 <cleanup_module+0x18>

10:      ebfffffe  bl    0 <printk>

14:      e89da800     ldm sp, {fp, sp, pc}

18:      00000000     .word     0x00000000

Disassembly of p .init.text:

00000000 <init_module>:

0:      e1a0c00d     mov       ip, sp

4:      e92dd800     push       {fp, ip, lr, pc}

8:      e24cb004     sub  fp, ip, #4       ;0x4

c:       e59f0008     ldr   r0, [pc, #8]   ;1c <init_module+0x1c>

10:      ebfffffe  bl    0 <printk>

14:      e3a00000     mov       r0, #0     ;0x0

18:      e89da800     ldm sp, {fp, sp, pc}

1c:      00000014     .word     0x00000014

可以看到，这个项目的汇编代码其实只有60个字节。开头的 e1a0c00d， e92dd800，跟阅读ko二进制文件的0D C0 A0 E1 00 D8 2D E9  04 B0 4C E2  04 00 9F E5 FE FF FF EB也是一一对应的。开头是 cleanup_module，机器码跟汇编是一一对应的。

那么我们的ko模块加载无效，是不是汇编段导致的问题呢？printk这种代码还是太复杂了，我们把这个汇编段精简一下，只保留一行arm汇编：mov pc, #9

汇编语言跟机器码是一一对应的，查表手算一下，可以知道这行命令对应的机器码是：e3a0f009

让整个程序精简到4个字节，上来就把pc指针置为9，触发内核panic，通过查看内核panic的寄存器状态，看pc指针的值是不是9，判断程序是否执行。

我们直接修改文件二进制，找到init_module对应的汇编代码入口位置e1a0c00d，把它改成这样。

可以看到，删掉了汇编段所有代码，把汇编段第一条命令改成了09 F0 A0 E3，字节序问题，也就是上面手算的e3a0f009，mov pc, #9指令了。

我们继续尝试，只有一行汇编的ko文件能否成功加载。

Insmod hello.ko

结果什么都没有发生，哪怕是崩溃，都没有，成功加载，一点反应都没有。

看样子不是汇编的问题，这后面紧跟着的是只读常量段，C语言里写的hello exit和hello init也在。这后面一堆零，是预留给堆栈区的空间。具体应该跳过多少呢？

 只读常量段

翻到上面，从上面readelf的输出可以看到，

Start of p headers:          904 (bytes into file)

去掉52个elf头，汇编段大小是852字节，让我们直接跳到目的地。

可以看到光标所在位置就是elf格式的p header了，前面紧接着的都是些字符串、模块信息之类了。

可以继续翻上去看readelf的输出，p header一共0-18，也就是19个段。一个加载就崩溃的模块，我们不需要exit段，那让我们仅保留下面几个段：

.text，.init.text，.rel.init.text，.modinfo（模块信息，内核会读取识别这个段的数据），.symtab（保存了很多symbol信息，还是有必要留一下的），.shstrtab（段的名字，需要保留一下），.gnu.linkonce.this_module，.rel.gnu.linkonce.this_module这几个段。暴力一点，把其他的段全都删了吧。

在elf格式里，每个p header是40字节，就从光标所在位置往下数，仅保留需要的段部分，其他的全都删除。

重新readelf看一下seciton内容变成了现在这样。

我们重新逆向一下修改后的汇编代码

嗯，很好，就剩一行汇编了，干净多了。

让我们再逐渐把无关的东西清理的更干净一些。（逐渐忘记最初的目的，→_→）

rel.init.text段标注了汇编段指定位置的动态预留地址，因为现在已经没有printk了，删！对应的二进制位置在这里。

.symtab段里有大量的标号，除init_module、cleanup_module、__this_module等一些有symbol的位置信息外，其他不用的，全部删除。

这下面紧接着的是symtab的位置信息，这是真正保存命名的字符串数据，这部分都是寻找字符串命名的，在此就不赘述了。

这里多截取了一些，但是可以看到，这个ko文件打开二进制，在修改的情况下，基本整个读完了。

最后，还剩余 48字节没读，也是最关键的48字节了，这里先卖个关子。

让我们把删的面目全非的ko文件扔到内核里加载一下看看，还能用不。。。

insmod hello.ko

嗯，依然没有任何反应，ismod可以看到模块成功加载了，但是如果pc置为9，应该会触发panic才对，但是依然是一行汇编都没有执行的状态。

我们回来继续读这关键的48字节所对应的Relocation p段。首先简单介绍一下这一段是干什么用的，为什么是ko模块对接最关键的段。

内核ko模块加载的时候一定会调用外部的函数，比如printk函数，这个printk函数的汇编代码在内核的某个位置，执行期加载到了内存的某个位置。我的模块怎么找到这个函数的真实汇编调用呢？内核在加载ko模块的时候，会读取Relocation p段，你需要什么函数，symbol名字是什么。内核在动态寻找这个printk函数对应的正在运行的内核的内存位置，然后在加载ko模块的时候，将printk在内核里运行时的真实内存地址覆盖到这个ko模块的指定位置，这样在ko模块执行到调用printk这行ebfffffe汇编的时候，调用的就是内核printk真实的地址了。

首先，exit段被我删了，这里readelf显示的对应位置开始缺失了，请滚动到最上方查看最初的readelf的exit段打印

[3].rel.exit.text    REL             00000000 000904 000010 08     17  2  4

Relocation p '.rel.exit.text' atoffset 0x904 contains 2 entries:

Offset    Info    Type            Sym.Value  Sym. Name

00000010 00001e01 R_ARM_PC24       00000000   printk

00000018 00000102 R_ARM_ABS32      00000000   .rodata.str1.4

0x0940的位置是exit段的Relocation p段，可以看到00000010  00001e01，00000018  00000102，这个开头跟最后48字节的开头完全一致，既然exit段都没了，可以删！

Relocation p '.rel.init.text' atoffset 0x914 contains 2 entries:

Offset    Info    Type       Sym.Value  Sym. Name

00000010 00001e01 R_ARM_PC24       00000000   printk

0000001c 00000102 R_ARM_ABS32      00000000

init段里还有个printk的动态入口？现在就一行汇编，这个Relocation p段已经没用了，也可以删。

终于到了最后时刻，有兴趣的朋友可以测试一下，现在ko模块依然能正常加载成功，但是依然不执行没有反应。

我们还剩下16字节没有修改，这16字节分为两组，读readelf打印可以看到，分别表示：

000000d4 00001d02 R_ARM_ABS32      00000000   init_module

00000140 00001c02 R_ARM_ABS32      00000000   cleanup_module

因为cleanup_module对应的exit段已经不存在了，我们继续删。好了，还剩余8字节。

明显前4字节表示的是offset位置，后4字节表示的是info信息，但这4字节到底是怎么来的呢？笔者尝试修改后4个字节info信息，发现加载ko的时候开始失败了，提示信息为unknown symbol。这个info是如何算出来的呢，我暂时也没有找到相关信息，希望有知道的好心读者能告知一下。

最后让我们看一下offset这4字节，其实就是内核加载ko模块时候的入口相对地址，我们先从上述now kernle里面找一个正常能用的ko文件出来，读一下二进制。

我这里使用了能正常使用的ebtables.ko模块，可以看到对应的init_module的offset地址是BC 00 00 00，而我的hello.ko的offset地址是D4 00 00 00。让我们手动把入口地址改为BC 00 00 00。

insmod hello.ko

成功触发kernel panic，查看pc指针值，就是9，终于成功加载了。

已经写的够长了，后面的就不赘述了，因为内核ko模块的地址全部是按照相对地址计算的，除了这一行汇编。类似printk，nf_register_hook，register_sysctl_table等常用的调用测试，均不影响正常使用。

所以当无法完美使用之前内核代码的情况下，编译一个magic code一致的假的fake kernel，只要版本基本一致，头文件没有什么区别，编译出来的ko文件，修改一下.rel.gnu.linkonce.this_module段的offset地址，info信息不用改动，就能在没有编译过的内核上完美正常运行自己编译的内核ko模块了。

1.人工智能：嵌入式技术的机遇与挑战

2.厉害了！用6个芯片打造复古经典计算机

3.国产操作系统这盘棋不简单

4.做嵌入式必须知道的国产CPU之路，里面有良机！

5.Linux是否能在8位MCU上运行？

6.为了适合你的项目，rt-thread有时候需要裁剪！