dataesr/scientific-paragraphs-categorization huggingface dataset:
After a rule triggers, the Pattern Engine executes a rule action (Java program code), while relying on the functionalities of the SDN Controller. Particularly, we have implemented this configuration through the REST interface of the SDN Controller (we used the RYU controller (https://osrg. github. io/ryu/)). The Pattern Engine can then dynamically adjust the network based on previously received rules. This enables in general a more agile management of the network, as compared to regular SDN controller based approaches. Before we can add queue settings and QoS rules, the first step to configuring the SDN is conducted during the bootstrapping phase to establish the communication with a switch. Listing 3 shows this first call that informs the SDN controller that the SDN switch (implemented using Open vSwitch (https://www.
openvswitch. org/; OVS) is listening on a particular IP address and port number. Then, to communicate between SDN controller and a switch the Open vSwitch Database Management Protocol) (https://tools. ietf. org/html/rfc7047) in conjunction with OpenFlow (https://www. opennetworking. org/images/stories/downloads/sdn-resources/onfspecifications/openflow/openflow-spec-v1. 3. 1. pdf) version 1. 3 are used. Thereby, the OVS_IP_ADDR is the IP address of the Open vSwitch, TCP_Listen_PORT is the port number of the switch, SDN_IP is the address of the SDN controller, SDN_Listen_PORT is its port number (for HTTP communication), and Switch_ID is given to uniquely identify a switch. In a second step, a call is made to the SDN Controller to set a queue table for a particular port or all ports of a switch.
Thereby, this table comprises the following parameters: Port_Name is the name corresponding to the port planned to set queue for, and linux-htb/linux-hfsc are two options to specify the queuing discipline (representing respective queuing algorithms in the Linux kernel). Further, we need to specify the maximum and minimal rate (max_rate and min_rate properties), and we can specify the data rate limits for each queue in the queues property. The ID of a particular queue is the index of the queue in the queues list. Finally, the SDN Controller is called by the Pattern Engine to install QoS flow rules in the flow table at a switch. Each installed QoS flow rule will match source and destination IP addresses of a packet with given source and destination IP addresses given. The matched packets will be forwarded to a queue with a particular queue ID, and so the traffic of similar packets will be limited according to the bandwidth limitation specified in that queue.
Garcia et al. [13]  used a machine learning method of classification regression tree to study a family classifier that can classify 33 malicious App families manually labeled in the AMG  [14]  dataset, achieving 95% accuracy. Wang and others  [5]  proposed the use of deep learning detection methods to implement Android malware detection systems; nonetheless, it did not study the implementation of multiclassification of malware. Andronio et al. [7]  analyzed the behavioral characteristics of Android ransomware and implemented a detection model for ransomware. In exploring the visualization of malicious software, Nataraj et al. [15]  used the K-nearest neighbor (KNN) algorithm as an automatic classification technology to classify 25 malicious software families with grayscale image and reached an accuracy rate of 98%.
The main purpose is to find the behaviors of the malicious Apps. We used the TF-IDF algorithm to calculate the influence weight of the extracted App's behavior characteristics. In this way, we got the most influential behavioral dataset in malicious Apps. After our calculation, we obtained 1695 behavior char-acteristics. For the convenience of researchers in related communities, we open the dataset (iii) We studied the influence of different features of color visualization on Android malicious Apps' multifamily classification. We selected four more common collections as experimental objects: classes. dex file, class name collection, application interface (API) call collection, and customized malicious features. We performed color visualization on each feature and conducted classification experiments, using the deep learning method to study the performance of the three features in classification time and accuracy.
Related Work Android malicious App visualization is a new trend in recent years. One of the common methods for the visualization of binary files comes from the paper by Conti et al. [17]. They used four different ways to visualize binary files. The first method is to draw each byte linearly to generate grayscale images, where empty bytes are described as black pixels and the 0xff bytes are described as white pixels. The second method is to color a portion of the bytecode to indicate the presence or absence of a particular byte value. This method is especially useful for finding compressed portions or ascii code portions. Third, the traditional hex editor is implemented, which converts the binary to hexadecimal and then colors it. Fourth, using dot plots to show the cross-entropy of a file, a dot plot is a way to visualize the similarity or self-similarity of data.
In the exploration of malware visualization, Gennissen et al. [18]  used a partial color visualization method to study Android malicious family classification. Zhang et al. [19]  decompiled the executable file to get the opcode sequence and then converted these sequences into the form of an image and finally performed further feature extraction and recognition through CNN. They did not characterize the executable file and directly used all the data, which may lead to false positives in model identification. Kancherla and Mukkamala  [20]  converted the executable files to grayscale images and then selected the model based on the intensity and texture-based feature selection for malware recognition. Grayscale images retain fewer features than color images, 2 Wireless Communications and Mobile Computing which can reduce the accuracy of malware identification.
Crowdroid  [9]  used dynamic analysis to extract API (App Programming Interface) calls as features and K-means clustering to detect malware. RiskRanker  [10]  classified Apps into high risk, medium risk, and low risk to judge malicious Apps. We find that there are few papers focusing on family classification. In researches of multifamily classification, DroidLegacy  [11]  focused on the part of malicious families using piggybacking technology to embed malicious code in benign Apps during repackaging; however, this type of malware is not representative of all malware. Dendroid  [22]  used text mining technology and data flow characteristics to construct a malicious family detection system based on App code structure analysis. It classified 33 families and achieved good results. However, no further research has been done on more families.
In the face of the endless stream of Android malicious App families, how to implement a family classification for most common malicious Apps becomes a problem: as the number of malicious families increases, the malicious behaviors of different families overlap  [12]. Different malware families with higher malicious similarity are more difficult to distinguish, and the accuracy of the classifier will also decrease. Due to the lack of reliable manual annotation datasets, some papers use labeled data for a large number of family classification experiments; nevertheless, the results obtained are often questionable. RevealDroid  [13]  used the classification regression tree algorithm, combined with packet-level and method-level API calls, reflections, and native code at package and method levels as features, and it successfully classified 33 families on AMC datasets.
Finally, in the "last propagation" stage, malicious Apps may use infected mobile phones to send links or emails, alluring unaware friends to download them to click on or download Apps, so as to achieve the purpose of dissemination of malicious Apps. Generally speaking, an App can be judged as malicious if it has the following behaviors  [14]   (6)  GinMaster: gain access by rooting the devices, thereby steal sensitive user information and send it to the server, and install other software without the user's permission  (7)  Kmin: send the IMEI information of the device to the remote server. At the same time, they will further threaten the security of the mobile phone by calling according to the remote command and blocking the short message from the operator, which will consume a lot of money  (8)  BaseBridge: are similar to the Kmin family, but they can kill antivirus software processes running in the background  (9)  Adrd: are similar to the Geinimi, but they can change the settings of mobile phones  (10)  DroidDream: get information through rooting mobile devices, download malicious Apps silently in the background, usually run at night while the device is charging in order to avoid the monitoring of power consumption by the detection software In addition, there are many other malicious App families, such as the Nickyspy family: record dial-in and dial-out information for infected mobile phones, record user's GPS information, and send text messages to other numbers; Zsone family: automatically send text messages to subscribe for paid content, thus achieving the purpose of consuming telephone charges; Obad family: elevate system privilege to prevent being uninstalled and send text messages to valueadded service numbers for profit; and Zitmo family: steal verification code sent from the bank.
Our Approach 4. 1. Select Features. The size of different Android Apps varies widely. If the entire App file is visualized, the visualized image sizes may differ by hundreds of times, which will bring a huge burden to the classification task of the images. Therefore, we need to select the features that can represent the behavior of the App and then perform color visualization. In the internal structure of an Android App, in addition to the dex file that stores the code and the AndroidManifest. xml file that stores the configuration information, there is res directory that stores resource files such as image files and audio files. This part of the file has nothing to do with the code logic of the App; it is only stored as a resource of the App and does not affect the behaviors of the program.
A small number of malicious Apps may hide malicious code in image files. Such Apps are beyond the scope of this paper, so the resource file is not included in the selection of visualization features. The basis for our classification of malicious App families is that each Android App has a different performance in classes. dex and AndroidManifest. xml, which reflects different characteristics and behaviors to distinguish malicious programs from different families  [11, 24, 25]. classes. dex is a bytecode file that compiles Java files into classes and saves them; it contains the package name, classes, methods, variables, and application interfaces (APIs) of the Android App. Most of the App's functional behaviors are implemented based on APIs, so we choose it as one of its features. Every activity component, service component, content provider component, and broadcast receiver component in the Android App need to be registered in the AndroidManifest.
xml file. In addition, it also contains some permissions and SDK information. So it is part of the features. If we want to better identify the malicious family to which certain malware belongs, we need to understand the malicious behavior of different malware families. For this purpose, we selected Apps from ten malicious families for manual analysis (FakeInstaller, DroidKungFu, Plankton, Opfake, GinMaster, Iconosys, Kmin, FakeDoc, Geinimi, and GoldDream). Figure  1  shows malicious code from an App of FakeInstaller family in AMD  [26]  (the complete analysis process is in Appendix A). The fifth line in the code shows that the App obtains the sensitive unique identification number of the victim's mobile phone. It can be seen from the code between lines 13 and 25 that the App will also intercept the incoming calls of the victim's mobile phone.
TF-IDF i = TF i * IDF i , ð1Þ TF i z = n i z ∑ N k=1 n k z | z ∈ 1, ⋯, 10 ð Þ , i = 1, ⋯, N ( ) , ð2Þ IDF i = log D W i + 1 : ð3Þ 4 Wireless Communications and Mobile Computing  4. 2. 1. Decompression. As described above, in order to get the features of the App, we need to decompress the Apk file. After decompression, we get the files including classes. dex and AndroidManifest. xml. 4. 2. 2. Feature Extraction. We use the androguard  [27]  to reverse the classes. dex file and build the control flow graph (CFG) of the App. As shown in Algorithm 1, we assume that the feature set is R. r i in formula (4) includes features of a feature category cat j ; cat j indicates which of the 5 feature categories it belongs to. p i means the permission. pkg i indicates the package name, m i indicates the method, cmd i indicates the instruction, and flow i indicates the mailicious call flow.
Dataset. In order to verify the effectiveness of our model in Apps' multiclassification, we selected 7000 benign Apps from Google Play  [29]  and 7204 malware Apps in 10 families from DREBIN  [25] , AMD  [26] , and VirusTotal (VT)  [30]. The details are shown in Table  3. In our experiment, we mainly use DREBIN Apps in the training process and use AMD and VT Apps in the verification process. In our experiments, we also selected an available tool for comparison, but it only supports to judge whether the App is malicious or benign. For this situation, we selected the following evaluation metrics: True Positive (TP). The true category of the App is malicious, and the results predicted by the model are also malicious. True Negative (TN). The true category of the App is benign, and the model predicts that it is benign.
Color Visualization of APIs. We use the API call sequence as a visual feature input. APIs can better reflect the internal logical structure of the Android App, which has a positive impact on the improvement of classification accuracy. Due to the need to analyze the internal code structure of the Android App, it takes slightly more time than simply extracting the App class name. The color visualization image of the API call sequence is shown in Figure  13. Accuracy. The classification results are shown in Figure  14. The classification result using the API sequence as the input of visualization can reach 98%. The occasional accuracy fluctuations in the figure may be due to the increase in similarity of different Apps to a certain extent due to the third-party libraries.
Answering RQ3: Multiclassification of Color Images Using Different DL Models. There are already many mature models in the field of image recognition. In order to select a model that is more suitable for solving our problems, we use CNN  [33]  and ResNet  [28]  for comparative experiments. For CNN, we use 5-layer network structures and use ReLU as the activation function for training. For ResNet, we set 20layer network structures. We select 10 malicious Apps' families as the dataset. For features for color virtualization, we select all APIs and customized features. Figure  17  shows the results of a CNN classification experiment by using customized features. The accuracy of classification can reach 76. 68%. Since the loss function values are all greater than 1, they are not shown in the figure.
13 Wireless Communications and Mobile Computing effective. In order to further verify the practicability of our method, we select 20 families of Apps from DREBIN  [25]  and AMD  [26]. We divide the dataset into a training set and a test set according to the ratio of 8 to 2. The model is ResNet. The results are shown in Table  6. It can be seen from the results that, for the expansion of the malicious App families, our proposed classifier still performs well in the detailed malicious App family identification; the best accuracy can reach 95. 7%. The reason for the low accuracy of Geinimi may be that during the evolution of Apps of this family, Apps are adulterated with other malicious behaviors.
We find the main activity of the v. v. v. mainactivity. As shown in Listing 1, in the onCreate method, we find that the App has behaviors: getting the current time, getting the IMEI of the device, and hiding the App icon. If the current time is earlier than 2016. 11. 29, it will execute the code in line 6. It will hide the App icon and start a customized service named xservicr. In the onCreate method of the xservicr service, we find that the App has registered the SMS listener, as shown in Listing 3. In the a method of line 9 in Listing 1, its code is shown in Listing 2. The App tries to obtain device manager permission through implicit intent. We find the customized class PAReceiver; the code is shown in Listing 4. There is an ondisablerequested method in this class; this method will be called automatically when the user tries to cancel "Activate Device Manager.
" If users cancel the activation, the App will send a text message containing "Fish trying to escape" to the attacker, and the attacker's phone number is exposed. As shown in Listing 5, we find in the class c of the package love. qin. co/service. dggng that the App sets call forwarding. So, it has malicious behaviors such as call interception, SMS forwarding, and getting contacts. In the class TelIntenral of love. qin. co. service package, as shown in Listing 6, we find the implementation of call forwarding. If the device is not in the dialing state and there is an incoming call, the ringtone is set to mute, and then, the incoming call will be dialed to the attacker. The classc of love. qin. co. service of the App sends messages to all contacts of the victim as shown in Listing 7. Based on the above analysis, it can be seen that the malicious App tries to obtain the administrator authority of the mobile device.
Acknowledgments Thank you VirusTotal (VT) [29] for providing us with Apps. This work was supported in part by the  National Key R&D Program of China  under Grant No. 2018YFB0804703. This article is a version with extension on the basis of the paper accepted by  SPNCE 2020  (https://www. google. com/url?q=https://spnce. eai-conferences. org/2020/accepted-papers/&sa=D&source=hangouts&ust=1604211194010000&usg= AFQjCNF8oiTapedWDv8qsGSdYvXewRs5dQ).
After removing the aerial plant tissue, 150 L of water were flowed over the soil-root blocks for a All results in the table are comparisons to wild type using ANOVA. Dashes indicate no significant difference and N/A indicates data could not be collected. Lateral root length, lateral root count and vertical angle from the root system were also measured on gel and had no significant difference from wild type. Root hairs on gel were images under magnification with dark field lighting. Photographs of whole root systems in gel were analysed with a combination of ImageJ  46  and Root Nav  61. Root hair counts in soil were performed on 1-mm-long root sections from CT images such as those in Fig. 1. maximum of 110 s to simulate an overland flow event (Fig. 4a ). RLD ranged between 3-56, 8-48 and 5-34 km m -3 for wild type, cpc try and wer myb23, respectively, which correspond with topsoil RLD ranges (1-45 km m -3 ) of six common cover crop species measured in field conditions  23.
Plates were placed inverted into a hanging basket centrifuge (Beckman Coulter Allegra X-30R Centrifuge) and subjected to 1-min incremental increases in centrifugal force of 720, 1018, 1247, 1440 and 1611 RPM (100, 200, 300, 400 and 500 × g). The proportion of seedlings that detached from the gel surface was determined between each speed. Data were collected for 87 wild type (Col-0), 87 wer myb23, 91 35S::RSL4, 94 rsl4 and 88 cpc try seedlings. We report the results of a single experiment, which are representative of at least two independent experiments. Calculations and statistics for the gel adhesion assay. We determined the perpendicular plane of rotation of the hanging buckets within the enclosed centrifuge mathematically. The bucket is attached 70 mm from the axis of rotation, which also corresponds approximately to the surface of the gel in the plate and is free to swing about the axis.
Hence, the seedlings experience a centrifugal force that can peel them away from the gel. The maximum force resisted by the seedlings was used as a measure of root-gel adhesion. The angular velocity (ω) and diameter of the centrifuge (i. e. the distance between the seedling and the axis of rotation =70 mm and the aerial tissue weight of each seedling were used to calculate the maximal centrifugal force (Fc (kg m s -2 )) that was experienced by each seedling (mass, Ms (kg)) at each centrifugal speed: Fc ¼ Ms radius ω 2 : ð2Þ We applied a Cox hazard function regression model  22  to statistically test for differences between the risk of detachment for each root hair mutant relative to wild type. We set up a priori contrasts and used the coxph function with exact treatment of ties within the survival package in R  36.
The dry weights of these roots were used to determine plant RLDs by converting the root masses into root lengths using specific root length (i. e. root length per unit mass) values for each genotype. To obtain root specific length values, at least 10 m of root per genotype from at least three representative plants were separated into single strands on a high contrast background, photographed, measured in ImageJ  46  , dried and weighed. The root specific length values (m mg -1 root ± 1 standard deviation) for wild type, cpc try and wer myb23 were 0. 63 ± 0. 04, 0. 43 ± 0. 07 and 1. 02 ± 0. 31 m mg -1 in clay soil and 0. 51 ± 0. 03, 0. 39 ± 0. 02 and 0. 53 ± 0. 02 m mg -1 in compost, respectively. Uprooting data were analysed with a linear modelling framework that used the lm() function in 'R' (3.
Plants were grown in sieved clay-loam soil (dry soil bulk density 1. 07-1. 27 g cm -3 ) in boxes with inner dimensions 250 × 250 × 150 mm fitted with a weed suppression mat. Different plant densities of 9, 16, 32, 49, 81 and 100 plants in each box box (i. e. a plant density range of 144-1600 plants m -2 ) were established, which corresponded to shoot densities between 0. 15 and 2. 37, 0. 37 and 1. 72, and 0. 57 and 2. 66 kg m -2 for wild type, cpc try and wer myb23, respectively. All boxes were tested for erosion resistance at the same developmental stage after about 5 weeks growth (i. e. shortly after bolting). Data were collected from 18 boxes with wild-type roots, 17 with cpc try roots or 27 with wer myb23 roots. Immediately prior to erosion, the boxes were saturated by capillary rise, photographed and the aerial tissue and weed mats were removed.
7, and sealed with Parafilm (Bemis, NA). Plates were incubated vertically for 10-11 days, when the root tips of wild-type plants reached within 1 cm of the bottom of the plate. For each genotype, 20 single seeded plates and 5 plates with 5 seeds were used to measure and compare the growth of single and grouped plants. Each set was compared with a wild-type control. 'Root depth' was the vertical distance the root tip had progressed down the plate. Root-hair counts were taken using dark field lighting on a Leica MZ FLIII microscope. A Nikon D50 camera with a polarising filter and SPOT image capture software (SPOTIMAGING) was used to capture microscope images. Image analysis was conducted with a combination of ImageJ  42  and RootNav software  61. Plants for X-raying were grown in 200 μl pipette tips filled with sieved clay soil for 5-7 days.