iOS 应用程序黑客攻击与安全防护

需积分: 0 134 浏览量更新于2024-07-17 1 收藏 9.95MB PDF 举报

iOS 应用程序黑客攻击和安全 iOS 应用程序黑客攻击和安全是当今最重要的安全问题之一。随着移动设备的普及，iOS 应用程序的安全变得越来越重要。本书《Hacking and Securing iOS Applications》就是专门介绍 iOS 应用程序黑客攻击和安全的书籍，本书分为两个部分：黑客攻击（Hacking）和安全（Securing）。黑客攻击部分（Part I）： Chapter 1. Everything You Know Is Wrong：本章节介绍了 iOS 应用程序黑客攻击的基本概念和原理，帮助读者了解 iOS 应用程序的安全漏洞。 Chapter 2. The Basics of Compromising iOS：本章节详细介绍了 iOS 应用程序黑客攻击的基本方法和技术，包括如何绕过 iOS 的安全机制。 Chapter 3. Stealing the Filesystem：本章节介绍了如何黑客攻击 iOS 文件系统，获取敏感信息。 Chapter 4. Forensic Trace and Data Leakage：本章节讨论了 iOS 应用程序的数字取证和数据泄露问题。 Chapter 5. Defeating Encryption：本章节介绍了如何破解 iOS 应用程序的加密机制。 Chapter 6. Unobliterating Files：本章节讨论了如何恢复删除的文件和数据。 Chapter 7. Manipulating the Runtime：本章节介绍了如何操纵 iOS 应用程序的运行时环境。 Chapter 8. Abusing the Runtime Library：本章节讨论了如何滥用 iOS 应用程序的运行时库。 Chapter 9. Hijacking Traffic：本章节介绍了如何劫持 iOS 应用程序的网络流量。安全部分（Part II）： Chapter 10. Implementing Encryption：本章节介绍了如何在 iOS 应用程序中实现加密机制。 Chapter 11. Counter Forensics：本章节讨论了如何对抗 iOS 应用程序的数字取证。 Chapter 12. Securing the Runtime：本章节介绍了如何保护 iOS 应用程序的运行时环境。 Chapter 13. Jailbreak Detection：本章节讨论了如何检测 iOS 应用程序的越狱状态。 Chapter 14. Next Steps：本章节总结了 iOS 应用程序黑客攻击和安全的重要性，并提供了未来发展的方向。《Hacking and Securing iOS Applications》是 iOS 应用程序黑客攻击和安全的权威指南，涵盖了 iOS 应用程序黑客攻击和安全的方方面面，为读者提供了深入的知识和实践经验。

Using Code Examples

This book is here to help you get your job done. In general, you may use the code in

this book in your programs and documentation. You do not need to contact us for

permission unless you’re reproducing a significant portion of the code. For example,

writing a program that uses several chunks of code from this book does not require

permission. Selling or distributing a CD-ROM of examples from O’Reilly books does

require permission. Answering a question by citing this book and quoting example

code does not require permission. Incorporating a significant amount of example code

from this book into your product’s documentation does require permission.

We appreciate, but do not require, attribution. An attribution usually includes the title,

author, publisher, and ISBN. For example: “Hacking and Securing iOS Applications by

If you feel your use of code examples falls outside fair use or the permission given above,

feel free to contact us at permissions@oreilly.com.

Legal Disclaimer

The technologies discussed in this publication, the limitations on these technologies

that the technology and content owners seek to impose, and the laws actually limiting

the use of these technologies are constantly changing. Thus, some of the hacks de-

scribed in this publication may not work, may cause unintended harm to equipment

or systems on which they are used, or may be inconsistent with applicable law or user

agreements. Your use of these projects is at your own risk, and O’Reilly Media, Inc.

disclaims responsibility for any damage or expense resulting from their use. In any

event, you should take care that your use of these projects does not violate any appli-

cable laws, including copyright laws.

Safari® Books Online

Safari Books Online is an on-demand digital library that lets you easily

search over 7,500 technology and creative reference books and videos to

find the answers you need quickly.

With a subscription, you can read any page and watch any video from our library online.

Read books on your cell phone and mobile devices. Access new titles before they are

available for print, and get exclusive access to manuscripts in development and post

feedback for the authors. Copy and paste code samples, organize your favorites, down-

load chapters, bookmark key sections, create notes, print out pages, and benefit from

tons of other time-saving features.

xiv | Preface

CHAPTER 1

Everything You Know Is Wrong

Secure coding is about increasing the complexity demanded for an attack against the

application to succeed. No application can ever be truly secure. With the right resources

and time, any application, including those utilizing strong encryption, can be broken.

The determination of how secure an application is depends on the trade-off between

the time and complexity of an attack versus the value of the resource when it is

breached. For example, a list of stolen credit card numbers is very useful to an attacker

—if that list is only 10 minutes old. After 24 hours, the value of this data becomes

increasingly diminished, and after a week it is virtually worthless. Securing an appli-

cation is about increasing the complexity needed to attack it, so that the resource—

when breached—will have a significantly diminished value to the attacker. Increasing

the complexity needed for an attack also reduces the pool size of potential attackers.

That is, attacks requiring higher skillsets reduce the number of people capable of at-

tacking your application.

The term mobile security, as used in the marketplace today, has fallen out of sync with

this premise. For many, security has become less about attack complexity and more

about reducing overhead by depending on a monoculture to provide secure interfaces.

As it pertains to iOS, this monoculture consists of a common set of code classes from

the manufacturer to provide password encryption routines, user interface security, file

system encryption, and so on. In spite of the many great advancements in security that

Apple has made, the overall dependence on the operating system has unfortunately had

the opposite effect on the security of applications: it has made them less complex, and

given the keys out for every single application when the monoculture is breached.

We use words like “encryption” as if they are inherently secure solutions to the decades-

old problem of data theft, yet countless millions of seemingly encrypted credit card

numbers, social security numbers, and other personal records have been stolen over

the years. Application developers are taught to write secure applications, but never told

that they can’t even trust their own runtime. Bolting on SSL has become the norm, even

though a number of attacks against SSL have been successfully used to rip off credentials

and later to empty bank accounts. Everything we are taught about security is wrong,

because the implementation is usually wrong. Even well thought out implementations,

such as Apple’s, have suffered from chinks in their armor, making them vulnerable to

many kinds of attacks. A lot of good ideas have been put in place to protect applications

on iOS devices, but at each stage are weakened by critical vulnerabilities. Because most

software manufacturers operate within this monoculture, they are at risk of a breach

whenever Apple is—and that is often.

Implementation is hard to get right. This is why data is stolen on millions of credit card

numbers at a time. The amount of time and effort it takes to invest in a proper imple-

mentation can increase costs and add maintenance overhead. To compensate for this,

many developers look to the manufacturer’s implementation to handle the security,

while they focus on the product itself. Managing data loss, however, is a budget based

on disaster recovery—an even higher cost than the maintenance of implementing your

own application-level security, and often more costly. Typically, the manufacturer isn’t

held liable in the event of security breaches either, meaning your company will have to

absorb the enormous cost of code fixes, mitigation of media and PR fallout, and lawsuits

by your users. Isn’t it much cheaper then, in the long run, to write more secure code?

As is the case with most monocultures, security ones fail, and fail hard. Numerous

security weaknesses on iOS-based devices have emerged over the past few years, leaving

the App Store’s some half million applications exposed to a number of security vul-

nerabilities inherited by the reuse of the manufacturer’s code. This isn’t a new problem

either, mind you. Ever since the introduction of enterprise-grade encryption and other

security features into iOS, both criminal and security enterprises have found numerous

flaws used to protect private data, putting the data on millions of devices at risk.

Unfortunately, the copyright engine in the United States has made it difficult to expose

many of these security flaws. Apple took an aggressive legal stance against opening up

the device’s otherwise private APIs and attempted to squash much of the ongoing

community research into the device, claiming that methods such as jailbreaking were

illegal, a violation of copyright. The Electronic Frontier Foundation (EFF) helped to

win new legal protections, which have helped security researchers divulge much of what

they knew about iOS without having to hide under a rock to do it. In the wake of this

battle over copyright, the forced secrecy has led to the weakening of security, and many

myths and misconceptions about iOS.

As is the case with any monoculture, having millions of instances of an application

relying on the same central security framework makes the framework a considerably

lucrative target: hack the security, and you hack every application using it.

The Myth of a Monoculture

Since the release of the original iPhone in 2007, Apple has engaged in a cat-and-mouse

game with hackers to secure their suite of devices for what has grown to nearly 100

million end users. Over this time, many improvements have been made to the security

of the device, and the stakes have been raised by their introduction into circles with far

2 | Chapter 1: Everything You Know Is Wrong

剩余355页未读，继续阅读

Apple_JD

粉丝: 4
资源: 2

iOS 应用程序黑客攻击与安全防护

iOS应用安全：渗透与防护策略揭秘

基于 Hacking with Swift 的iOS图像查看器开发教程

开源项目Hacking and Development带你了解Linux在PalmOS设备上的开发

Hacking and Securing Ios Applications

Hacking and Securing iOS Applications 无水印pdf

Hacking and Securing iOS Applications.pdf

iOS逆向系列：Hacking and Securing iOS Applications

Hacking.and.Securing.iOS.Applications

【Hacking.and.Securing.iOS.Applications】[PDF+源代码] [iPhone/iPad/iOS]

iOS安全破解：从iOS8到iOS9的演变

最新资源