IOS Application Security Testing Cheat Sheet - Revision history

Dominique RIGHETTO: Migration to GitHub of the project

2019-02-16T09:41:19Z

Migration to GitHub of the project

2018-05-26T07:58:36Z

Add Other Cheatsheets marker for the book

2018-05-10T09:15:46Z

Replace the content by a reference to the MSTG project according to our plan

2016-01-11T18:12:02Z

Corrected options to print the indirect symbol table (-I) rather than printing the load commands (-l).

2015-08-24T14:07:56Z

add note about running otool against binary not ipa

2015-06-30T18:21:23Z

Added memscan to the list of iOS tools

2014-08-03T10:53:28Z

2014-08-03T10:48:52Z

2014-08-03T10:35:31Z

2013-10-07T09:51:30Z

← Older revision		Revision as of 09:41, 16 February 2019
Line 16:		Line 16:

	Consult this [https://github.com/OWASP/owasp-mstg#ios-testing-guide section] for information about iOS platform.		Consult this [https://github.com/OWASP/owasp-mstg#ios-testing-guide section] for information about iOS platform.
−
−	~~= Other Cheatsheets =~~
−
−	~~{{Cheatsheet_Navigation_Body}}~~
−
−	\|}
−
−	~~[[Category:Cheatsheets]]~~

← Older revision		Revision as of 07:58, 26 May 2018
Line 16:		Line 16:

	Consult this [https://github.com/OWASP/owasp-mstg#ios-testing-guide section] for information about iOS platform.		Consult this [https://github.com/OWASP/owasp-mstg#ios-testing-guide section] for information about iOS platform.
		+
		+	= Other Cheatsheets =

	{{Cheatsheet_Navigation_Body}}		{{Cheatsheet_Navigation_Body}}

@@ Line 29: / Line 29: @@
 <ul>
 <li>Locate the PIE (Position Independent Executable) - an app compiled without PIE (using the “–fPIE –pie” flag) will load the executable at a fixed address. Check this using the command: otool –hv <app name> (otool should be run against the app *binary* after unzipping the ipa, it should not be run directly against the ipa)</li>
-<li>Stack smashing protection - specify the –fstack-protector-all compiler flag. A “canary” is placed on the stack to protect the saved base pointer, saved instruction pointer and function arguments. It will be verified upon the function return to see if it has been overwritten. Check this using: otool –I –v <app name> | grep stack . If the application was compiled with the stack smashing protection two undefined symbols will be present: “___stack_chk_fail” and “___stack_chk_guard”.</li>
+<li>Stack smashing protection - specify the –fstack-protector-all compiler flag. A “canary” is placed on the stack to protect the saved base pointer, saved instruction pointer and function arguments. It will be verified upon the function return to see if it has been overwritten. Check this using: otool -Iv <app name> | grep stack . If the application was compiled with the stack smashing protection two undefined symbols will be present: “___stack_chk_fail” and “___stack_chk_guard”.</li>
 </ul>

@@ Line 28: / Line 28: @@
 Determine the security features in place:
 <ul>
-<li>Locate the PIE (Position Independent Executable) - an app compiled without PIE (using the “–fPIE –pie” flag) will load the executable at a fixed address. Check this using the command: otool –hv <app name></li>
+<li>Locate the PIE (Position Independent Executable) - an app compiled without PIE (using the “–fPIE –pie” flag) will load the executable at a fixed address. Check this using the command: otool –hv <app name> (otool should be run against the app *binary* after unzipping the ipa, it should not be run directly against the ipa)</li>
 <li>Stack smashing protection - specify the –fstack-protector-all compiler flag. A “canary” is placed on the stack to protect the saved base pointer, saved instruction pointer and function arguments. It will be verified upon the function return to see if it has been overwritten. Check this using: otool –I –v <app name> | grep stack . If the application was compiled with the stack smashing protection two undefined symbols will be present: “___stack_chk_fail” and “___stack_chk_guard”.</li>
 </ul>

@@ Line 249: / Line 249: @@
 <td>https://github.com/iSECPartners/Introspy-iOS</td>
 <td>A security profiling tool revolved around hooking security based iOS APIs and logging their output for security analysis</td>
 </tr>
 </table>

@@ Line 244: / Line 244: @@
 <td>http://damnvulnerableiosapp.com/</td>
 <td>A purposefully vulnerable iOS application for learning iOS application assessment skills.</td>
 </tr>
 </table>

@@ Line 239: / Line 239: @@
 <td>https://github.com/dmayer/idb</td>
 <td>A GUI (and cmdline) tool to simplify some common tasks for iOS pentesting and research.</td>
 </tr>
 </table>

@@ Line 233: / Line 233: @@
 <td>snoop-it</td>
 <td>https://code.google.com/p/snoop-it/</td>
-<td>A tool to assist security assessments and dynamic analysis of iOS Apps</td>
+<td>A tool to assist security assessments and dynamic analysis of iOS Apps, includes runtime views of obj-c classes and methods, and options to modify those values</td>
 </tr>
 </table>

@@ Line 18: / Line 18: @@
 <li>Identify what protocols are in use</li>
 <li>Identify other applications or services with which the application interacts</li>
-<li>Decrypt Appstore binaries: the .ipa will be decrypted at runtime by the kernel’s mach loader. Cydia has two applications available: Crackulous, AppCrack and Clutch. Also, you can use GDB. The “cryptid” field of the LC_ENCRYPTION_INFO identifies if the application is encrypted or not. Use otool –l <app name> | grep –A 4 LC_ENCRYPTION_INFO</li>
+<li>Decrypt Appstore binaries: the .ipa will be decrypted at runtime by the kernel’s mach loader. Cydia has several applications available: Crackulous, AppCrack and Clutch. Also, you can use GDB. The “cryptid” field of the LC_ENCRYPTION_INFO identifies if the application is encrypted or not. Use otool –l <app name> | grep –A 4 LC_ENCRYPTION_INFO</li>
 <li>Determine the architecture the application was compiled for: otool –f <app name> or lipo -info <app>.</li>
 <li>Get information about what functions, classes and methods are referenced in the application and in the dynamically loaded libraries. Use nm <app name></li>