start	end	text
0	4360	So, this is the outline.
4720	8060	Number one, we will introduce our malware scouting system.
8220	12280	And number two, we will show you how we designed the Dalvik bytecode loader.
12300	17180	And number three, we will go through two cases of real malware analysis using Quark Engine.
17380	21760	And number four, we will share our strategy of generating the detection rules.
22080	24800	And the last thing, yes, the feature works.
24800	27140	Because we still have a lot of things to do.
27980	31800	Alright, so let's introduce the malware scoring system.
31980	38500	As we know, when developing a malware analysis engine, it is important to have a scoring system.
38500	43580	However, those systems are either business secrets or just too complicated.
43680	50080	Therefore, we decided to create a simple but solid one and take that as a challenge.
50400	54300	And since we wanted to design a novel scoring system,
54300	59570	we stopped reading and decoding whatever people do in the field of cybersecurity.
60000	64570	Because we don't want our ideas to be subjected to the existing systems.
65180	70240	So we started to find ideas in fields other than cybersecurity.
70240	72500	And luckily, we found one.
73000	77200	Yes, the best practice we found is the criminal law.
77720	83740	So, when sentenced a penalty for a criminal, the judge weighs the penalties based on the criminal law.
83740	87320	And after decoding the law, we find principles behind it.
87320	91040	And we develop a scoring system for Android malware.
91960	95420	There are only eight principles decoded from the criminal law.
95420	98020	And I'll go through it in the following slides.
98120	100360	Now let's see principle number one.
100360	104700	A malware crime consists of action and targets.
104920	110220	In the criminal law, the definition of a crime consists of action and targets.
110220	113680	For example, steal money and kill people.
113680	120360	So, with this principle in mind, we develop the definition of a crime for Android malware.
120500	125920	And the definition is, the malware crime consists of action and targets.
126260	131540	For example, steal photos or steal your banking account password.
132620	135000	Now let's see principle number two.
135000	139400	We consider that the loss of fame is greater than the loss of wealth.
139400	145640	So, in the criminal law, physical body injury is more serious than psychological injury.
145700	152560	So, the principle we decoded here is, when things are hard to recover, we consider it a felony.
152900	157240	So, with this principle decoded, we develop our second principle.
157240	165120	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.
165820	169760	Okay, now let's see principle number three, arithmetic sequence.
170080	179620	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?
179640	183180	Why 20 and 7 years? Why the number?
183180	190180	We found no obvious principles in the criminal law, so we use arithmetic sequence to weigh the penalty of each crime.
190180	197740	For example, the penalty weight of Y1 is 10, and Y2 is 20, and Y3 is 30, etc.
198800	202520	So, now let's see the most important part of the scoring system.
202600	206720	We create an order theory, which consists of three principles.
206720	209900	Here are principle number four, five, and number six.
210280	212380	Now, let's look at principle number four.
212380	216360	The later the stage, the more we're sure that a crime is practiced.
216360	222920	As mentioned in chapter four of Taiwan criminal law, each crime consists of a sequence of behaviors.
222920	226660	Those behaviors can be categorized in a specific order.
227080	229460	So, let's take murder for example.
229460	234520	Determined in stage one. Determined means somebody decided to kill someone.
234520	240320	And in stage two, conspiracy. It means he or she started to make a plan for the murder.
240320	247900	And in stage three, preparation. It means buying stuff, for example, weapons or arranging services for the murder plan.
248040	256540	And in stage four, starts. It means when things are all set, the murderer takes action and is on the way to kill someone.
256760	262100	And in stage five, practice. It means the murderer does pull the trigger and shoot someone.
262880	268000	So, as we can see here, the later the stage, the more we're sure that a crime is practiced.
269440	275320	So, with this principle in mind, we developed Android malware crime author theory.
275560	279760	And in this theory, we also have five stages for the crime.
279760	285120	For example, if a malware tries to send out your location data by using SMS,
285560	290720	in stage one, we will check if related permission is requested by the malware.
290720	294760	And then, we will check if the key native API is called.
294760	300040	And in stage three, we will see if a certain combination of native API exists.
300360	304180	And then, we will check if the APIs are called in a specific order.
304420	309700	Finally, we will check if the APIs are handling the same register.
310780	316260	Okay, so now you can see from this picture, this is a two-dimensional map for Android malware crime.
316260	319280	For the crimes, we put them in y-axis.
319280	325200	And for each crime, we use x-axis to see the evidence we caught for the crime.
325240	336140	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.
336300	344880	And x3, y5 means in crime number five, we have found certain combinations of native APIs that is used in this APK.
344880	349540	So, now let's look at principle number five.
349540	353480	The more evidence we caught, the more penalty weight we give.
353480	359620	So, we give stage two more weight than stage one, and stage three more weight than stage two, etc.
360780	364840	Okay, principle number six, proportional sequence.
365020	371500	As we decode it from the criminal law, the later the stage, the more we are sure that a crime is practiced.
371500	379760	So, we consider proportional sequence, for example, 2 to the power of n, to present such principle in our scoring system.
379900	384040	Alright, principle number seven, crimes are independence events.
384040	390660	For simplicity, we assume crimes are independence events, and penalty weights can be added up directly.
390800	394020	So, this is an example of adding up two crimes.
394020	399860	In the malware, we find two crimes, they are stealing photos and stealing your banking account password.
399860	403620	So, the calculation of the total penalty weights is quite simple.
403620	413540	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.
414040	418860	The last principle, principle number eight, thresholds generate system.
418860	428520	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.
428520	438820	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.
439180	450400	So, we decided that threshold for each level is the sum of the same proportion of caught evidence multiplies penalty weights of crimes.
450400	457100	We know it's not a perfect one, but we're sure that we build a foundation for future optimization.
457100	462580	Alright, now let's talk about the design logic of Delphi Bytecode Loader.
463260	467000	And Junwei, he will take care of this part.
468020	473440	Hello everyone, my name is Junwei, and I will take care of this part.
473560	479300	So now, let's talk about the design logic of Delphi Bytecode Loader.
480300	488680	Our Delphi Bytecode Loader is actually the implementation of the Android malware crime order theory.
488680	492280	We implement every stage of the theory.
492280	496600	There are five stages. The first three stages are easy.
496600	505300	We simply use APIs in another open source tool, Android Guard, to implement the first three stages.
505300	511300	As I just mentioned, the implementation of the first three stages are easy.
511300	515300	But in stage 4, we need to do a little bit more.
515440	520600	So before the implementation, we need to know what does stage 4 do.
521000	530300	In stage 4, we find the calling sequence of native APIs and check if they are called in a specific order.
530300	544500	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,
544500	552740	and then call native API sendTextMessage to send your location data by SNS.
552740	557940	Normally, native APIs are wrapped in functions.
557940	564460	So we trace back to see which function is cross-referenced from the native APIs.
564460	568960	And we call those functions a parent function.
569020	575930	And we will keep tracing back until we find a mutual parent function for both the native APIs.
576320	578660	Here is the example.
578660	587600	sendTextMessage is called by sendSNS, which is the parent function of sendTextMessage.
587600	596400	And getCellLocation is called by getLocation, which is the parent function of getCellLocation.
596400	608120	And if we keep tracing back, we will see that both sendSNS and getLocation shares the same parent function, sendTextMessage.
608800	621820	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.
621820	626180	So this is the small light code of sendMessage.
626400	633720	We can see that getLocation is called first to get location data of the cell phone.
633840	638980	And sendSNS is called to send out the location data.
640220	649900	And in stage 4, we found that our design can also overcome the obfuscation techniques used by the malware.
649900	656940	When applying obfuscation techniques, functions except native APIs are renamed.
657080	662220	This has made the decompiled source code hard to read for humans.
662620	668140	A machine can still run the code because the logic of the code remains the same.
668520	670840	Here is the example.
670840	679500	When applying obfuscation techniques, native API sendTextMessage is called by function k.
679500	683720	And function k is called by function f.
683720	689500	The alternative API getCellLocation is called by function e.
689500	696320	And both function e and f share the same parent function, which is a.
696320	705660	You see, if you start reading the decompiled source code of a, it will be hard to figure out what is going on there.
705660	716940	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.
717900	722320	Now, let's see the implementation of stage 5.
722320	725520	Yes, this is the most important part.
725520	732840	In stage 5, we need to confirm that if the native APIs are handling the send register.
732840	735880	Let's use the send example.
735880	740480	Send out your location data by using SNS.
740500	749360	So when native API getCellLocation is called, it will return the location data of the cell phone.
749360	762420	And what we do in stage 5 is to check if the alternative API sendTextMessaging sends out the location data returned from getCellLocation.
763040	768440	So in stage 5, we simulate the CPU operation.
768440	777860	We read line by line of the Somali-like source code and operate like CPUs to get two things.
777860	782080	First, the value of every register.
782080	788500	Second, the information like functions who have operated the send register.
788680	793820	To make this happen, we create a self-defined data type.
793820	796800	We call it register object.
796880	802080	In each register object, we store three kinds of information.
802080	804680	No.1, the register name.
804680	807740	No.2, the value of register.
807740	811840	And No.3, the function who use this register.
811840	814420	Let's see an example.
814600	817740	So the register name is fee7.
817740	821580	And the value of the register is a string.
821580	828780	And the string appends the value of string1 and the result of function1.
828780	836660	And then we can see that the register is used as the input resource of the function2.
836780	844540	By the way, when filling the value of useByWhich function in the register object,
844540	851620	we extend every register by cross-referencing other register objects in the table.
851620	861040	So, for example, by cross-referencing, we know that fee8 is a string called userLocation.
861040	865080	And fee3 is a function called getLocation.
865260	876200	As you can see in the lower right corner, the result of getLocation is appended to the string which is userLocation.
876200	882660	And the new string is sent out by using function sendSns.
882660	895620	In other words, the value of register fee7 is generated by using function getLocation, which has native API 1 in it.
895620	905420	And the value is used as an input for function sendSns, which has native API 2 in it.
905420	915820	So now, we prove that by using the register object, we can check if the APIs are handling the same register.
915820	922880	So after we scan through the source code, we produce dots of register objects.
923180	930620	And those register objects will be organized when a two-dimensional Python list.
930740	934320	It is a similar idea like hash table.
934320	939600	We use it to boot out the read and write of the list.
939600	942780	So now, let's see the table.
942820	949200	As you can see here, register fee4 has three register objects.
949200	955220	That means in the source code we scanned, fee4 was used three times.
955220	964720	And every time when it was used, we store the present value of register and the function who used it if there is one.
964800	969820	So basically, the whole table is the history of the registers.
970520	982740	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.
982740	988520	So now, let's see how to use Quark engine to analyze the malware.
988660	991660	Now, let's get back to Kunyu.
995330	1003430	In this section, we prepared two malware. One is non-obfuscated and the other one is obfuscated.
1003430	1009550	And for each malware, we will show how we detect the behavior of the malware with the detection rule.
1009750	1014070	Now let's look at the first malware. This is a non-obfuscated one.
1014070	1021870	We will use the rule in Quark engine to detect whether if the malware sends out the cell phone location data by using SMS.
1022210	1026190	So this is the detailed report of Quark engine.
1026190	1034250	In this report, the engine shows the detection results of one single malware behavior or you can say one single malware crime.
1034770	1040750	For example, we try to find if the malware sends out your location data by using SMS.
1040750	1047690	So in this report, we list out the evidence we found in each stage of the Android malware crime order theory.
1047690	1056530	And this report shows we find evidence in every stage, which means we have 100% of confidence that the malware has this behavior.
1056530	1065030	So let's see. In stage 1, permissions like send SMS, access course location, and find locations are requested.
1065030	1071710	In the second stage, the key native APIs like getCellLocation and sendTextMessages are used.
1071710	1076350	And in stage 3, we find certain combinations of native API exist.
1076350	1083790	And in stage 4, we found out that in functions like sendMessage and doBytes, the APIs are called in the right sequence.
1083790	1091990	And in stage 5, in function sendMessage, we find out that those APIs are handling the same register.
1092650	1101790	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?
1101830	1108670	Our suggestion is you start backwards. That means you start from stage 5.
1108670	1120670	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.
1120670	1126810	So you start to locate a function sendMessage in the decompiled source code.
1127110	1132030	And in stage 4, we know that those two functions are called in the right sequence.
1132030	1139910	So we can start to find the functions that contains the native APIs and check if they are really called in the right sequence.
1140010	1145430	The information of the two functions and the sequence will be shown in the next version of Quark Engine.
1146370	1149650	So now let's look at a real example.
1149650	1152270	Let's locate the function sendMessage.
1152270	1157810	And we found out that two functions that contains the two native APIs respectively.
1157990	1160690	They are sendSMS and getLocation.
1160690	1167810	And if we dive into the function of getLocation, we will see that it contains native API getLocation.
1167970	1176050	And if we dive in this function of sendMessage, sendSMS, we will see that it contains native API sendTextMessage.
1176050	1182490	So the code here means it first collects your cell phone location data and sends it out through SMS.
1183270	1186130	So now let's dive into the source code of getLocation.
1186130	1195070	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.
1195830	1199670	And now let's dive into the source code of sendSMS.
1199670	1204890	Native API sendTextMessage is used to send out the location information.
1204890	1206650	So quite simple, isn't it?
1206690	1209690	Now let's look at the second malware.
1209690	1212310	This is an obfuscated one.
1212370	1222470	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.
1222950	1227670	Okay, so as a malware analyst, we read the report backwards.
1227730	1233950	As you can see in stage 5, there are functions like p.a, addView.c, and af.run.
1233950	1241710	And those functions have two functions that contain native APIs respectively, and they are handling the same register.
1241710	1251090	And in stage 4, those two functions are also called in the right sequence in functions like p.a, addView.c, and af.run.
1251090	1259690	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.
1259690	1262630	And we can pick any parts for further analysis.
1262630	1265870	So we just pick function p.a.
1266730	1269830	So now let's look in... now let's see the source code.
1269830	1273210	Let's first locate the function p.a.
1273210	1281150	And we found out that two functions that contains the two native APIs respectively, they are ap.a and af.f.
1281150	1289230	And if we dive into the source code of function ap.a, we will see that it contains native API getActiveNetworkInfo.
1289230	1296250	And if we dive into the function of af.f, we will see that it contains native API getCellLocation.
1296270	1307410	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.
1307770	1311210	So now let's dive into the source code of function ap.a.
1311210	1319870	As you can see in the source code, it tries to call native API getActiveNetworkInfo and return the related information at some points.
1320290	1324270	So now let's dive into the source code of af.f.
1324470	1330330	Native API getCellLocation is used to get the cell phone location data.
1330330	1333550	And this information is processed with some other strings.
1333550	1338430	And at the end of this function, it returns the strings with the information.
1338430	1350310	As mentioned earlier, after collecting information from function ap.a and af.f, they used the information as an input for function am.a.
1350390	1353350	And we noticed one thing.
1353350	1359830	The function am.a used byte arrayed output string as one of its input parameter.
1359830	1368190	And we know when seeing byte arrayed output string, it means the function is probably trying to write the data into a file.
1368190	1370410	This is amazing, isn't it?
1370410	1376270	So with Quark engine, malware analysis can really boost up their productivity.
1377170	1382190	Okay, so now I will introduce our detection rule generate strategy.
1382470	1386690	So why do we need to develop the detection rule generate strategy?
1387210	1395170	Because to make our engine practical and easy to use, we need to have more detection rules.
1395170	1399330	However, the speed of rule generated by human is quite slow.
1399590	1405950	And human generated rules is subjected to his or her experiences of malware analysis.
1406070	1411270	So we developed a rule generate strategy to boost up the production of detection rules.
1411670	1424510	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.
1424510	1433290	After generating the rules, we then use Quark engine to find the intersection between those amazing amounts of rules and the malware we prepared.
1433290	1437010	In other words, we find rules that match the malware behaviors.
1437090	1443630	However, this is not a good way to generate detection rules because it's time and resource consuming.
1443770	1447910	So we developed a seven step generate strategy.
1447910	1455210	Step one, we curl down all native API information on Android official API reference.
1455210	1460210	For example, this is the native API information of send text message.
1460890	1466410	You can see the input parameters, return value and a description of this API.
1467070	1472070	Okay, step two, we did a little bit modification to our engine.
1472070	1477890	We ignore the permission checks in stage one of the Android malware crime order theory.
1477970	1485450	And in step three, we find all kinds of API combination and generate rules without permission information.
1486070	1492710	And in stage four, we use the modified Quark engine to find intersections of the rules and the malwares.
1492710	1499150	We call the rules... we call rules in intersection the first stage verified rules.
1499150	1503930	In other words, these rules need to be verified again.
1504450	1513550	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.
1513870	1517990	And in stage five, we try to generate rules with permissions.
1518130	1524790	So inside the intersection, we have first stage verified rules matched with malwares.
1524790	1534590	We then use the first stage rules and permission in the matched malware to generate rules with permissions, which is the second stage rules.
1535150	1539730	And in step six, we then use the Quark engine.
1539730	1552050	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.
1552050	1558410	So after that, for each rule, we label the number of matched malware.
1558430	1565530	For example, the behavior of rule number one can be found in a hundred malware, etc.
1566110	1573450	And in step seven, after labeling the rules, we then sort the rules by number of matched malware.
1573730	1579030	We will review the rules from the highest matched one to the lowest one.
1579910	1583250	All right, the last part, feature works.
1584670	1588630	As I mentioned earlier, we still have a lot of things to do.
1588630	1597770	For example, we need to have more detection rules, and we also need to deal with the .so files and the packed APKs.
1597830	1603710	And we want to have more features of Dalvik Bytecode Loader, for example, the downloader.
1603710	1611090	And we also want to apply the scoring system to other binary formats.
1611150	1612950	Yeah, it is in our to-do list.
1613410	1617730	And we noticed that API changes in different versions of Android.
1617730	1621770	So we will also take care of this problem in the next version of Quark.
1621850	1628050	Oh, we probably would change the core library since Android God is quite inactive recently.
1628650	1630410	And one more thing.
1630710	1635630	Actually, we are trying to make Quark itself easier to be integrated to other tools.
1635630	1643230	For example, users can import Quark as a Python library and output the analysis result as a JSON file.
1643230	1651590	So now Quark is collected in BlackArch Linux and will soon be integrated to a threat intelligence analysis tool, Intel O.
1652470	1655310	And there is one nugget that I would like to share.
1655310	1657710	We work at the limits of our tools.
1657710	1661030	When new tools come along, new things are possible.
1661390	1663630	Okay, so that's all for today.
1663630	1669130	And if you have any questions, please feel free to DM our Twitter accounts.
1669130	1670310	Thank you.