通过谷歌快速搜索发现了这一点，但是我不确定该方法是否仍然适用于OS X（10.10）。 ，还是应该将.kext复制到主机OS（Linux）并开始在诸如Hopper / Radare2之类的反汇编程序中进行分析？扩展是用C ++编写的，而大多数（如果不是全部）Linux驱动程序是用C编写的。那么，我会浪费我的时间来反转/分析此.kext吗？在这个主题上的任何帮助将不胜感激。
#1 楼
直接回答您的问题：您可以使用IDA Pro，Radare2，GDB或您想要的任何反汇编器来反向扩展内核。是的，您将必须学习反汇编后的C ++结构。我无法回答“静态分析还是动态分析？”直接提出问题，因为答案通常是“两者都取决于您想要的东西”。一些反向工程师从静态开始，而另一些则从动态开始。
我个人将从静态分析工具入手，因为：
我认为驱动程序很大。如果您不知道要查找的内容，则可能要花费很长的时间进行单步操作。
通过搜索并分析驱动程序中的特定函数调用，您将获得更多收益。一旦看到它们与其他功能的关系，它们的使用很可能在驱动程序中很明显。
这里没有混淆的元素。您也不需要检查任何内容在内存中的确切位置。
无论如何，您都试图以此来重写驱动程序，以类似于源代码的格式查看内容将有助于该过程。
但是每个人都有。如果有足够的时间，我会为了了解而进行这两个过程。另外，要正确完成此操作，您将需要了解一些有关Macintosh系统编程的知识。
今年，有一个关于这一主题的侦查课：http://www.recon.cx/2015/trainingosx.html（一旦白皮书发布，应该在此答案中链接）
这是一本有关内核开发的书的摘录，其中介绍了使用IDA pro反转kext的基础知识：
https://books.google.com /书籍？ID = G6Zeh_XSOqUC＆PG = PA215与LPG = PA215＆DQ = IDA +职业+内核+扩展+ MAC和源= BL＆OTS = 0y3XXMAgqH与SIG = 6HkJnGKmW7OugZiHo42DwOYtaY8＆HL = EN＆SA = X＆EI = 93nbVIe_BYWVyQT4z4HgDw＆VED = 0CEIQ6AEwBQ＃v = onepage＆q = IDA％20pro％20kernel％20extension％20mac＆F =假
关于此特定摄像机：
似乎在以下对话中引用了该摄像机：https://bugzilla.kernel.org/show_bug.cgi?id=71131
本质上，此摄像机通过PCI进行语音通信，因为它在发送到系统之前不会压缩视频。该线程指出，已经有一个项目在为相机制作驱动程序，可以在https://github.com/patjak/bcwc_pcie
上找到该站点上的Wiki，内容丰富，并列出了反向驱动这类驱动程序的一些问题。 Wiki页面位于：https://github.com/patjak/bcwc_pcie/wiki/Mac-OS-X-driver提供了一些很好的想法，说明您应该从Mac方面开始。
基于他们的任务清单，您可能希望专注于帮助从设备本身中窃取设备固件。
关于开发自己的驱动程序：
我将从另一个方向开始，然后对相机本身进行反向工程。根据相机的复杂程度，您可能无需串行驱动程序就可以直接与之通话。您也许还可以打开相机，并通过调试端口直接与之对话（想想JTAG，甚至更简单）。电脑外的小型相机，但我想您的意思是笔记本电脑内置的相机。我认为在这种情况下，您只需改编现有网络摄像头中的驱动程序，然后查看驱动器死于何处。我认为这些相机目前在硬件上是相当通用的。
Linux上的大多数网络摄像头都使用此驱动程序：https://help.ubuntu.com/community/UVC，可能您可以只运行该驱动程序，看看它死于哪里/无法与相机。无论如何，观看与相机的实际通信将使您对需要做的事情有更好的了解。
关于反转Macintosh内核扩展的实用程序：
我不必担心c ++ / C的差异以及系统库和系统调用接口的差异。分析驱动程序以适应您自己的需求当然不会受到任何损害，但是您可能会发现，通过调用在Linux中工作方式不同的mac系统库可以完成大部分工作。您将最有兴趣阅读驱动程序中定义与相机通讯的部分。无论如何，您将无法直接将KeXT转换为Linux内核模块。
我的最终建议：
相反，如果您当前的网络摄像头不适用于Linux发行版，则我将首先确认您具有正确的通用驱动程序，然后进行编辑支持相机的通用驱动程序。您可以在通用驱动程序上执行拉取请求。
在大多数情况下，与这些摄像机的通信是非常简单的串行通信。我怀疑从通用驱动程序触发错误比尝试解密mac驱动程序更快。
评论
主要问题似乎是，尽管大多数网络摄像头都连接到USB总线，但该网络摄像头具有直接的PCI接口。因此，任何封装了USB协议的驱动程序都会失败，所有漂亮的USB监听方法也会失败。我仍然希望该芯片是去除了USB部分的某种标准芯片，而不是“新的”实现，因此阅读同一制造商提供的类似硬件的数据表以及理解类似硬件的驱动程序仍然会有所帮助。 。
–贡特拉姆·布洛姆（Guntram Blohm）
2015年2月11日在19:10
不会恰好与此凸轮相似吗？ bugzilla.kernel.org/show_bug.cgi?id=71131
–baordog
2015年2月11日在19:21
似乎正是这个凸轮。
–贡特拉姆·布洛姆（Guntram Blohm）
2015年2月11日在19:29
更新了答案
–baordog
2015年2月11日在19:57
@baordog是的，您说的是Broadcom 1570 PCI设备是正确的。至于编写FW提取实用程序，似乎已经完成了，并已发布在上面列出的github项目页面上。感谢您的详尽回答。
– ipatch
15年2月12日在18:45
评论
它所使用的语言是无关紧要的。 C ++ vs. C只是面向对象而不是对象的问题。我想这个问题归结为您要做什么？第三方.kext与网络摄像头的其他驱动程序不同。我想对于您反转.kext的原因有些困惑。您是否正在尝试验证其自身的安全性做法？@raz实际上，反转真实的C代码比C ++容易。那是因为C语言的简单性。C++有时会骗你。
@AcidShout我同意反汇编有很大的不同。但是，无论驱动程序是用C ++还是C编写的，对其在系统上产生的总体影响都无关紧要。如果这样的话。
@raz我想在.kext周围打一下，因为它是大多数MacBook Pro和某些MacBook Air的Broadcom 1570设备的“驱动程序”。到目前为止，还没有Linux驱动程序，因此我认为将二进制文件放入反汇编程序中将有助于理解硬件。也没有1570设备的数据表，因此它使理解硬件变得更加有趣;）