4

I recently discovered there is no native Linux driver for the Web Cam in my computer. However, there is a person who has taking the initiative to start a github project for a driver. That being said, I was able to get the web cam working in a qemu guest OS running OS X (10.10), and now I'm at the point where I would like to start to analyze the .kext is question.

A quick google search revealed this, but I am not sure if this method would still apply to OS X (10.10).

Should I try to debug the .kext on a running system, or should I just copy the .kext to my host OS (Linux) and start analyzing in a disassembler such as Hopper / Radare2?

Also I should note, from what I understand, most OS X kernel extensions are written in C++ while most if not all Linux drivers are written in C. So would I be wasting my time reversing / analyzing this .kext? Any help on this subject matter would be greatly appreciated.

  • The language its written in is slightly irrelevant. C++ vs. C is only a matter of object oriented versus not. I guess the question comes down to what are you trying to do? The 3rd party .kext will be different than another driver for your webcam. I guess I'm a bit confused as to the reason you're reversing the .kext. Are you trying to verify its own security practices? – RoraΖ Feb 10 '15 at 19:14
  • @raz actually, reversing real-world C code is easier than C++. that's because of the simplicity of C. C++ can fool you sometimes. – rev Feb 10 '15 at 19:16
  • @AcidShout I agree the disassembly is extremely different. But whether or not the driver is written in C++ vs. C shouldn't much matter for the overall effect it has on the system. If that makes sense. – RoraΖ Feb 10 '15 at 19:18
  • @raz I wanted to poke around the .kext because it is the "driver" for the Broadcom 1570 device found in most MacBook Pro's, and some MacBook Air's. As of right now there is no Linux driver, so I thought putting the binary in a disassembler would help in understanding of the hardware. Also there is no datasheet for the 1570 device, so it make understanding the hardware that much more fun ;) – ipatch Feb 10 '15 at 20:59
7

Answering Your Question Directly:

You can reverse Kernal Extensions with IDA Pro, Radare2, GDB or whatever dissasembler you would like. Yes, you will have to learn what C++ structures look like once disassembled. I can't answer the "static analysis or dynamic analysis?" question directly, since often the answer is "both, depending on exactly what you want." Some Reverse Engineers start with the static, and some start with the dynamic.

I personally would start with a static analysis tool because:

  • I imagine the driver is rather large. If you don't know what you are looking for, you could spend a long, long time single stepping.
  • You will get more out of this by searching over and analyzing specific function calls in the driver. Their use will most likely be self evident in the driver once you see their relation to other functions
  • There isn't an element of obfuscation here. Nor do you need to check the exact position of anything in memory.
  • You are trying to rewrite a driver from this anyway, seeing things in a format that resembles source code will help that process.

But to each his own. Given enough time I would go through both processes just for the sake of knowing. Also, to pull this off correctly, you will need to learn a little about Macintosh system programming.

There is a class at recon on this subject this year: http://www.recon.cx/2015/trainingosx.html (once the white paper is published, it should be linked in this answer)

Here is a snippet from a book on kernal exploitation that takes you through the basics of reversing a kext with IDA pro:

https://books.google.com/books?id=G6Zeh_XSOqUC&pg=PA215&lpg=PA215&dq=IDA+pro+kernel+extension+mac&source=bl&ots=0y3XXMAgqH&sig=6HkJnGKmW7OugZiHo42DwOYtaY8&hl=en&sa=X&ei=93nbVIe_BYWVyQT4z4HgDw&ved=0CEIQ6AEwBQ#v=onepage&q=IDA%20pro%20kernel%20extension%20mac&f=false

Regarding this particular camera:

It seems that the camera in question is referenced in the conversation found here: https://bugzilla.kernel.org/show_bug.cgi?id=71131

Essentially, this camera speaks over PCI because it does not compress its video before being sent to the system. The thread states that there is already a project underway to make a driver for the camera, which can be found at https://github.com/patjak/bcwc_pcie

The wiki on this site is informative, and lists some of the issues with reverse engineering this sort of driver. The wiki page found at: https://github.com/patjak/bcwc_pcie/wiki/Mac-OS-X-driver gives some great ideas for where you should be starting on the mac side of things.

Based on their to do list, you might want to focus on helping rip the device firmware from the device itself.

Regarding developing your own driver:

I would start from a different direction, and reverse engineer the camera itself. Depending on the complexity of your camera, you may be able to speak to it directly without a driver over serial. You might also be able to open up the camera, and speak to it directly via a debug port (think JTAG, or even simpler.)

The first time I read your question, I thought you meant a small camera outside your computer, but I am guessing you mean a camera built into your laptop. I think in that case, you could just adapt a driver from an existing webcam, and see where it dies. I believe these cameras are fairly generic bits of hardware at this point.

Most webcam's on Linux use this driver: https://help.ubuntu.com/community/UVC, and potentially you can just run this driver and see where it dies/can't communicate with the camera. At any rate, watching the actual communications with the camera will give you a much better idea of what you need to do.

Regarding the Utility of reversing a Macintosh Kernal extension:

I would be less worried about the c++/C difference versus differences in system libaries, and the system call interface. It certainly wouldn't hurt to analyze the driver for your own edification, but you may find that it gets most of its work done by calling mac system libraries that don't work the same way in linux. You will be most interested in reading the parts of the driver that define the communication with the camera. At any rate, you wont be able to directly convert the KeXT into a Linux Kernal Module.

My Final Advice:

Instead, if your current webcam isn't working with your linux distro, I would first confirm that you have the proper generic driver, and then edit the generic driver to support your camera. You can do a pull request on the generic driver.

In most cases the communications with these cameras are very simple serial communications. I suspect that triggering an error from the generic driver will be faster than trying to decipher the mac driver.

  • The main problem seems to be that while most webcams attach to the USB bus, this one has a direct PCI interface. So any driver that encapsulates whatever protocol in USB will fail, as will all the nice USB snooping methods. I'd still expect the chip to be some standard chip with the USB part stripped, instead of a "new" implementation, so reading the datasheets of similar hardware by the same manufacturer, as well as understanding drivers for similar hardware, will still help. – Guntram Blohm supports Monica Feb 11 '15 at 19:10
  • Wouldn't happen to be similar to this cam? bugzilla.kernel.org/show_bug.cgi?id=71131 – baordog Feb 11 '15 at 19:21
  • Seems to be exactly this cam. – Guntram Blohm supports Monica Feb 11 '15 at 19:29
  • updated the answer – baordog Feb 11 '15 at 19:57
  • @baordog Yeah you are correct in saying the camera in question is the Broadcom 1570 PCI device. As for writing a FW extraction utility, it appears that has already been done, and it has been posted on the github project page you listed above. Thanks for the thorough answer. – ipatch Feb 12 '15 at 18:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.