iPhone Mach-O 二进制文件、字符串存储、__TEXT/__DATA
我正在尝试从 iPhone Mach-O 二进制文件读取常量（或初始化）字符串。据我所知，3个相关的segment.sections是_TEXT._cstring _TEXT._ustring和_DATA._cfstring。然而，尽管我知道字符串信息存储在我提取的这三个数据块中，但我无法理解它，而且它看起来都是垃圾 - 我没有看到任何可识别的字符串。任何人都可以阐明这一点并让我了解需要采取哪些步骤来读取字符串数据？
我查看了一些代码（来自 http: //llvm.org/svn/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp），但同样，无法将其与我的内容完全联系起来请参阅二进制文件。
在我的例子中，有问题的部分的大小是：
__TEXT.__cstring (99 K-bytes)
__TEXT.__ustring (<200 bytes)
__DATA.__cfstring (29 K-bytes)
为了给你一个想法， __cfstring 部分的前 32 个字节，我认为它包含实际的字符串，看起来像这样：
Dump _DATA. _cfstring
00 00 00 00 c8 07 00 00 74 02 0d 00 15 00 00 00
00 00 00 00 c8 07 00 00 8c 02 0d 00 01 00 00 00
...
非常感谢您的帮助！
I am attempting to read constant (or initilization) strings from an iPhone Mach-O binary file. I understand that the 3 relevant segment.sections are _TEXT._cstring _TEXT._ustring and _DATA._cfstring. Howver, even though I know the string information is stored in these three blocks of data, which I have extracted, I can not make any sense of it, and it all looks like garbage - I do not see any recognizable character strings. Can anyone shed some light on this and give me an idea of what steps need to be take to read the string data?
I have looked at some code (GetAddrOfConstantCFString() from http://llvm.org/svn/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp), but again, couldn't quite relate it to what I see in the binaries.
In my case the sizes of the sections in question are:
__TEXT.__cstring (99 K-bytes)
__TEXT.__ustring (<200 bytes)
__DATA.__cfstring (29 K-bytes)
To give you an idea, the first 32 bytes of the __cfstring section, which I though would contain the actual strings looks like this:
Dump _DATA._cfstring
00 00 00 00 c8 07 00 00 74 02 0d 00 15 00 00 00
00 00 00 00 c8 07 00 00 8c 02 0d 00 01 00 00 00
...
Thanks a lot for your help!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
嗯，我找到了答案。
1）文件通常是加密的（可以使用 otool -l prog_file|grep -i crypt 进行测试）。并非所有部分都被加密，但通常包括 _TEXT._text（程序代码）和 _TEXT._cstring 在内的第一个块都被加密。在我的例子中，_DATA._cfstring 部分未加密。
2) 正如预期的那样，__cfstring 由 16 字节结构 (NSConstantString) 组成，其中第三个字是指向加载 _TEXT._cstring 的内存的指针。第4个字是长度。
因此，在现实生活中，诀窍是首先解密文件，然后所有内容都可见且可访问。我仍然没有设法正确地执行此操作，而是将一块内存转储到 gdb 中，然后替换文件中的相关部分。
Well, I've found the answer.
1) the files are generally encrypted (this can be tested with otool -l prog_file|grep -i crypt ). Not all sections are encrypted but usually the first block including _TEXT._text (prog code) and _TEXT._cstring are. The _DATA._cfstring section was not encrypted in my case.
2) as expected __cfstring consists of 16-byte structures (NSConstantString), where the 3rd word is a pointer to memory where _TEXT._cstring is loaded. The 4th word is the length.
So in real life the trick is to decrypt the file first, and then all is visible and accessible. I still didn't get around doing it properly, but dumped a piece of memory in gdb, which then replaced the relevant section in the file.