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.
