codesigncommand to display the signing information:
TargetApp(the iOS main app executable) to show the typical output of a binary containing debug symbols which are marked with the
d(debug) flag. Check the objdump man page for information about various other symbol flag characters.
Strip Debug Symbols During Copyto
YESvia the XCode project's build settings. Stripping debugging symbols will not only reduce the size of the binary but also increase the difficulty of reverse engineering.
debugPrint) about responses from their APIs and about their application's progress and/or state. Furthermore, there may be debugging code for "management-functionality", which is used by developers to set the application's state or mock responses from an API. Reverse engineers can easily use this information to track what's happening with the application. Therefore, debugging code should be removed from the application's release version.
OHHTTPStubsused for testing.
AFNetworkingversion 2.5.1, which contained a bug that disabled certificate validation. This vulnerability would allow attackers to execute man-in-the-middle attacks against apps that are using the library to connect to their APIs.
- 1.If the developer packs all dependencies in terms of its own support library using a .podspec file, then this .podspec file can be checked with the experimental CocoaPods podspec checker.
- 2.If the project uses CocoaPods in combination with Objective-C, SourceClear can be used.
- 3.Using CocoaPods with HTTP-based links instead of HTTPS might allow for man-in-the-middle attacks during the download of the dependency, allowing an attacker to replace (parts of) the library with other content. Therefore, always use HTTPS.
Note, at the time of writing this chapter, there is no automated support for Carthage based dependency analysis known to the authors. At least, this feature was already requested for the OWASP DependencyCheck tool but not yet implemented (see the GitHub issue).
/.build/checkouts/folder in the project. Here you can find the license for each of the libraries in their respective folder.
Carthage/Checkoutsfolder in the project. Here you can find the license for each of the libraries in their respective folder.
EULAsection in which the copy-right statements are noted as required by the license of the third party library.
list_bundlescommand lists all of the application’s bundles that are not related to Frameworks. The output contains executable name, bundle id, version of the library and path to the library.
list_frameworkscommand lists all of the application’s bundles that represent Frameworks.
NSExceptionis used to handle programming and low-level errors (e.g., division by 0 and out-of-bounds array access). An
NSExceptioncan either be raised by
raiseor thrown with
@throw. Unless caught, this exception will invoke the unhandled exception handler, with which you can log the statement (logging will halt the program).
@catchallows you to recover from the exception if you're using a
NSErroris used for all other types of errors. Some Cocoa framework APIs provide errors as objects in their failure callback in case something goes wrong; those that don't provide them pass a pointer to an
NSErrorobject by reference. It is a good practice to provide a
BOOLreturn type to the method that takes a pointer to an
NSErrorobject to indicate success or failure. If there's a return type, make sure to return
nilfor errors. If
nilis returned, it allows you to inspect the error/reason for failure.
NSException. The block is used to handle errors that conform to the
Error(Swift 3) or
ErrorType(Swift 2) protocol. This can be challenging when Objective-C and Swift code are combined in an application. Therefore,
NSErroris preferable to
NSExceptionfor programs written in both languages. Furthermore, error-handling is opt-in in Objective-C, but
throwsmust be explicitly handled in Swift. To convert error-throwing, look at the Apple documentation. Methods that can throw errors use the
Resulttype represents a success or failure, see Result, How to use Result in Swift 5 and The power of Result types in Swift. There are four ways to handle errors in Swift:
do-catch; there's only a
throwthrowing the actual error or a
tryto execute the method that throws. The method containing the
tryalso requires the
do-catchstatement. You can use the following pattern:
try!expression to assert that the error won't occur.
@tryblocks is released in the
@throw, the calling method has a proper
@catchat the level of either the calling method or the
UIApplicationobjects to clean up sensitive information and possibly recover,
raiseis rarely used (it's used when the program must be terminated without further warning),
NSErrorobjects don't contain data that might leak sensitive information.
try!is used only with proper guarding up front (to programmatically verify that the method that's called with
try!can't throw an error).
try!in Swift unless you're certain that there's no error in the throwing method that's being called.
freeis called twice for a given region instead of once.
UnsafePointercan be managed wrongly, which will allow for various memory corruption issues.
Unmanagedmanually, leading to wrong counter numbers and a too late/too soon release.
Please note that with Swift 5 you can only deallocate full blocks, which means the playground has changed a bit.
NSDebugEnabledin Xcode while testing the application.
swiftccompiler. However, for Objective-C apps you'll have ensure that it's enabled by following these steps:
PIEis set. This check is applicable to all - Objective-C, Swift and hybrid apps but only to the main executable.
__stack_chk_failindicates that stack canaries are being used. This check is applicable to pure Objective-C and hybrid apps, but not necessarily to pure Swift apps (i.e. it is OK if it's shown as disabled because Swift is memory safe by design).