我正在尝试追踪内核二进制文件; 有没有办法确定Linux'uImage'二进制文件的版本(构建字符串)?
正在运行
strings uImage
发送到各种尾随grep
语句导致我认为我正在处理压缩图像...
答案 0 :(得分:5)
根据内核的格式规范,这里是C代码:
#include <stdio.h>
int main(int argc, char** argv){
if (argc > 1){
FILE* f = fopen(argv[1], "r");
short offset = 0;
char str[128];
if(f){
fseek(f, 0x20E, SEEK_SET);
fread(&offset, 2, 1, f);
fseek(f, offset + 0x200, SEEK_SET);
fread(str, 128, 1, f);
str[127] = '\0';
printf("%s\n", str);
fclose(f);
return 0;
}else {
return 2;
}
} else {
printf("use: kver [kernel image file]\n");
return 1;
}
}
编译并运行:
gcc -o kver kver.c
./kver /boot/vmlinux-something
答案 1 :(得分:5)
要了解编译的Linux版本,请在未压缩的vmlinux映像上使用strings
实用程序。
例如:
strings linux-src/build/build-generic/vmlinux|grep "Linux version"
示例输出:
Linux version 3.2.0-56-generic (root@puerto-cayo) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #86 SMP Fri Nov 1 10:24:18 EDT 2013 (Ubuntu 3.2.0-56.86-generic 3.2.51)
答案 2 :(得分:3)
我刚刚意识到,我可以立即访问 do 的内核在头文件中存储了未压缩的版本字符串。 strings uImage | grep 2.6
应该足够好用于任何2.6内核,它涵盖了过去5年多来的所有内容。)
(原始答案如下)
这在理论上是可行的,但并非完全无足轻重。
现代Linux内核版本使用名为bzImage的格式(对于x86 / x86_64,其他平台上为YMMV)。它实际上包含一个ELF头和一些其他细节(比如一些解压缩代码),然后是实际内核的压缩图像。
传统上,压缩算法是zlib(与流行的误解相反,'bzImage'确实不代表“bzipped图像”,但对于“大zImage” - 原始的zImage格式不能处理大内核),虽然2.6.30之后的版本也支持bzip2和LZMA。
您可能需要做的是确定压缩数据的确切位置(抱歉,无法帮助您,但试验和错误可能有效),并编写一些代码以通过库运行它无论使用哪种压缩算法。
答案 3 :(得分:2)
试试file uImage
。如果它是一种通常已知的压缩格式,它可能会识别文件格式。除此之外,strings
实用程序可能是执行此任务的最佳实用程序。
答案 4 :(得分:0)
我不确定你会尝试uname -a
这可能是你想要的。
答案 5 :(得分:0)
如果它是x86的内核,它的标题版本。请参阅Documentation/x86/boot.txt(查看kernel_version
字段)。
我不知道其他架构是否也是如此(该头是x86特定的)。
答案 6 :(得分:0)
这将在bzimage上输出内核版本和localversion字符串(如果有人在构建时设置):
strings bzimage |grep -E "^[1-4]\.[0-9][0-9]*\.[0-9][0-9]*" |awk '{print $1}' |head -1
我已经在内核版本3和4上测试了它...但它也应该适用于以前的版本。
strings vmlinuz |grep -E "^[1-4]\.[0-9][0-9]*\.[0-9][0-9]*" |awk '{print $1}' |head -1
4.4.5
strings vmlinux |grep -E "^[1-4]\.[0-9][0-9]*\.[0-9][0-9]*" |awk '{print $1}' |head -1
3.2.45-smp
如果您有uImage,则必须删除“^”,否则它将无法匹配任何内容
strings uImage |grep -E "[1-4]\.[0-9][0-9]*\.[0-9][0-9]*" |head -1
Linux-3.0.76