1
00:00:00,000 --> 00:00:04,360
So, this is the outline.

2
00:00:04,720 --> 00:00:08,060
Number one, we will introduce our malware scouting system.

3
00:00:08,220 --> 00:00:12,280
And number two, we will show you how we designed the Dalvik bytecode loader.

4
00:00:12,300 --> 00:00:17,180
And number three, we will go through two cases of real malware analysis using Quark Engine.

5
00:00:17,380 --> 00:00:21,760
And number four, we will share our strategy of generating the detection rules.

6
00:00:22,080 --> 00:00:24,800
And the last thing, yes, the feature works.

7
00:00:24,800 --> 00:00:27,140
Because we still have a lot of things to do.

8
00:00:27,980 --> 00:00:31,800
Alright, so let's introduce the malware scoring system.

9
00:00:31,980 --> 00:00:38,500
As we know, when developing a malware analysis engine, it is important to have a scoring system.

10
00:00:38,500 --> 00:00:43,580
However, those systems are either business secrets or just too complicated.

11
00:00:43,680 --> 00:00:50,080
Therefore, we decided to create a simple but solid one and take that as a challenge.

12
00:00:50,400 --> 00:00:59,570
And since we wanted to design a novel scoring system, we stopped reading and decoding whatever people do in the field of cybersecurity.

13
00:01:00,000 --> 00:01:04,570
Because we don't want our ideas to be subjected to the existing systems.

14
00:01:05,180 --> 00:01:10,240
So we started to find ideas in fields other than cybersecurity.

15
00:01:10,240 --> 00:01:12,500
And luckily, we found one.

16
00:01:13,000 --> 00:01:17,200
Yes, the best practice we found is the criminal law.

17
00:01:17,720 --> 00:01:23,740
So, when sentenced a penalty for a criminal, the judge weighs the penalties based on the criminal law.

18
00:01:23,740 --> 00:01:27,320
And after decoding the law, we find principles behind it.

19
00:01:27,320 --> 00:01:31,040
And we develop a scoring system for Android malware.

20
00:01:31,960 --> 00:01:35,420
There are only eight principles decoded from the criminal law.

21
00:01:35,420 --> 00:01:38,020
And I'll go through it in the following slides.

22
00:01:38,120 --> 00:01:40,360
Now let's see principle number one.

23
00:01:40,360 --> 00:01:44,700
A malware crime consists of action and targets.

24
00:01:44,920 --> 00:01:50,220
In the criminal law, the definition of a crime consists of action and targets.

25
00:01:50,220 --> 00:01:53,680
For example, steal money and kill people.

26
00:01:53,680 --> 00:02:00,360
So, with this principle in mind, we develop the definition of a crime for Android malware.

27
00:02:00,500 --> 00:02:05,920
And the definition is, the malware crime consists of action and targets.

28
00:02:06,260 --> 00:02:11,540
For example, steal photos or steal your banking account password.

29
00:02:12,620 --> 00:02:15,000
Now let's see principle number two.

30
00:02:15,000 --> 00:02:19,400
We consider that the loss of fame is greater than the loss of wealth.

31
00:02:19,400 --> 00:02:25,640
So, in the criminal law, physical body injury is more serious than psychological injury.

32
00:02:25,700 --> 00:02:32,560
So, the principle we decoded here is, when things are hard to recover, we consider it a felony.

33
00:02:32,900 --> 00:02:37,240
So, with this principle decoded, we develop our second principle.

34
00:02:37,240 --> 00:02:45,120
We consider the loss of fame is greater than the loss of wealth, because it's easier to make money back than rebuild your reputation.

35
00:02:45,820 --> 00:02:49,760
Okay, now let's see principle number three, arithmetic sequence.

36
00:02:50,080 --> 00:02:59,620
In the criminal law, when a murderer is sentenced to 20 years in prison, and a robber is sentenced to 7 years in prison for his crime, why the number?

37
00:02:59,640 --> 00:03:02,120
Why 20 and 7 years?

38
00:03:02,120 --> 00:03:03,180
Why the number?

39
00:03:03,180 --> 00:03:10,180
We found no obvious principles in the criminal law, so we use arithmetic sequence to weigh the penalty of each crime.

40
00:03:10,180 --> 00:03:17,740
For example, the penalty weight of Y1 is 10, and Y2 is 20, and Y3 is 30, etc.

41
00:03:18,800 --> 00:03:22,520
So, now let's see the most important part of the scoring system.

42
00:03:22,600 --> 00:03:26,720
We create an order theory, which consists of three principles.

43
00:03:26,720 --> 00:03:29,900
Here are principle number four, five, and number six.

44
00:03:30,280 --> 00:03:32,380
Now, let's look at principle number four.

45
00:03:32,380 --> 00:03:36,360
The later the stage, the more we're sure that a crime is practiced.

46
00:03:36,360 --> 00:03:42,920
As mentioned in chapter four of Taiwan criminal law, each crime consists of a sequence of behaviors.

47
00:03:42,920 --> 00:03:46,660
Those behaviors can be categorized in a specific order.

48
00:03:47,080 --> 00:03:49,460
So, let's take murder for example.

49
00:03:49,460 --> 00:03:51,040
Determined in stage one.

50
00:03:51,040 --> 00:03:54,520
Determined means somebody decided to kill someone.

51
00:03:54,520 --> 00:03:56,460
And in stage two, conspiracy.

52
00:03:56,460 --> 00:04:00,320
It means he or she started to make a plan for the murder.

53
00:04:00,320 --> 00:04:02,060
And in stage three, preparation.

54
00:04:02,060 --> 00:04:07,900
It means buying stuff, for example, weapons or arranging services for the murder plan.

55
00:04:08,040 --> 00:04:10,580
And in stage four, starts.

56
00:04:10,580 --> 00:04:16,540
It means when things are all set, the murderer takes action and is on the way to kill someone.

57
00:04:16,760 --> 00:04:18,480
And in stage five, practice.

58
00:04:18,480 --> 00:04:22,100
It means the murderer does pull the trigger and shoot someone.

59
00:04:22,880 --> 00:04:28,000
So, as we can see here, the later the stage, the more we're sure that a crime is practiced.

60
00:04:29,440 --> 00:04:35,320
So, with this principle in mind, we developed Android malware crime author theory.

61
00:04:35,560 --> 00:04:39,760
And in this theory, we also have five stages for the crime.

62
00:04:39,760 --> 00:04:50,720
For example, if a malware tries to send out your location data by using SMS, in stage one, we will check if related permission is requested by the malware.

63
00:04:50,720 --> 00:04:54,760
And then, we will check if the key native API is called.

64
00:04:54,760 --> 00:05:00,040
And in stage three, we will see if a certain combination of native API exists.

65
00:05:00,360 --> 00:05:04,180
And then, we will check if the APIs are called in a specific order.

66
00:05:04,420 --> 00:05:09,700
Finally, we will check if the APIs are handling the same register.

67
00:05:10,780 --> 00:05:16,260
Okay, so now you can see from this picture, this is a two-dimensional map for Android malware crime.

68
00:05:16,260 --> 00:05:19,280
For the crimes, we put them in y-axis.

69
00:05:19,280 --> 00:05:25,200
And for each crime, we use x-axis to see the evidence we caught for the crime.

70
00:05:25,240 --> 00:05:36,140
So, x5, y1 means in crime number one, we have found native APIs that are caught in a correct sequence and are handling the same register.

71
00:05:36,300 --> 00:05:44,880
And x3, y5 means in crime number five, we have found certain combinations of native APIs that is used in this APK.

72
00:05:44,880 --> 00:05:49,540
So, now let's look at principle number five.

73
00:05:49,540 --> 00:05:53,480
The more evidence we caught, the more penalty weight we give.

74
00:05:53,480 --> 00:05:59,620
So, we give stage two more weight than stage one, and stage three more weight than stage two, etc.

75
00:06:00,780 --> 00:06:04,840
Okay, principle number six, proportional sequence.

76
00:06:05,020 --> 00:06:11,500
As we decode it from the criminal law, the later the stage, the more we are sure that a crime is practiced.

77
00:06:11,500 --> 00:06:19,760
So, we consider proportional sequence, for example, 2 to the power of n, to present such principle in our scoring system.

78
00:06:19,900 --> 00:06:24,040
Alright, principle number seven, crimes are independence events.

79
00:06:24,040 --> 00:06:30,660
For simplicity, we assume crimes are independence events, and penalty weights can be added up directly.

80
00:06:30,800 --> 00:06:34,020
So, this is an example of adding up two crimes.

81
00:06:34,020 --> 00:06:39,860
In the malware, we find two crimes, they are stealing photos and stealing your banking account password.

82
00:06:39,860 --> 00:06:43,620
So, the calculation of the total penalty weights is quite simple.

83
00:06:43,620 --> 00:06:53,540
For example, for each crime, we use penalty weights of crime to multiply proportion of caught evidence and add up the results of the two.

84
00:06:54,040 --> 00:06:58,860
The last principle, principle number eight, thresholds generate system.

85
00:06:58,860 --> 00:07:08,520
So, after calculating the total penalty weights for a malware, we need to have threat level threshold, so that we can tell which threat level does the malware fill in.

86
00:07:08,520 --> 00:07:18,820
Unfortunately, we can't find them in criminal law, but we know we need to design a threshold-generated system for that, not just give any number by intuition.

87
00:07:19,180 --> 00:07:30,400
So, we decided that threshold for each level is the sum of the same proportion of caught evidence multiplies penalty weights of crimes.

88
00:07:30,400 --> 00:07:37,100
We know it's not a perfect one, but we're sure that we build a foundation for future optimization.

89
00:07:37,100 --> 00:07:42,580
Alright, now let's talk about the design logic of Delphi Bytecode Loader.

90
00:07:43,260 --> 00:07:47,000
And Junwei, he will take care of this part.

91
00:07:48,020 --> 00:07:53,440
Hello everyone, my name is Junwei, and I will take care of this part.

92
00:07:53,560 --> 00:07:59,300
So now, let's talk about the design logic of Delphi Bytecode Loader.

93
00:08:00,300 --> 00:08:08,680
Our Delphi Bytecode Loader is actually the implementation of the Android malware crime order theory.

94
00:08:08,680 --> 00:08:12,280
We implement every stage of the theory.

95
00:08:12,280 --> 00:08:14,060
There are five stages.

96
00:08:14,060 --> 00:08:16,600
The first three stages are easy.

97
00:08:16,600 --> 00:08:25,300
We simply use APIs in another open source tool, Android Guard, to implement the first three stages.

98
00:08:25,300 --> 00:08:31,300
As I just mentioned, the implementation of the first three stages are easy.

99
00:08:31,300 --> 00:08:35,300
But in stage 4, we need to do a little bit more.

100
00:08:35,440 --> 00:08:40,600
So before the implementation, we need to know what does stage 4 do.

101
00:08:41,000 --> 00:08:50,300
In stage 4, we find the calling sequence of native APIs and check if they are called in a specific order.

102
00:08:50,300 --> 00:09:12,740
For example, if a malware sends out your location data by SNS, then first it will call native API getCellLocation to get your location data, and then call native API sendTextMessage to send your location data by SNS.

103
00:09:12,740 --> 00:09:17,940
Normally, native APIs are wrapped in functions.

104
00:09:17,940 --> 00:09:24,460
So we trace back to see which function is cross-referenced from the native APIs.

105
00:09:24,460 --> 00:09:28,960
And we call those functions a parent function.

106
00:09:29,020 --> 00:09:35,930
And we will keep tracing back until we find a mutual parent function for both the native APIs.

107
00:09:36,320 --> 00:09:38,660
Here is the example.

108
00:09:38,660 --> 00:09:47,600
sendTextMessage is called by sendSNS, which is the parent function of sendTextMessage.

109
00:09:47,600 --> 00:09:56,400
And getCellLocation is called by getLocation, which is the parent function of getCellLocation.

110
00:09:56,400 --> 00:10:08,120
And if we keep tracing back, we will see that both sendSNS and getLocation shares the same parent function, sendTextMessage.

111
00:10:08,800 --> 00:10:21,820
And after we find the mutual parent function, we will scan through a small light code of the mutual parent function and check which function is called first.

112
00:10:21,820 --> 00:10:26,180
So this is the small light code of sendMessage.

113
00:10:26,400 --> 00:10:33,720
We can see that getLocation is called first to get location data of the cell phone.

114
00:10:33,840 --> 00:10:38,980
And sendSNS is called to send out the location data.

115
00:10:40,220 --> 00:10:49,900
And in stage 4, we found that our design can also overcome the obfuscation techniques used by the malware.

116
00:10:49,900 --> 00:10:56,940
When applying obfuscation techniques, functions except native APIs are renamed.

117
00:10:57,080 --> 00:11:02,220
This has made the decompiled source code hard to read for humans.

118
00:11:02,620 --> 00:11:08,140
A machine can still run the code because the logic of the code remains the same.

119
00:11:08,520 --> 00:11:10,840
Here is the example.

120
00:11:10,840 --> 00:11:19,500
When applying obfuscation techniques, native API sendTextMessage is called by function k.

121
00:11:19,500 --> 00:11:23,720
And function k is called by function f.

122
00:11:23,720 --> 00:11:29,500
The alternative API getCellLocation is called by function e.

123
00:11:29,500 --> 00:11:36,320
And both function e and f share the same parent function, which is a.

124
00:11:36,320 --> 00:11:45,660
You see, if you start reading the decompiled source code of a, it will be hard to figure out what is going on there.

125
00:11:45,660 --> 00:11:56,940
And by the way, since our goal is to find the mutual parent function, so it doesn't matter how many layers the wipers are.

126
00:11:57,900 --> 00:12:02,320
Now, let's see the implementation of stage 5.

127
00:12:02,320 --> 00:12:05,520
Yes, this is the most important part.

128
00:12:05,520 --> 00:12:12,840
In stage 5, we need to confirm that if the native APIs are handling the send register.

129
00:12:12,840 --> 00:12:15,880
Let's use the send example.

130
00:12:15,880 --> 00:12:20,480
Send out your location data by using SNS.

131
00:12:20,500 --> 00:12:29,360
So when native API getCellLocation is called, it will return the location data of the cell phone.

132
00:12:29,360 --> 00:12:42,420
And what we do in stage 5 is to check if the alternative API sendTextMessaging sends out the location data returned from getCellLocation.

133
00:12:43,040 --> 00:12:48,440
So in stage 5, we simulate the CPU operation.

134
00:12:48,440 --> 00:12:57,860
We read line by line of the Somali-like source code and operate like CPUs to get two things.

135
00:12:57,860 --> 00:13:02,080
First, the value of every register.

136
00:13:02,080 --> 00:13:08,500
Second, the information like functions who have operated the send register.

137
00:13:08,680 --> 00:13:13,820
To make this happen, we create a self-defined data type.

138
00:13:13,820 --> 00:13:16,800
We call it register object.

139
00:13:16,880 --> 00:13:22,080
In each register object, we store three kinds of information.

140
00:13:22,080 --> 00:13:24,680
No.1, the register name.

141
00:13:24,680 --> 00:13:27,740
No.2, the value of register.

142
00:13:27,740 --> 00:13:31,840
And No.3, the function who use this register.

143
00:13:31,840 --> 00:13:34,420
Let's see an example.

144
00:13:34,600 --> 00:13:37,740
So the register name is fee7.

145
00:13:37,740 --> 00:13:41,580
And the value of the register is a string.

146
00:13:41,580 --> 00:13:48,780
And the string appends the value of string1 and the result of function1.

147
00:13:48,780 --> 00:13:56,660
And then we can see that the register is used as the input resource of the function2.

148
00:13:56,780 --> 00:14:11,620
By the way, when filling the value of useByWhich function in the register object, we extend every register by cross-referencing other register objects in the table.

149
00:14:11,620 --> 00:14:21,040
So, for example, by cross-referencing, we know that fee8 is a string called userLocation.

150
00:14:21,040 --> 00:14:25,080
And fee3 is a function called getLocation.

151
00:14:25,260 --> 00:14:36,200
As you can see in the lower right corner, the result of getLocation is appended to the string which is userLocation.

152
00:14:36,200 --> 00:14:42,660
And the new string is sent out by using function sendSns.

153
00:14:42,660 --> 00:14:55,620
In other words, the value of register fee7 is generated by using function getLocation, which has native API 1 in it.

154
00:14:55,620 --> 00:15:05,420
And the value is used as an input for function sendSns, which has native API 2 in it.

155
00:15:05,420 --> 00:15:15,820
So now, we prove that by using the register object, we can check if the APIs are handling the same register.

156
00:15:15,820 --> 00:15:22,880
So after we scan through the source code, we produce dots of register objects.

157
00:15:23,180 --> 00:15:30,620
And those register objects will be organized when a two-dimensional Python list.

158
00:15:30,740 --> 00:15:34,320
It is a similar idea like hash table.

159
00:15:34,320 --> 00:15:39,600
We use it to boot out the read and write of the list.

160
00:15:39,600 --> 00:15:42,780
So now, let's see the table.

161
00:15:42,820 --> 00:15:49,200
As you can see here, register fee4 has three register objects.

162
00:15:49,200 --> 00:15:55,220
That means in the source code we scanned, fee4 was used three times.

163
00:15:55,220 --> 00:16:04,720
And every time when it was used, we store the present value of register and the function who used it if there is one.

164
00:16:04,800 --> 00:16:09,820
So basically, the whole table is the history of the registers.

165
00:16:10,520 --> 00:16:22,740
So when we finish constructing the table, we then scan through all register objects in the table to check if the native APIs are handling the same registers.

166
00:16:22,740 --> 00:16:28,520
So now, let's see how to use Quark engine to analyze the malware.

167
00:16:28,660 --> 00:16:31,660
Now, let's get back to Kunyu.

168
00:16:35,330 --> 00:16:38,850
In this section, we prepared two malware.

169
00:16:38,850 --> 00:16:43,430
One is non-obfuscated and the other one is obfuscated.

170
00:16:43,430 --> 00:16:49,550
And for each malware, we will show how we detect the behavior of the malware with the detection rule.

171
00:16:49,750 --> 00:16:51,710
Now let's look at the first malware.

172
00:16:51,710 --> 00:16:54,070
This is a non-obfuscated one.

173
00:16:54,070 --> 00:17:01,870
We will use the rule in Quark engine to detect whether if the malware sends out the cell phone location data by using SMS.

174
00:17:02,210 --> 00:17:06,190
So this is the detailed report of Quark engine.

175
00:17:06,190 --> 00:17:14,250
In this report, the engine shows the detection results of one single malware behavior or you can say one single malware crime.

176
00:17:14,770 --> 00:17:20,750
For example, we try to find if the malware sends out your location data by using SMS.

177
00:17:20,750 --> 00:17:27,690
So in this report, we list out the evidence we found in each stage of the Android malware crime order theory.

178
00:17:27,690 --> 00:17:36,530
And this report shows we find evidence in every stage, which means we have 100% of confidence that the malware has this behavior.

179
00:17:36,530 --> 00:17:37,530
So let's see.

180
00:17:37,530 --> 00:17:45,030
In stage 1, permissions like send SMS, access course location, and find locations are requested.

181
00:17:45,030 --> 00:17:51,710
In the second stage, the key native APIs like getCellLocation and sendTextMessages are used.

182
00:17:51,710 --> 00:17:56,350
And in stage 3, we find certain combinations of native API exist.

183
00:17:56,350 --> 00:18:03,790
And in stage 4, we found out that in functions like sendMessage and doBytes, the APIs are called in the right sequence.

184
00:18:03,790 --> 00:18:11,990
And in stage 5, in function sendMessage, we find out that those APIs are handling the same register.

185
00:18:12,650 --> 00:18:21,790
So now let's think, if you are analyzing this malware, and you want to trace the compiled source code to see the evidence, how do you do it?

186
00:18:21,830 --> 00:18:25,470
Our suggestion is you start backwards.

187
00:18:25,630 --> 00:18:28,670
That means you start from stage 5.

188
00:18:28,670 --> 00:18:40,670
For example, in stage 5, we know that inside a function of sendMessage, it has two functions that contains the two native APIs respectively, and they are handling the same register.

189
00:18:40,670 --> 00:18:46,810
So you start to locate a function sendMessage in the decompiled source code.

190
00:18:47,110 --> 00:18:52,030
And in stage 4, we know that those two functions are called in the right sequence.

191
00:18:52,030 --> 00:18:59,910
So we can start to find the functions that contains the native APIs and check if they are really called in the right sequence.

192
00:19:00,010 --> 00:19:05,430
The information of the two functions and the sequence will be shown in the next version of Quark Engine.

193
00:19:06,370 --> 00:19:09,650
So now let's look at a real example.

194
00:19:09,650 --> 00:19:12,270
Let's locate the function sendMessage.

195
00:19:12,270 --> 00:19:17,810
And we found out that two functions that contains the two native APIs respectively.

196
00:19:17,990 --> 00:19:20,690
They are sendSMS and getLocation.

197
00:19:20,690 --> 00:19:27,810
And if we dive into the function of getLocation, we will see that it contains native API getLocation.

198
00:19:27,970 --> 00:19:36,050
And if we dive in this function of sendMessage, sendSMS, we will see that it contains native API sendTextMessage.

199
00:19:36,050 --> 00:19:42,490
So the code here means it first collects your cell phone location data and sends it out through SMS.

200
00:19:43,270 --> 00:19:46,130
So now let's dive into the source code of getLocation.

201
00:19:46,130 --> 00:19:55,070
As you can see in the source code, it tries to call native API getCellLocation and returns this information at the end of the code.

202
00:19:55,830 --> 00:19:59,670
And now let's dive into the source code of sendSMS.

203
00:19:59,670 --> 00:20:04,890
Native API sendTextMessage is used to send out the location information.

204
00:20:04,890 --> 00:20:06,650
So quite simple, isn't it?

205
00:20:06,690 --> 00:20:09,690
Now let's look at the second malware.

206
00:20:09,690 --> 00:20:12,310
This is an obfuscated one.

207
00:20:12,370 --> 00:20:22,470
We will use the rule in Quark Engine to find whether if the malware detects Wi-Fi hotspot by gathering information like active network info and cell phone location.

208
00:20:22,950 --> 00:20:27,670
Okay, so as a malware analyst, we read the report backwards.

209
00:20:27,730 --> 00:20:33,950
As you can see in stage 5, there are functions like p.a, addView.c, and af.run.

210
00:20:33,950 --> 00:20:41,710
And those functions have two functions that contain native APIs respectively, and they are handling the same register.

211
00:20:41,710 --> 00:20:51,090
And in stage 4, those two functions are also called in the right sequence in functions like p.a, addView.c, and af.run.

212
00:20:51,090 --> 00:20:59,690
So according to the report, we can see that malware has the behavior of Wi-Fi hotspot detection in three parts of the source code.

213
00:20:59,690 --> 00:21:02,630
And we can pick any parts for further analysis.

214
00:21:02,630 --> 00:21:05,870
So we just pick function p.a.

215
00:21:06,730 --> 00:21:09,830
So now let's look in... now let's see the source code.

216
00:21:09,830 --> 00:21:13,210
Let's first locate the function p.a.

217
00:21:13,210 --> 00:21:21,150
And we found out that two functions that contains the two native APIs respectively, they are ap.a and af.f.

218
00:21:21,150 --> 00:21:29,230
And if we dive into the source code of function ap.a, we will see that it contains native API getActiveNetworkInfo.

219
00:21:29,230 --> 00:21:36,250
And if we dive into the function of af.f, we will see that it contains native API getCellLocation.

220
00:21:36,270 --> 00:21:47,410
So this quote here means, after collecting information from function ap.a and af.f, they sent the information as an input for function am.a.

221
00:21:47,770 --> 00:21:51,210
So now let's dive into the source code of function ap.a.

222
00:21:51,210 --> 00:21:59,870
As you can see in the source code, it tries to call native API getActiveNetworkInfo and return the related information at some points.

223
00:22:00,290 --> 00:22:04,270
So now let's dive into the source code of af.f.

224
00:22:04,470 --> 00:22:10,330
Native API getCellLocation is used to get the cell phone location data.

225
00:22:10,330 --> 00:22:13,550
And this information is processed with some other strings.

226
00:22:13,550 --> 00:22:18,430
And at the end of this function, it returns the strings with the information.

227
00:22:18,430 --> 00:22:30,310
As mentioned earlier, after collecting information from function ap.a and af.f, they used the information as an input for function am.a.

228
00:22:30,390 --> 00:22:33,350
And we noticed one thing.

229
00:22:33,350 --> 00:22:39,830
The function am.a used byte arrayed output string as one of its input parameter.

230
00:22:39,830 --> 00:22:48,190
And we know when seeing byte arrayed output string, it means the function is probably trying to write the data into a file.

231
00:22:48,190 --> 00:22:50,410
This is amazing, isn't it?

232
00:22:50,410 --> 00:22:56,270
So with Quark engine, malware analysis can really boost up their productivity.

233
00:22:57,170 --> 00:23:02,190
Okay, so now I will introduce our detection rule generate strategy.

234
00:23:02,470 --> 00:23:06,690
So why do we need to develop the detection rule generate strategy?

235
00:23:07,210 --> 00:23:15,170
Because to make our engine practical and easy to use, we need to have more detection rules.

236
00:23:15,170 --> 00:23:19,330
However, the speed of rule generated by human is quite slow.

237
00:23:19,590 --> 00:23:25,950
And human generated rules is subjected to his or her experiences of malware analysis.

238
00:23:26,070 --> 00:23:31,270
So we developed a rule generate strategy to boost up the production of detection rules.

239
00:23:31,670 --> 00:23:44,510
And since our goal is to find all kinds of behaviors in the malware, so if we use permissions and native APIs to generate all possible rules, we will have an amazing amount of rules.

240
00:23:44,510 --> 00:23:53,290
After generating the rules, we then use Quark engine to find the intersection between those amazing amounts of rules and the malware we prepared.

241
00:23:53,290 --> 00:23:57,010
In other words, we find rules that match the malware behaviors.

242
00:23:57,090 --> 00:24:03,630
However, this is not a good way to generate detection rules because it's time and resource consuming.

243
00:24:03,770 --> 00:24:07,910
So we developed a seven step generate strategy.

244
00:24:07,910 --> 00:24:15,210
Step one, we curl down all native API information on Android official API reference.

245
00:24:15,210 --> 00:24:20,210
For example, this is the native API information of send text message.

246
00:24:20,890 --> 00:24:26,410
You can see the input parameters, return value and a description of this API.

247
00:24:27,070 --> 00:24:32,070
Okay, step two, we did a little bit modification to our engine.

248
00:24:32,070 --> 00:24:37,890
We ignore the permission checks in stage one of the Android malware crime order theory.

249
00:24:37,970 --> 00:24:45,450
And in step three, we find all kinds of API combination and generate rules without permission information.

250
00:24:46,070 --> 00:24:52,710
And in stage four, we use the modified Quark engine to find intersections of the rules and the malwares.

251
00:24:52,710 --> 00:24:59,150
We call the rules... we call rules in intersection the first stage verified rules.

252
00:24:59,150 --> 00:25:03,930
In other words, these rules need to be verified again.

253
00:25:04,450 --> 00:25:13,550
And since we don't need to generate rules with permission and verify the permissions in Quark engine, the whole process of rule production speed up.

254
00:25:13,870 --> 00:25:17,990
And in stage five, we try to generate rules with permissions.

255
00:25:18,130 --> 00:25:24,790
So inside the intersection, we have first stage verified rules matched with malwares.

256
00:25:24,790 --> 00:25:34,590
We then use the first stage rules and permission in the matched malware to generate rules with permissions, which is the second stage rules.

257
00:25:35,150 --> 00:25:39,730
And in step six, we then use the Quark engine.

258
00:25:39,730 --> 00:25:52,050
Yes, the full function version to find again, the intersection of the second stage rules, which are the one with permission and the malware we prepared.

259
00:25:52,050 --> 00:25:58,410
So after that, for each rule, we label the number of matched malware.

260
00:25:58,430 --> 00:26:05,530
For example, the behavior of rule number one can be found in a hundred malware, etc.

261
00:26:06,110 --> 00:26:13,450
And in step seven, after labeling the rules, we then sort the rules by number of matched malware.

262
00:26:13,730 --> 00:26:19,030
We will review the rules from the highest matched one to the lowest one.

263
00:26:19,910 --> 00:26:23,250
All right, the last part, feature works.

264
00:26:24,670 --> 00:26:28,630
As I mentioned earlier, we still have a lot of things to do.

265
00:26:28,630 --> 00:26:37,770
For example, we need to have more detection rules, and we also need to deal with the .so files and the packed APKs.

266
00:26:37,830 --> 00:26:43,710
And we want to have more features of Dalvik Bytecode Loader, for example, the downloader.

267
00:26:43,710 --> 00:26:51,090
And we also want to apply the scoring system to other binary formats.

268
00:26:51,150 --> 00:26:52,950
Yeah, it is in our to-do list.

269
00:26:53,410 --> 00:26:57,730
And we noticed that API changes in different versions of Android.

270
00:26:57,730 --> 00:27:01,770
So we will also take care of this problem in the next version of Quark.

271
00:27:01,850 --> 00:27:08,050
Oh, we probably would change the core library since Android God is quite inactive recently.

272
00:27:08,650 --> 00:27:10,410
And one more thing.

273
00:27:10,710 --> 00:27:15,630
Actually, we are trying to make Quark itself easier to be integrated to other tools.

274
00:27:15,630 --> 00:27:23,230
For example, users can import Quark as a Python library and output the analysis result as a JSON file.

275
00:27:23,230 --> 00:27:31,590
So now Quark is collected in BlackArch Linux and will soon be integrated to a threat intelligence analysis tool, Intel O.

276
00:27:32,470 --> 00:27:35,310
And there is one nugget that I would like to share.

277
00:27:35,310 --> 00:27:37,710
We work at the limits of our tools.

278
00:27:37,710 --> 00:27:41,030
When new tools come along, new things are possible.

279
00:27:41,390 --> 00:27:43,630
Okay, so that's all for today.

280
00:27:43,630 --> 00:27:49,130
And if you have any questions, please feel free to DM our Twitter accounts.

281
00:27:49,130 --> 00:27:50,310
Thank you.