You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: iGoat-Swift/iGoat-Swift/Resources/Assets.plist
+5-75Lines changed: 5 additions & 75 deletions
Original file line number
Diff line number
Diff line change
@@ -72,76 +72,6 @@
72
72
</dict>
73
73
</array>
74
74
</dict>
75
-
<key>Sample Test</key>
76
-
<dict>
77
-
<key>description</key>
78
-
<string>This exercise category contains exercises related to reverse engineering a mobile app's binary code. On its own, reverse engineering an app leads to a number of valuable things for a hacker. First, it will give the hacker a solid blueprint of the app and reveal a great deal of information about the underlying architecture, design, and implementation. This can lead to things like counterfeiting or stealing of code. As a springboard, the hacker can then exploit this knowledge to conduct other types of attacks. For instance, the hacker may extract infrastructure passwords to conduct infrastructure attacks against backend systems. The hacker may leverage this knowledge to modify the app or its runtime behavior. These exercises show you how to raise the bar and make it much more painful and difficult for the hacker to successfully extract anything useful from the binary.</string>
79
-
<key>exercises</key>
80
-
<array>
81
-
<dict>
82
-
<key>creditsFile</key>
83
-
<string>KRvWAssociates.html</string>
84
-
<key>description</key>
85
-
<string>In this exercise, we are trying to extract a secret piece of information embedded within a string located within the app's binary. Ideally, you should avoid relying upon sensitive strings embedded within your binary. However, that is not always realistic. Offline availability requirements or system architectures typically drive the need for reliance upon embedded strings. In some scenarios, it is not possible to avoid placing sensitive strings within your string table. However, there are things you can do to make it much more difficult to exploit these strings...
86
-
87
-
Your first goal is to perform a string analysis of the compiled binary and answer the riddle posed by this exercise.
88
-
89
-
Your second goal is to alter the mobile app in such a way that static analysis will not easily reveal the answer to the riddle.
90
-
</string>
91
-
<key>hints</key>
92
-
<array>
93
-
<string>To extract useful string information from a binary, a hacker will follow a well-established methodology. First, the hacker will download the app from the iTunes store and decrypt it within a jailbroken environment using a free tool like <i>Clutch</i>.<br/><br/>
94
-
95
-
To see a demo of how to bypass iTunes code encryption, click <a href="http://m.youtube.com/watch?v=nOFXsR4-2AQ">here</a>.<br/><br/>
96
-
97
-
Normally, you must start a string analysis by breaking through iTunes code encryption to look at the underlying string table. However, you are running this app within a development environment. Hence, you cannot download the iTunes version of the app which would include this easily breakable protection. You can safely ignore the first step of bypassing iTunes code encryption through the use of a tool like <i>Clutch</i> on your binary.
98
-
99
-
</string>
100
-
<string>The heart of every iPhone mobile app lies within its core binary file. The file contains ARM instructions that will be executed by iOS. When you download the app from the iTunes store, your phone receives an IPA file. This is an archive that contains an application bundle (APP file) as well as other files meant for iTunes management of your app.<br/><br/>
101
-
102
-
Within the Xcode environment, you can find the APP file within the <i>Products</i> directory of the iGoat project. The particular subdirectory will dependend upon which target you are building against. If you are running the app within an iOS emulator, you can find the APP file within the filepath <i>~/Library/Application\ Support/iPhone\ Simulator</i>.
103
-
</string>
104
-
<string>The application bundle contains the raw binary you will want to analyze. The binary typically has the same name as the project. In this case, the name of the raw binary is the filename <i>iGoat</i>
105
-
</string>
106
-
<string>A hacker will use static analysis tools (<i>IDA Pro</i>; <i>Hopper</i>; <i>strings</i>)to inspect the unencrypted binary's string table. To learn how to perform basic static analysis, click <a href="http://m.youtube.com/watch?v=GvqnJmTb9HU">here</a>.<br/><br/>
107
-
108
-
If you like the idea of using a simple command line tool instead, check out <i>strings</i>.
109
-
</string>
110
-
<string>A hacker will typically pipe the output from the <i>strings</i> command line tool to another tool like <i>grep</i> to search for strings matching a particular pattern.
111
-
</string>
112
-
<string>There are many simple, easy things you can do to your original code to trick casual hackers from identifying sensitive strings contained within your binary string table. You can tweak the algorithm behind the code that retrieves the sensitive string to ensure that the original string is never stored in plaintext and easily accessible to the hacker.<br/><br/>
113
-
114
-
Which type of encryption / encoding algorithms are available to you? What do you need to worry about with each type?
115
-
</string>
116
-
</array>
117
-
<key>initialViewController</key>
118
-
<string>SampleDemoVC</string>
119
-
<key>name</key>
120
-
<string>Sample Demo</string>
121
-
<key>solution</key>
122
-
<string>There are two key goals of this exercise.
123
-
124
-
First, you must answer the riddle posed to you by the application. You might be tempted to just look at the source code and get the answer. However, a hacker will not have the luxury of doing so as they will not have access to the original source code. They will only have access to what they can download off the iTunes store. The answer is embedded within the app's binary string table.
125
-
126
-
To get the answer, a hacker must perform binary string analysis and inspect its string table. The string table contains any hardcoded strings used by the code throughout its execution. Hardcoded strings reveal all sorts of useful tidbits of information. A hacker can use a string table to cross-reference and locate sensitive algorithms within the binary. There are many studies of apps in the wild that show the prevalence of hardcoded usernames and passwords to backend systesm.
127
-
128
-
Use the command-line tool <i>strings</i> against the core binary file iGoat and pipe the output to <i>grep</i> to search for the answer to the riddle.
129
-
130
-
<i>strings iGoat | grep riddle</i>
131
-
132
-
The second goal is to make the app immune to this type of binary attack. To achieve this goal, there are a number of different techniques available. You could store an encrypted version of the string within the string table and decrypt it at runtime. After decryption, perform the string comparison to determine if the answer is correct. In taking this approach, static analysis will no longer yield a useful result. The attacker will be forced to move into the more expensive proposition of performing dynamic analysis to deduce the answer to the riddle. There are a whole other set of deterrents related to preventing or frustrating dynamic analsyis.
133
-
134
-
You could also transform the representation of the string into something else (like an array of bytes) that would take it completely outside of the string table. You would be surprised how often this simple transformation will deter a hacker from going further...
135
-
136
-
<H1>External References</H1>
137
-
<OL>
138
-
<LI>OWASP Technical Risks of Reverse Engineering and Unauthorized Code Modification - <i><a href="https://www.owasp.org/index.php/Technical_Risks_of_Reverse_Engineering_and_Unauthorized_Code_Modification#Exposed_String_Tables">Exposed String Tables</a></i></LI>
139
-
<LI>OWASP Mobile Top Ten 2014 - <i><a href="https://www.owasp.org/index.php/Mobile_Top_10_2014-M10">M10</a></i></LI>
140
-
</OL>
141
-
</string>
142
-
</dict>
143
-
</array>
144
-
</dict>
145
75
<key>Tampering</key>
146
76
<dict>
147
77
<key>description</key>
@@ -254,7 +184,7 @@
254
184
<string>If you received a message telling you that your credentials were compromised, you've finished the first part.</string>
0 commit comments