问题描述
我正在尝试跟踪内核二进制文件； 是否可以确定Linux'uImage'二进制文件的版本(构建字符串)?
运行
strings uImage
通过管道输入各种尾随的grep语句使我认为我正在处理压缩图像...
strings uImage | grep 2.6对于任何涵盖过去5年以上的几乎所有内容的2.6内核都应该足够好.(后接原始答案)
从理论上讲这是可能的，但并非完全无关紧要.
现代Linux内核版本使用一种称为bzImage的格式(对于x86/x86_64，在其他平台上为YMMV).它实际上由一个ELF标头和其他一些细节(例如一些解压缩代码)组成，然后是实际内核的压缩图像.
传统上，压缩算法是zlib(与流行的误解相反，'bzImage'并非 代表"bzipped image"，但代表了"big zImage"-原始的zImage格式无法处理大型内核)，尽管2.6.30之后的版本也支持bzip2和LZMA.
您可能需要做的是确定压缩数据的确切位置(对不起，无法在那儿为您提供帮助，但是反复试验可能会起作用)，并编写一些代码以通过压缩库运行该代码，无论使用哪种压缩算法.
I'm trying to track down a kernel binary; is there a way to determine the version (build string) of a Linux 'uImage' binary?
Running
strings uImage
piped into various trailing grep statements leads me to think I'm dealing with a compressed image...
I just realized, the kernels I have immediate access to do have the version string stored uncompressed amongst the headers. strings uImage | grep 2.6 ought to be good enough for any 2.6 kernel which covers pretty much everything in the last 5+ years).
(original answer follows)
It's theoretically possible, but not entirely trivial.
Modern Linux kernel versions use a format called bzImage (for x86/x86_64, YMMV on other platforms). It actually consists of an ELF header and some other minutia (like a bit of decompression code) followed by, yes, a compressed image of the actual kernel.
Traditionally, the compression algorithm was zlib (contrary to popular misconception, 'bzImage' did not stand for "bzipped image", but for "big zImage" -- the original zImage format not being able to handle large kernels), though versions after 2.6.30 also support bzip2 and LZMA.
What you'll probably have to do is determine exactly where the compressed data starts (sorry, can't help you there, but trial and error might work), and write a bit of code to run it through the library for whichever compression algorithm is in use.
这篇关于如何确定Linux内核"uImage"的构建/版本?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！