Hi all,

I have a kernel image that includes a built-in module. I would like to recompile this kernel and include the driver as a loadable, rather than built-in, module. The driver requires firmware, and the vendor is having trouble contacting someone that can send it to me. In talking to them, they suggested that I might be able to extract the compiled-in firmware from the kernel image.

It seems like I'm about half-way there... I took the kernel and extracted it with binwalk:

In there, I looked for the a section that includes a couple registers/pages that have known values from their documentation.

For example, we know that page 0xfb, register 0x24 contains the screen height and 0x28 is the width. So I can search the extracted kernel and find:

I was able to find these areas, but that was as far as I could get. Neither I nor the person I'm in touch with there knows enough at this point to do anything but identify the location of these few values. We don't know what denotes the beginning or the end of the firmware, and we aren't sure if it lives in one continuous block, or if it gets mutilated somehow in the image.

If you have knowledge of how the kernel image is formatted and can help us figure out how to make sense of how the firmware is stored in there, we would appreciate it.

Thanks!

So you do not have source to rebuild even the built-in form? This firmware should be a data table within the source of that driver. Even if you do not have the exact same firmware as part of your source, you should be able to see the size of that firmware table, see if it is located somewhere specific, or examine adjoining memory spaces to detect boundary variables which are not part of that table, but define the next and previous locations in memory. Good luck. Not saying this is impossible, but it seems very difficult. For me a working example in a debugger would be ideal. Running the code, able to stop it just at the point where the driver chooses to address this firmware, presumably for loading it to some device, and at that point I'd be able to extract the firmware table.

Maybe that's a way to find it. My thinking is that this driver, during initialization addresses this firmware, reading it from the program memory table and writing it to a specific address. Search for code which does this and when you encounter it, you can see the start, loop write, and then finish. Once again, examining static hex code is far more difficult as opposed to being able to observe this working under a debugger.

Sadly, no. I'll spare you the whole saga, but basically, no one in the entire supply chain has the code anymore. They're just cloning the kernel images.

I think this is kind of what I was thinking. Unfortunately, I'm not sure how to do this without being able to compile it myself. If you have any resources for further reading, I would be happy to try.

Agreed!

Please correct my understanding here... are you saying that it's possible to somehow load the existing kernel in some kind of debugging mode? I could see how this might be done if I could compile the kernel myself, but if there are ways to debug compiled kernels while they load, then that seems relatively promising.

Thanks!

My comment about running on the debugger depends on being able to rebuild the kernel and this driver. I'm understanding that you're only working with binary/hex. So the thoughts I had about being able to look at it in the debugger are irrelevant because you cannot built the original kernel and driver. Unless you can discern the assembly instructions where the addressing and loading of that firmware is performed, you can't go much farther.

UML and VM. You can run linux in linux and therefor debug kernels. There's really no other way to do it. Although you would kind of need a kernel compiled with debugging information so the debugger could do something useful. Which is not likely the setup for the firmware you're trying to access.

# modinfo <module>

Perhaps there's meta data for the author and such to get the source and firmware directly, instead of indirectly. In most modern setups the firmware is loaded from /lib/firmware/*, not embedded in the module. Have you tried using strings on the module? It might have a path and firmware name in there. Noting that modules in the kernel changed dramatically between kernels 2.4 and 2.6+

While this may be a legal issue that doesn't cover the technical question part.

That being can you get a built in module out? Yes, maybe.
http://superuser.com/questions/57730...-the-linux-ker

http://blog.packagecloud.io/eng/2016...image-vmlinuz/

http://stackoverflow.com/questions/2...-using-objdump

It is a lot easier building a kernel than trying to unbuild it.

Might be some way to disable it either in grub or some sort of blacklist but not sure just yet.

I agree completely.

The firmware file is built directly into your binary kernel image. Than the kernel calls for the firmware it needs.

http://www.berkes.ca/guides/linux_kernel.html

The bottom line is going to be that the source-code to that module must be found ... or, reconstructed ... by the vendor.

You can build a module to be loadable or compiled-in, according to settings in the kernel make-file, but in the latter case it is statically linked into the kernel image and cannot be removed.

1 members found this post helpful.

OP would have to use C++ to build the module right?

Since, as far as I know, "C++" is not supported in the kernel environment, I would expect that ordinary gcc would have been used.

Somewhere, in the archives of the vendor company or one of its predecessors, the source-code to this module and to the firmware must exist. If they don't now know where it is, then it quite-literally is "their business" to find it.

1 members found this post helpful.

Roger that:-