1
00:00:07,020 --> 00:00:10,440
- Our primary areas of focus for digging

2
00:00:10,440 --> 00:00:13,620
into Android applications are listed here

3
00:00:13,620 --> 00:00:17,630
data storage, logging, network,
and platform communications

4
00:00:17,630 --> 00:00:20,570
build settings, and finally
reverse engineering.

5
00:00:20,570 --> 00:00:22,350
So let's run through some of these.

6
00:00:22,350 --> 00:00:24,660
For data storage on Android.

7
00:00:24,660 --> 00:00:28,530
We have a few persistent data stores.

8
00:00:28,530 --> 00:00:31,600
We have shared preferences,
SQLite databases

9
00:00:31,600 --> 00:00:34,420
and fire base, realtime databases.

10
00:00:34,420 --> 00:00:35,910
So for shared preferences,

11
00:00:35,910 --> 00:00:40,910
shared preferences are a,
it's on disk, an XML file.

12
00:00:41,750 --> 00:00:45,410
And there are methods
exposed in the Android SDK

13
00:00:45,410 --> 00:00:47,970
to write two shared
preferences very easily

14
00:00:47,970 --> 00:00:50,853
I have an example of this
on the coming slides.

15
00:00:51,720 --> 00:00:55,640
We talked about SQLite and
fire base in the iOS section

16
00:00:55,640 --> 00:00:58,480
the storage location
for the SQLite databases

17
00:00:58,480 --> 00:01:01,680
on Android is slightly
different, of course

18
00:01:01,680 --> 00:01:03,550
completely different operating system.

19
00:01:03,550 --> 00:01:05,650
But in slash data slash data

20
00:01:05,650 --> 00:01:09,210
the package name slash
databases within there

21
00:01:09,210 --> 00:01:12,260
you would have a SQLite file
that you could then, provided,

22
00:01:12,260 --> 00:01:14,740
You can get to that data,
you can actually, you know

23
00:01:14,740 --> 00:01:17,690
load it up into SQLite and see the data.

24
00:01:17,690 --> 00:01:19,550
We also have internal storage,

25
00:01:19,550 --> 00:01:22,774
so applications just
like iOS, are sand-boxed,

26
00:01:22,774 --> 00:01:27,774
containerized, segmented
data store and inaccessible

27
00:01:27,870 --> 00:01:29,670
to a general user.

28
00:01:29,670 --> 00:01:31,130
In one of the coming screenshots,

29
00:01:31,130 --> 00:01:34,500
we'll see that I get root
in order to access data.

30
00:01:34,500 --> 00:01:36,720
And that applies here.
Your standard off the shelf

31
00:01:36,720 --> 00:01:39,480
cell phone, running Android, non-rooted,

32
00:01:39,480 --> 00:01:41,490
you wouldn't be able to access this.

33
00:01:41,490 --> 00:01:43,080
You root the device, then you get access

34
00:01:43,080 --> 00:01:46,540
to the full disc and you can
access whatever data you want.

35
00:01:46,540 --> 00:01:48,600
And then finally, external storage.

36
00:01:48,600 --> 00:01:52,740
So Android, all Android
devices have a concept

37
00:01:52,740 --> 00:01:54,910
of external storage,
whether or not it exists

38
00:01:54,910 --> 00:01:57,560
or not is up to the actual
manufacturer of the product.

39
00:01:57,560 --> 00:02:00,710
However, the capability is there.

40
00:02:00,710 --> 00:02:01,950
This might be removable.

41
00:02:01,950 --> 00:02:03,420
It might be non-removable.

42
00:02:03,420 --> 00:02:06,120
So if you have an SD
card that you can extract

43
00:02:06,120 --> 00:02:09,560
from your phone, that's
removable, external storage.

44
00:02:09,560 --> 00:02:12,190
That data store is world readable

45
00:02:13,420 --> 00:02:16,710
and USB accessible, and
plug it into a computer,

46
00:02:16,710 --> 00:02:18,930
you can browse the data on that disc.

47
00:02:18,930 --> 00:02:22,610
So if an application developer
decides to write their data,

48
00:02:22,610 --> 00:02:24,920
maybe on purpose, maybe by accident,

49
00:02:24,920 --> 00:02:27,615
to this external storage
location, and then it falls

50
00:02:27,615 --> 00:02:32,615
into an SD card, again, on
purpose or not, what sort

51
00:02:32,730 --> 00:02:34,780
of information can you extract from that?

52
00:02:36,540 --> 00:02:39,940
So an example of shared
preferences exposure.

53
00:02:39,940 --> 00:02:43,160
So I put together this
very simple application.

54
00:02:43,160 --> 00:02:45,650
This is not even really
an application it's

55
00:02:45,650 --> 00:02:48,810
got two text fields and
some code in order to

56
00:02:48,810 --> 00:02:50,170
store shared preferences.

57
00:02:50,170 --> 00:02:52,940
So we create a shared preferences object.

58
00:02:52,940 --> 00:02:54,410
We create an editor for that.

59
00:02:54,410 --> 00:02:56,690
We put two strings into that

60
00:02:56,690 --> 00:02:59,360
and we see right here,
save username and password

61
00:02:59,360 --> 00:03:01,023
is the function name.

62
00:03:02,710 --> 00:03:05,159
Whenever the user taps, the login button

63
00:03:05,159 --> 00:03:08,610
this function gets executed
and it stores the username

64
00:03:08,610 --> 00:03:11,060
and password to those shared preferences.

65
00:03:11,060 --> 00:03:13,960
So that example I was talking
about on the previous slide,

66
00:03:13,960 --> 00:03:17,430
of being root to get access to this data.

67
00:03:17,430 --> 00:03:20,170
If I root my phone, then I can get a shell

68
00:03:20,170 --> 00:03:22,950
and actually navigate to the applications

69
00:03:22,950 --> 00:03:26,670
containerized directory and extract data.

70
00:03:26,670 --> 00:03:28,930
So shared preferences, as
I mentioned, are stored

71
00:03:28,930 --> 00:03:32,530
in an XML file, shared press
dot XML, saved password

72
00:03:32,530 --> 00:03:37,190
super secret password saved
username john@doe.com.

73
00:03:37,190 --> 00:03:40,760
So once I type that information
in here, press login.

74
00:03:40,760 --> 00:03:45,053
This function executes and
stores it to shared preferences.

75
00:03:46,310 --> 00:03:49,440
Shared preferences are commonly
used to store information

76
00:03:49,440 --> 00:03:50,523
for an application.

77
00:03:51,520 --> 00:03:53,973
And as you can see very easy to implement.

78
00:03:56,200 --> 00:03:58,460
ADB, Android debug bridge.

79
00:03:58,460 --> 00:04:00,610
This is an application you
can install on your computer.

80
00:04:00,610 --> 00:04:02,503
It's available for Mac, Linux, Windows,

81
00:04:02,503 --> 00:04:05,950
and it includes the log cat feature.

82
00:04:05,950 --> 00:04:09,640
So Android is constantly
logging under the covers.

83
00:04:09,640 --> 00:04:12,070
Your phone is always
logging stuff to itself.

84
00:04:12,070 --> 00:04:14,100
You can get access to these logs.

85
00:04:14,100 --> 00:04:15,310
If you turn on developer mode

86
00:04:15,310 --> 00:04:19,330
on the phone and then turn
on USB debugging or TCP

87
00:04:19,330 --> 00:04:21,340
you can do this over the network as well.

88
00:04:21,340 --> 00:04:25,510
Then you can do ADB log cat
and get a bunch of information.

89
00:04:25,510 --> 00:04:29,750
If the developer forgets to
turn off the de-bugable flag

90
00:04:29,750 --> 00:04:32,010
then it's possible to expose information

91
00:04:32,010 --> 00:04:34,760
in these log messages. I
have an example of that here.

92
00:04:34,760 --> 00:04:36,570
Same application, I went ahead and added

93
00:04:36,570 --> 00:04:38,810
a bank login header here.

94
00:04:38,810 --> 00:04:39,950
So I have username and password.

95
00:04:39,950 --> 00:04:42,690
You press the login
button and what occurs?

96
00:04:42,690 --> 00:04:45,900
So we have a debug
message here. Log dot D.

97
00:04:45,900 --> 00:04:49,940
So it is integrating the login
library into the application.

98
00:04:49,940 --> 00:04:52,990
It's built into the Android SDK

99
00:04:52,990 --> 00:04:55,193
for logging it's to help developers.

100
00:04:56,630 --> 00:04:58,930
Once you hit the package button,

101
00:04:58,930 --> 00:05:01,290
so I mentioned this de-bugable flag.

102
00:05:01,290 --> 00:05:04,300
So whenever you are
debugging an application

103
00:05:04,300 --> 00:05:06,180
then de-bugable is set to true.

104
00:05:06,180 --> 00:05:08,380
Whenever you package it for release,

105
00:05:08,380 --> 00:05:10,190
then if you're using Android studio

106
00:05:10,190 --> 00:05:11,683
it'll turn that off for you,

107
00:05:13,080 --> 00:05:15,770
as part of the release process.

108
00:05:15,770 --> 00:05:18,520
if for whatever reason, the
developer decided to mess

109
00:05:18,520 --> 00:05:22,360
with that, or they change
from debug to info.

110
00:05:22,360 --> 00:05:25,603
So you'll notice log
dot I versus log dot D.

111
00:05:26,880 --> 00:05:29,580
Then we could expose information here.

112
00:05:29,580 --> 00:05:33,930
So we have on create and
we get the some handles

113
00:05:33,930 --> 00:05:37,370
to these two text fields over
here, you press go log in,

114
00:05:37,370 --> 00:05:41,110
it executes this function right here.

115
00:05:41,110 --> 00:05:46,110
And we see we create two
strings and we log it, log dot I

116
00:05:46,300 --> 00:05:49,310
so this is an informational
log message that

117
00:05:49,310 --> 00:05:52,070
is output in log cat output.

118
00:05:52,070 --> 00:05:54,940
So we see here, go log
in username and password

119
00:05:54,940 --> 00:05:56,960
which is what I told it to output,

120
00:05:56,960 --> 00:05:58,423
username and password.

121
00:06:00,000 --> 00:06:03,410
So if you are investigating
an Android application

122
00:06:03,410 --> 00:06:06,080
turn on developer mode,
turn on USB debugging

123
00:06:06,080 --> 00:06:07,920
and just start watching log messages.

124
00:06:07,920 --> 00:06:10,200
And it's a command line application.

125
00:06:10,200 --> 00:06:14,160
So you pipe that to grip or
whatever the case may be, and

126
00:06:14,160 --> 00:06:17,220
look for unique strings
that this application

127
00:06:17,220 --> 00:06:19,690
may be accidentally logging.

128
00:06:19,690 --> 00:06:21,920
When it comes to network communications

129
00:06:21,920 --> 00:06:25,400
the same concepts we have
looked at in previous lessons

130
00:06:25,400 --> 00:06:27,700
as well as the iOS lesson apply.

131
00:06:27,700 --> 00:06:30,670
So capturing traffic, sniffing traffic

132
00:06:30,670 --> 00:06:34,290
and even proxying traffic.
So we have burp suite as well

133
00:06:34,290 --> 00:06:39,290
as the Zed Attack Proxy from
OWASP to proxy HTTP traffic

134
00:06:39,460 --> 00:06:41,260
as it's coming out of the device

135
00:06:41,260 --> 00:06:44,990
and then better cap or etter
cap to actually do machine

136
00:06:44,990 --> 00:06:48,030
in the middle type capture of data.

137
00:06:48,030 --> 00:06:50,680
Similar to iOS, Android has permissions.

138
00:06:50,680 --> 00:06:54,180
These permissions will
allow an application to

139
00:06:54,180 --> 00:06:56,140
access platform capabilities.

140
00:06:56,140 --> 00:06:59,720
We can see here in this
screenshot access fine location,

141
00:06:59,720 --> 00:07:03,590
access course location,
get accounts, record audio.

142
00:07:03,590 --> 00:07:06,890
Why does this application
need to record audio?

143
00:07:06,890 --> 00:07:08,010
That's a good question.

144
00:07:08,010 --> 00:07:10,280
These requested permissions would then

145
00:07:10,280 --> 00:07:11,370
be presented to the user.

146
00:07:11,370 --> 00:07:14,280
Do you want to allow this
application to record audio?

147
00:07:14,280 --> 00:07:16,030
Hopefully the user's gonna say no.

148
00:07:16,030 --> 00:07:18,783
However, there's a good
chance, they're gonna say yes.

149
00:07:19,750 --> 00:07:22,430
Regardless, understanding
what permissions are requested

150
00:07:22,430 --> 00:07:24,230
by an application is helpful.

151
00:07:24,230 --> 00:07:26,840
These are called runtime
permissions, as well,

152
00:07:26,840 --> 00:07:28,450
they are called dangerous permissions

153
00:07:28,450 --> 00:07:30,420
and that's quote on quote dangerous.

154
00:07:30,420 --> 00:07:32,430
So in the documentation they're classified

155
00:07:32,430 --> 00:07:35,250
as dangerous meaning they
could expose some data

156
00:07:35,250 --> 00:07:38,483
provided the user says yes
this permission is approved.

157
00:07:40,070 --> 00:07:43,200
Build settings. So I
mentioned the de-bugable

158
00:07:43,200 --> 00:07:47,000
in a previous slide here, so
within the manifest dot XML

159
00:07:47,000 --> 00:07:49,250
is Android de-bugable, true or false?

160
00:07:49,250 --> 00:07:51,910
The build settings for either debug

161
00:07:51,910 --> 00:07:54,952
or release should toggle
this from true to false,

162
00:07:54,952 --> 00:07:56,822
when you go to release it.

163
00:07:56,822 --> 00:08:01,120
You can see the contents
of manifest dot XML

164
00:08:01,120 --> 00:08:06,120
using some applications such
as jadx and drozer, or jadx,

165
00:08:07,690 --> 00:08:09,110
also AP case signatures.

166
00:08:09,110 --> 00:08:12,340
So in your build settings,
whenever you are packaging it up

167
00:08:12,340 --> 00:08:16,359
for distribution on the
Android play platform

168
00:08:16,359 --> 00:08:18,300
there's several different
options available

169
00:08:18,300 --> 00:08:22,030
for signing those particular
application bundles.

170
00:08:22,030 --> 00:08:25,340
So in version one, when they
first release this stuff

171
00:08:25,340 --> 00:08:27,750
they were doing Java
archive signing, and now

172
00:08:27,750 --> 00:08:30,090
they have APK signatures
for two and three.

173
00:08:30,090 --> 00:08:33,690
Based on the level of
API, you are targeting

174
00:08:33,690 --> 00:08:35,650
with your application.

175
00:08:35,650 --> 00:08:38,523
I'm saying you as if
you are the developer.

176
00:08:39,910 --> 00:08:43,860
For reverse engineering
of Android applications

177
00:08:43,860 --> 00:08:48,680
there is a Dex to Java
decompiler called jadx

178
00:08:48,680 --> 00:08:51,160
or jadx. Bite code viewer can be used

179
00:08:51,160 --> 00:08:53,070
as well to decompile these.

180
00:08:53,070 --> 00:08:57,220
I have a screenshot to
show you how jadx or jadx

181
00:08:57,220 --> 00:08:58,860
works here in just a moment.

182
00:08:58,860 --> 00:09:03,231
Also, if you have access to the
actual distributable package

183
00:09:03,231 --> 00:09:07,040
Android studio, which is the default IDE

184
00:09:07,040 --> 00:09:10,660
for Android, can actually
decompile it for you

185
00:09:10,660 --> 00:09:14,970
into what is called Smali.
Smali as is mentioned here

186
00:09:14,970 --> 00:09:18,030
a similar and disassembler
for Dex bite code

187
00:09:18,030 --> 00:09:20,220
which is used by dalvik which was the

188
00:09:20,220 --> 00:09:23,230
previous version of the virtual machine,

189
00:09:23,230 --> 00:09:24,923
and now the Android runtime.

190
00:09:26,490 --> 00:09:30,290
So here's an example of jadx compilation.

191
00:09:30,290 --> 00:09:34,330
So this is that example
application I was showing

192
00:09:34,330 --> 00:09:37,020
in the previous slides.
This is the original source.

193
00:09:37,020 --> 00:09:39,280
And then this is the decompiled source.

194
00:09:39,280 --> 00:09:41,600
And you'll notice that it is the same

195
00:09:42,530 --> 00:09:45,210
from original to decompiled source.

196
00:09:45,210 --> 00:09:47,930
So provided I can get
access to that binary,

197
00:09:47,930 --> 00:09:51,010
I can extract quite a bit of useful data.

198
00:09:51,010 --> 00:09:54,790
The input to this
decompilation was the actual

199
00:09:54,790 --> 00:09:57,770
signed Android package
that would be uploaded

200
00:09:57,770 --> 00:09:59,933
to the Android play store.

201
00:10:02,030 --> 00:10:05,020
Some other tools available to you for

202
00:10:05,020 --> 00:10:10,020
decompiling Android
applications, dex2jar, APKtool,

203
00:10:10,170 --> 00:10:11,720
The developer studio, as I mentioned

204
00:10:11,720 --> 00:10:15,370
is the default preferred
integrated development environment

205
00:10:15,370 --> 00:10:17,140
for Android applications.

206
00:10:17,140 --> 00:10:20,040
IDA Pro can deal with this stuff as well.

207
00:10:20,040 --> 00:10:23,670
There is a list of tools
available from OWASP

208
00:10:23,670 --> 00:10:28,670
for interacting with both
iOS and Android applications.