0
1
00:00:08,490 --> 00:00:13,740
So now we're going to use objection for dynamic analysis before we go into this.
1

2
00:00:13,740 --> 00:00:17,660
There's one thing we need to mention. Earlier on,
2

3
00:00:17,690 --> 00:00:20,870
we saw how to extract an APK from our phone.
3

4
00:00:21,140 --> 00:00:25,790
But the APK we were working with was actually a development app.
4

5
00:00:25,790 --> 00:00:32,840
This means that the app was not signed on the other hand when you download an APK from an app store
5

6
00:00:33,500 --> 00:00:39,320
you'll find that the developer signed the app when the app is not signed,
6

7
00:00:39,320 --> 00:00:46,480
you may encounter a few problems particularly with dynamic analysis so let's go through the signing
7

8
00:00:46,480 --> 00:00:56,100
process. What you're going to do is go to Android Studio and you're going to click on build here you're
8

9
00:00:56,100 --> 00:01:03,120
going to have an option to say generate signed bundle slash apk. OK.
9

10
00:01:03,120 --> 00:01:07,260
So click here follow the wizard.
10

11
00:01:07,260 --> 00:01:13,290
You're going to click next if this is your first time signing an app you're probably not going to have
11

12
00:01:13,290 --> 00:01:19,960
a key store. So in that case just create a key store here where you fill in password and you confirm
12

13
00:01:19,960 --> 00:01:28,810
password, give it the name and the password validity by default it is twenty five years. If you want to
13

14
00:01:28,810 --> 00:01:31,690
increase it because of what happened with the millennium bug...
14

15
00:01:31,690 --> 00:01:39,320
Go ahead and increase it, then you can give information about the certificate. Here we'll just use one
15

16
00:01:39,320 --> 00:01:49,010
created earlier, when you click Next make sure version 1 and version 2 are both clicked. Choose debug
16

17
00:01:49,040 --> 00:01:52,580
or release depending on whether you're going to release or not.
17

18
00:01:53,570 --> 00:02:02,780
OK let's do release, choose the path and just like this you'll be able to see... let's open the file where
18

19
00:02:02,780 --> 00:02:10,970
this is located. Go to the path you specified when signing.
19

20
00:02:11,200 --> 00:02:21,580
In our case it's this and here you have the signed apk. So the APK release is your signed version of
20

21
00:02:21,580 --> 00:02:25,210
the application we were working with.
21

22
00:02:25,270 --> 00:02:31,570
Now this should work with our online sandboxes or dynamic analysis tools.
22

23
00:02:31,650 --> 00:02:33,630
That's your signed apk
23

24
00:02:33,870 --> 00:02:37,630
We sign it because we're going to install it to the emulator.
24

25
00:02:37,680 --> 00:02:43,320
So what we're going to do is start the emulator and in this case we actually use an emulator which is
25

26
00:02:43,320 --> 00:02:50,970
version 24, this lab machine is a bit slow and sometimes newer emulators tend to have higher requirements.
26

27
00:02:51,810 --> 00:02:52,710
In your environment
27

28
00:02:52,710 --> 00:02:56,010
you can run your preferred version if need be.
28

29
00:02:56,020 --> 00:02:59,420
Just go to the emulator or ADB part of the course.
29

30
00:02:59,440 --> 00:03:05,670
Earlier on in case you need to revise how to set up an emulator. OK.
30

31
00:03:05,670 --> 00:03:12,300
So before we continue let's recall the part of the static analysis, if you remember in download we had
31

32
00:03:12,300 --> 00:03:20,060
the bytecodeviewer depending where you saved your byte code viewer. Let's run that again and have a
32

33
00:03:20,060 --> 00:03:27,550
look at the code through some analysis we can try to identify some points of interest so just find your
33

34
00:03:27,620 --> 00:03:33,800
APK. So it's under release and you just drag it onto the window just like that.
34

35
00:03:34,710 --> 00:03:38,590
So if you remember the app was receiving an S M S and ex-filtrating it.
35

36
00:03:39,030 --> 00:03:42,200
So it was stealing the S M S and sending it to some 
36

37
00:03:42,200 --> 00:03:44,660
URL
37

38
00:03:44,790 --> 00:03:51,850
Now we kind of managed to understand what was happening but maybe we want to confirm even further also
38

39
00:03:51,850 --> 00:03:58,450
in certain cases the statically Decompiled code may not have been so clear and maybe you're unable to
39

40
00:03:58,450 --> 00:04:03,370
see in code what is happening exactly at some specific methods.
40

41
00:04:03,370 --> 00:04:07,000
That's where dynamic analysis is extremely handy.
41

42
00:04:07,010 --> 00:04:08,930
Consider this case here.
42

43
00:04:08,990 --> 00:04:17,550
Remember we had an HTTP post but assume we couldn't trace exactly what was being exfiltrated. Maybe
43

44
00:04:17,570 --> 00:04:23,120
we suspect it's the SMSs but we're not sure. Through dynamic analysis 
44

45
00:04:23,130 --> 00:04:29,620
we can try to understand what is happening over here at particular points within the class during execution.
45

46
00:04:30,990 --> 00:04:33,550
OK so let's have a look at objection now.
46

47
00:04:34,080 --> 00:04:41,770
We're going to go where the signed apk is and we want to run objection patchapk.
47

48
00:04:41,790 --> 00:04:52,380
source and the path to our signed APK. Actually let's move the APK from the Android Studio path to
48

49
00:04:52,380 --> 00:04:57,330
the flipcortex directory we created earlier OK.
49

50
00:04:57,340 --> 00:05:09,070
So we moved the APK so now run objection patch APK source and the path to our assigned apk and we
50

51
00:05:09,070 --> 00:05:11,050
can pass the gadget version.
51

52
00:05:11,170 --> 00:05:14,260
I had some issues with some versions and this one worked.
52

53
00:05:14,260 --> 00:05:18,170
So just to be safe let's use this.
53

54
00:05:18,300 --> 00:05:27,210
Now this is going to instrument the APK meaning it's going to decompile the app, inject code and recompile
54

55
00:05:27,780 --> 00:05:37,040
and sign the app all of this is done automatically while also using another tool called Frida for instrumentation.
55

56
00:05:37,040 --> 00:05:42,480
This will allow us to hook into specific functions of the app dynamically.
56

57
00:05:42,650 --> 00:05:52,270
OK so we give it some time and we can see it is signing the new APK and if we look into our folder now
57

58
00:05:52,630 --> 00:05:59,290
we can see that instrumented version of our APK over here it appended objection to the name.
58

59
00:05:59,910 --> 00:06:00,470
OK.
59

60
00:06:00,550 --> 00:06:03,370
Now we can go ahead and install.
60

61
00:06:03,370 --> 00:06:13,630
If you remember we can use ADB install, so ADB install and the name of the APK to install.
61

62
00:06:13,630 --> 00:06:18,380
Now we can see that we can run the app but nothing will happen.
62

63
00:06:18,430 --> 00:06:22,950
This is because it's waiting for us to run objection against the app.
63

64
00:06:23,110 --> 00:06:24,010
So.
64

65
00:06:24,100 --> 00:06:25,260
Objection.
65

66
00:06:25,450 --> 00:06:26,740
Explore.
66

67
00:06:27,040 --> 00:06:29,390
Then it will run the app.
67

68
00:06:29,420 --> 00:06:33,590
Now we want to hook onto the HTTP post to do this.
68

69
00:06:33,590 --> 00:06:41,720
We're going to run Android hooking watch class method pass the name of the method including the entire
69

70
00:06:41,720 --> 00:06:54,500
package and class before, so com dot flipcortex dot Hello World dot SMSreceiver dot HTTP post, then
70

71
00:06:54,500 --> 00:07:05,140
we're going to dump the arguments using dump dash args dump back trace using dump dash back trace and
71

72
00:07:05,140 --> 00:07:11,020
finally dump the return values using dump dash return.
72

73
00:07:11,020 --> 00:07:11,880
Great.
73

74
00:07:12,310 --> 00:07:15,760
So now we're going to run this by pressing enter.
74

75
00:07:15,760 --> 00:07:23,650
Now what this does is it hooks onto the instance of the HTTP post method and if it sees that this method
75

76
00:07:23,650 --> 00:07:31,050
is invoked then it dumps all the info we specified in the console. So if you remember when we developed
76

77
00:07:31,050 --> 00:07:36,780
the app we were able to do debugging inside Android Studio by adding breakpoints.
77

78
00:07:36,780 --> 00:07:42,400
Here we sort of have a similar behavior where we can hook onto specific points in the code and obtain
78

79
00:07:42,420 --> 00:07:45,240
info about the variables at runtime.
79

80
00:07:45,240 --> 00:07:46,410
So this is quite useful.
80

81
00:07:47,810 --> 00:07:48,300
OK.
81

82
00:07:48,330 --> 00:07:50,700
Let's open the emulator here.
82

83
00:07:50,700 --> 00:07:59,080
Go to send an S M S and let's see what happens when we receive an S M S. So click on phone changed the
83

84
00:07:59,080 --> 00:08:09,810
text write something like Hey receiver then we click on send .. in the console we can see all the dumps.
84

85
00:08:09,850 --> 00:08:17,230
This tells us that HTTP post was invoked as soon as the SM S was received which is what we expected.
85

86
00:08:17,380 --> 00:08:23,440
Now also if we look at the arguments we can confirm that it actually was the S M S that was passed as
86

87
00:08:23,440 --> 00:08:31,370
an argument similarly if we look at the return value we can see the U R L with the HTTP parameters,
87

88
00:08:31,370 --> 00:08:38,500
that are being exfiltrated, so we can see post man dash echo and we can see the contents of our sms.
88

89
00:08:40,460 --> 00:08:46,640
So here we are 100 percent sure that the S M S is being stolen. Through static analysis
89

90
00:08:46,650 --> 00:08:50,420
we got a clear picture but it's not always so black and white.
90

91
00:08:50,490 --> 00:08:57,180
Here we have 100 percent confirmation that as soon as we receive an S M S that S M S is being sent over
91

92
00:08:57,180 --> 00:09:05,250
HTTP post to post-man dash echo so we can go to our network analysts and say yes your assumption was
92

93
00:09:05,250 --> 00:09:06,110
correct.
93

94
00:09:06,210 --> 00:09:12,020
We're seeing data being exfiltrated to this server and the data being sent is SMS's