虽然Mac很少成为安全漏洞和病毒攻击的目标，但软件盗版也并不陌生，因为Mac应用程序很容易破解。下面是如何做到这一点，以及如何防止它。

我怎么破解你的mac应用程序

免责声明：我强烈反对软件盗版，我不参与盗版。有些人会把这篇文章看作是对盗版的认可，但请放心，事实并非如此。然而，我不认为默默无闻和忽视问题是一个可以接受的解决办法。

不是说你，而是说你是指普通的Mac开发者。破解Mac应用程序太容易了。太简单了。通过介绍我如何只用一个终端外壳就可以破解你的应用程序，我希望能让你明白这是最常见的做法，并希望说服你保护自己不受我的伤害。我将用一些技巧来结束这篇文章，以防止这种黑客攻击。

为了继续下去，您将需要一些命令行实用程序。您需要安装Xcode工具。最后，你需要一个应用程序来操作。我选择了Exces，一个我很久以前写的共享软件应用。

让我们首先确保我们有两个我们需要的实用程序：otx和类转储。我喜欢使用自**为我的包管理器的选择。注意，我将只使用命令行实用程序，包括vim。如果您喜欢GUI，可以随意使用您选择的代码编辑器hexfeind和otx的GUI应用程序。

$ sudo brew install otx $ sudo brew install class-dump

第一步是**目标应用程序的标题，由不知情的开发人员保持绅士风度。

$ cd Exces.app/Contents/MacOS $ class-dump Exces | vim

四处浏览，找到以下宝石：

@interface SSExcesAppController : NSObject { [...] BOOL registred; [...] - (void)verifyLicenseFile:(id)arg1; - (id)verifyPath:(id)arg1; - (BOOL)registred;

我们这里有什么？！一个（拼写错误的）变量和三个与注册相关的方法。我们现在可以把精力集中在这些符号上。让我们通过反汇编这些方法的源代码继续讨论。

$ otx Exces -arch i386

请注意，Exces是一个通用二进制文件，我们需要确保只处理活动体系结构。在这种情况下，英特尔的i386。让我们看看verifyLicenseFile:的作用。

-(void)[SSExcesAppController verifyLicenseFile:] [...] +34 0000521e e8c21e0100 calll 0x000170e5 -[(%esp,1) verifyPath:] +39 00005223 85c0 testl %eax,%eax +41 00005225 0f84e2000000 je 0x0000530d [...] +226 000052de c6472c01 movb $0x01,0x2c(%edi) (BOOL)registred [...]

这不是直接的Objective-C代码，而是C编译成的程序集。每行的第一部分，偏移量+34，显示该指令**方法的字节数。0000521e是程序中指令的地址。e8c21e0100是字节码形式的指令。calll 0x000170e5是汇编语言的指令。-[（%esp，1）verifyPath:]是otx可以从二进制文件中留下的符号中收集要在Obj-C中表示的指令。

考虑到这一点，我们可以认识到verifyLicenseFile:调用方法verifyPath:，然后设置boolean实例变量registred。我们可以猜测verifyPath:可能是检查许可证文件有效性的方法。我们可以从标题中看到verifyPath:返回一个对象，因此过于复杂，无法修补。我们需要处理布尔函数的东西。

让我们在gdb调试器中启动execes，并检查何时调用verifyLicenseFile:。

$ gdb Exces (gdb) break [SSExcesAppController verifyLicenseFile:] Breakpoint 1 at 0x5205 (gdb) run

不要咬。启动时未命中断点。我们可以假设verifyLicenseFile:和verifyPath:是两种不同的方法，这是有充分理由的。虽然我们可以修补verifyLicenseFile:以始终将registered设置为true，但调用verifyLicenseFile:可能只是为了检查用户输入的许可证文件。退出gdb，让我们搜索另一段调用verifyPath:的代码。在otx转储中，在awakeFromNib中找到以下内容：

-(void)[SSExcesAppController awakeFromNib] [...] +885 00004c8c a1a0410100 movl 0x000141a0,%eax verifyPath: +890 00004c91 89442404 movl %eax,0x04(%esp) +894 00004c95 e84b240100 calll 0x000170e5 -[(%esp,1) verifyPath:] +899 00004c9a 85c0 testl %eax,%eax +901 00004c9c 7409 je 0x00004ca7 +903 00004c9e 8b4508 movl 0x08(%ebp),%eax +906 00004ca1 c6402c01 movb $0x01,0x2c(%eax) (BOOL)registred +910 00004ca5 eb7d jmp 0x00004d24 return; [...]

代码几乎与verifyLicenseFile相同：。下面是发生的情况：

• verifyPath:被调用(+894（电话）
• 根据调用的结果进行测试(+899（测试L）
• 根据文本的结果，如果相等，则跳转(+901 je）后跟je或jne（如果不相等则跳转）的测试是if语句的汇编语句。
• 如果我们没有跳开的话，注册的ivar已经设置好了。

因为awakeFromNib是在启动时执行的，所以我们可以安全地假设，如果我们重写这个检查，我们可以欺骗应用程序，使其认为它已经注册。最简单的方法就是把je改成jne，基本上颠倒了它的意思。

在转储中搜索任何jne语句，并将其与je进行比较：

+901 00004c9c 7409 je 0x00004ca7 +14 00004d9f 7534 jne 0x00004dd5 return;

7409是je 0x00004ca7的二进制代码。7534是一个类似的二进制代码。如果我们简单地将je的二进制代码切换到地址00004c9c处的7534，我们就可以破解了。让我们在gdb中进行测试。

$ gdb Exces (gdb) break [SSExcesAppController awakeFromNib] Breakpoint 1 at 0x4920 (gdb) r (gdb) x/x 0x00004c9c 0x4c9c <-[SSExcesAppController awakeFromNib]+901>: 0x458b0974

我们从nib中醒来，这样我们就可以在应用程序冻结时随意摆弄。x/x在给定的地址读取内存中的代码。而在磁盘上，二进制代码是正常的，英特尔是一个小endian系统，它把最重要的字节放在最后，从而反转内存中每四个字节的块。因此，虽然地址0x4c9c处的代码打印为0x458b0974，但实际上是0x74098b45。我们可以识别前面的两个字节7409。

我们需要将前两个字节切换到7534。让我们从分解方法开始，以便更好地了解我们的方法。查找相关声明：

0x00004c9c <-[SSExcesAppController awakeFromNib]+901>: je 0x4ca7 <-[SSExcesAppController awakeFromNib]+912>

现在让我们在内存中编辑代码。

(gdb) set {char}0x00004c9c=0x75 (gdb) x/x 0x00004c9c 0x4c9c <-[SSExcesAppController awakeFromNib]+901>: 0x458b0975 (gdb) set {char}0x00004c9d=0x34 (gdb) x/x 0x00004c9c 0x4c9c <-[SSExcesAppController awakeFromNib]+901>: 0x458b3475

这里我们将第一个字节设置为0x00004c9c。通过简单的十六进制计数，我们知道下一个字节位于地址0x00004c9d，并将其设置为这样。我们再拆开一次，看看是否换对了。

(gdb) disas 0x00004c9c <-[SSExcesAppController awakeFromNib]+901>: jne 0x4cd2 <-[SSExcesAppController awakeFromNib]+955>

哎呀，我们搞错了，把跳转的目的地从+912改成了+955。我们意识到字节码的第一个字节（74）代表je/jne，第二个字节是偏移量，也就是要跳转多少字节。我们应该把74改成75，而不是09改成34。让我们改正错误。

(gdb) set {char}0x00004c9c=0x75 (gdb) set {char}0x00004c9d=0x09

再检查一下…

0x00004c9c <-[SSExcesAppController awakeFromNib]+901>: jne 0x4ca7 <-[SSExcesAppController awakeFromNib]+912>

好极了这看起来不错！让我们执行应用程序来欣赏我们的破解。

(gdb) continue

呜呜！胜利！我们加入了，应用程序认为我们是合法客户。浪费时间开派对吧(我推荐旧金山市区的夜总会。好吧，不太好。我们仍然需要使我们的改变永久化。从目前的情况来看，一旦我们退出gdb，一切都将被删除。我们需要编辑磁盘上的代码，在实际的二进制文件中。让我们找到一个足够大的已编辑二进制文件块，它可能不会在整个二进制文件中重复。

(gdb) x/8x 0x00004c9c 0x4c9c <-[SSExcesAppController awakeFromNib]+901>: 0x458b0975 0x2c40c608 0x8b7deb01 0xa4a10855 0x4cac <-[SSExcesAppController awakeFromNib]+917>: 0x89000141 0x89082454 0x89042444 0x26e82414

这是代码的内存表示，从0x00004c9c开始的8个四字节块。考虑到endianness，我们必须反转它们，得到以下结果：

0x75098b45 0x08c6402c 0x01eb7d8b 0x5508a1a4 0x41010089 0x54240889 0x44240489 0x1424e826

这个序列的第一个字节是74，我们把它换成75。通过把它换回来，我们可以把原来的二进制代码推导出：

0x74098b45 0x08c6402c 0x01eb7d8b 0x5508a1a4 0x41010089 0x54240889 0x44240489 0x1424e826

让我们在十六进制编辑器中打开二进制文件。我使用了vim，但现在可以随意使用任何十六进制编辑器。黑魔王有一个伟大的GUI。

(gdb) quit $ vim Exces

这将二进制文件加载为ascii文本，这没有什么帮助。将其转换为十六进制：

:%!xxd

vim格式如下：

0000000: cafe babe 0000 0002 0000 0012 0000 0000 ................

第一部分，在冒号之前，是块的地址。后面是16个字节，分成两个字节段。顺便说一下，每个Mach-O二进制文件都以十六进制字节cafebabe开始。醉醺醺的内核程序员可能会觉得这很有趣。现在我们已经加载了漂亮的十六进制代码，让我们搜索要替换的代码的前两个字节：

/7409

倒霉。太多的结果让人无法理解。我们再加两个字节。搜索“7409 8b45”并弹出，只有一个结果：

001fc90: 0089 4424 04e8 4b24 0100 85c0 7409 8b45 ..D$..K$....t..E

将其编辑为：

001fc90: 0089 4424 04e8 4b24 0100 85c0 7509 8b45 ..D$..K$....t..E

将其转换回二进制格式，然后保存并退出：

:%!xxd -r :wq

然后…我们结束了！要检查我们的工作，请在gdb中启动应用程序，转到[ssexappcontroller awakeFromNib]并反汇编。

$ gdb Exces (gdb) break [SSExcesAppController awakeFromNib] Breakpoint 1 at 0x4c90 (gdb) r (gdb) disas

敬佩我们的工作：

0x00004c9c <-[SSExcesAppController awakeFromNib]+901>: jne 0x4ca7 <-[SSExcesAppController awakeFromNib]+912>

退出gdb，从Finder重新启动应用程序，享受你的leet荣耀。

如何预防

Objective-C让你很容易搞乱应用程序的内部结构。试着用纯C语言为你的应用程序编程许可机制，这已经让我很难找到绕过你的二进制文件的方法了。另外，请阅读我的这篇老文章，其中介绍了三个简单的技巧：剥离调试符号、使用PT_DENY_ATTACH以及对二进制文件执行校验和，这样可以使应用程序更难被破解。

一个真正熟练的黑客总会在你的保护下找到自己的出路，但实施最低限度的安全措施将淘汰99%的业余黑客。我不是一个熟练的黑客与一些非常基本的知识，我撕碎了这个在任何时间。实现上述各种简单的技巧只需要很少的时间，但这对我来说已经足够痛苦，我会放弃。

肯尼思·巴列内格尔开发了很酷的Mac和iPhone软件。访问他的个人博客，了解更多关于设计、软件和生活的文章。你可以打电话联系他[email protected].