Lamine Noureddine
email: lamine.noureddine@inria.fr

Annelie Heuser
email: annelie.heuser@irisa.fr

Cassius Puodzius
email: cassius.puodzius@inria.fr

Olivier Zendra
email: olivier.zendra@inria.fr

SE-PAC: A Self-Evolving PAcker Classifier against rapid packers evolution

Keywords: Packers, Malware obfuscation, Features combination, Classification, Clustering, Novelty detection, Incremental learning

Packers are widespread tools used by malware authors to hinder static malware detection and analysis. Identifying the packer used to pack a malware is essential to properly unpack and analyze the malware, be it manually or automatically. While many wellknown packers are used, there is a growing trend for new custom packers that make malware analysis and detection harder. Research works have been very effective in identifying known packers or their variants, with signature-based, supervised machine learning or similarity-based techniques. However, identifying new packer classes remains an open problem.

This paper presents a self-evolving packer classifier that provides an effective, incremental, and robust solution to cope with the rapid evolution of packers. We propose a composite pairwise distance metric combining different types of packer features. We derive an incremental clustering approach able to identify both (variants of) known packer classes and new ones, as well as to update clusters automatically and efficiently. Our system thus continuously enhances, integrates, adapts and evolves packer knowledge. Moreover, to optimize post clustering packer processing costs, we introduce a new post clustering strategy for selecting small subsets of relevant samples from the clusters. Our approach effectiveness and timeresilience are assessed with: 1) a real-world malware feed dataset composed of 16k packed binaries, comprising 29 unique packers, and 2) a synthetic dataset composed of 19k manually crafted packed binaries, comprising 31 unique packers (including custom ones).

CCS CONCEPTS

• Security and privacy → Malware and its mitigation; • Computing methodologies → Machine learning approaches.

INTRODUCTION

Context. The malware (MW) ecosystem is evolving rapidly, with drastic changes in the frequency and composition of malware. This growing problem has high financial impact. Ransomware damage alone cost more than $5 billion USD in 2017 and was estimated to reach $20 billion USD by 2021, an increment of 400% compared to 2017 and 5700% to 2015 [START_REF] Morgan | Global Ransomware Damage Costs Predicted To Reach $20 Billion (USD) By[END_REF].

Effective MW detection and analysis is thus crucial for users and security systems. They can be implemented with analysis techniques that are either static or dynamic. Static analyses examine a binary directly, by disassembly or measuring syntactic properties, with no execution. Dynamic analyses require executing the binary, e.g. in a virtual sandbox environment.

To defeat these analyses, MW authors employ different obfuscation techniques. In particular, they use packers to hinder static analysis by increasing the difficulty to reverse engineer the binaries, which entails higher analysis costs for MW analysts. Packing consists in compressing and encrypting binary data, to produce a new binary that is syntactically different from the original one. Thus unpacking is essential to verify if packed binaries are malicious.

New unknown packers complicate unpacking, since the specific required unpacking function is unknown and generic unpackers are not always effective [START_REF] Biondi | Effective, efficient, and robust packing detection and classification[END_REF], which makes MW detection and analysis harder. So beside the many well-known packers in use (e.g. UPX, NsPack, ASPack), there is a growing trend for custom packers. The latter are developed either from scratch or partially from available ones (e.g. Vanilla UPX). Their usage has become so widespread that by 2015 Symantec detected their use in over 83% of MW attacks [START_REF] Prasad | Cloak and Dagger: Unpacking Hidden Malware Attacks[END_REF]. Research works have also followed this evolution [START_REF] Ugarte-Pedrero | SoK: Deep packer inspection: A longitudinal study of the complexity of run-time packers[END_REF].

The detection of new packers using supervised Machine Learning (ML) techniques has shown promising results [START_REF] Biondi | Effective, efficient, and robust packing detection and classification[END_REF]. It is a binary (packed or non-packed) classification problem and uses large labeled datasets containing a variety of packers to train ML models. However, classifying new packers into families with supervised ML can be unfeasible or unreliable. Indeed, when a packer is just a modified variant of a packer (class) used for training, Supervised Learning (SL) can classify it as related to an existing class; but when the packer (class) is totally new, SL techniques fail. This misclassification can lead to a significant increase in the unpacking costs, and create a dataset pollution problem if the wrong predicted labels were then used for (re-)training, which would result in false positives should the signature tools be updated accordingly.

Challenges and Difficulties. Packers evolve as rapidly as MW, constantly bringing new classes or new variants of existing ones [START_REF] Ugarte-Pedrero | SoK: Deep packer inspection: A longitudinal study of the complexity of run-time packers[END_REF].

To build an effective MW analysis and detection system, it is thus essential to keep the packer classification system updated. But identifying new packers is difficult, be it manually or automatically. Manual reverse engineering is unfeasible in practice as the number of MW instances grows exponentially. Automatic techniques like signatures-based tools and supervised classification systems cannot properly detect class novelty. And although generic unpacking may identify the underlying packer, it may fail if the packer is totally new. Thus, a crucial challenge is to propose an update system able to automatically and effectively identify new packer classes.

Updating the system often consists in retraining from scratch, thus rebuilding the whole model. The drawback of this approach is that at each retraining the knowledge from the previous existing model is omitted. Hence another important challenge is to derive an incremental approach where knowledge is constantly enhanced, integrated, adapted and evolved. Such a system would eventually lose effectiveness, thus requiring supervisor intervention to completely retrain. But full retraining is very costly, so achieving high robustness (i.e. time-resilience) is crucial to maximize the lifespan of our model, minimize costs and maximize user security.

In this paper, we present a self-evolving packer classifier that provides an effective, incremental, and robust solution to cope with the rapid evolution of packers. Our self-evolving technique consists in predicting incoming packers by assigning them to the most likely clusters, and relies on these predictions to automatically update clusters, reshaping them and/or creating new ones. Thus our system continuously learns from incoming packers, adapting its clustering to packers evolution over time. Note that the packer detection problem (packed, non-packed) is out of the scope of this paper. Our work focuses on packer families classification.

Our main contributions are:

• We point out and experimentally show the importance of constantly updating the packing classification system. • We show how to combine different types of features in the construction of a composite pairwise distance metric, in the context of packed binaries. • To decrease the update time for the incremental clustering procedure, we derive a methodology to extract representative samples for each cluster. Interestingly, the number of representatives extracted from each cluster is not fixed, but related to the number of samples in the cluster. We furthermore study this relation experimentally, to derive a good trade-off between effectiveness and update time performance. This paper is structured as follows. Sec. 2 recalls useful background material, and Section 3 related work. Section 4 presents our methodology and Section 5 our post clustering selection strategy. Section 6 details the datasets and ground truth, and Section 7 the evaluation metrics. Section 8 presents the experimental setup and results, which Section 9 discusses. Section 10 concludes.

BACKGROUND

This section provides background on packers usage, their impact on a MW analysis workflow, and a brief overview on clustering.

Usage of Packers in Malware

Packers were designed to fulfill either or both goals of size reduction and protection against reverse engineering [START_REF] Sikorski | Practical Malware Analysis: The Hands-On Guide to Dissecting Malicious Software[END_REF]. Binary packing takes a target binary (called payload) as input and generates a new binary that embeds the original in a packed, "scrambled" form, together with an unpacking routine (unpacking stub) that can unpack and execute the original binary in memory. Packers are also called runtime packers and sometimes self-extracting executables.

For MW detection, the main challenge to analyse an unknown packed binary is to determine whether the payload is malicious or benign (using packing for legitimate purposes, e.g. software integrity protection). This analysis is only possible after partial or complete unpacking of the sample (see Sec. 2.2). Classical signaturebased antiviruses (AVs) that heavily rely on syntactical properties and cannot unpack are thus ineffective against packing. So a special concern for MW packers is to alter the syntactic properties of the different instances (i.e. variants) generated from the same MW (family) in order to better defeat AVs. Polymorphic codes take different forms at each instance generation (e.g. using encryption). Metamorphic codes rewrite themselves at each execution [START_REF] Li | Mechanisms of polymorphic and metamorphic viruses[END_REF].

The protection features sought by MW developers include many different techniques for anti-debugging, anti-disassembly, obfuscation and anti-VM [START_REF] Sikorski | Practical Malware Analysis: The Hands-On Guide to Dissecting Malicious Software[END_REF]. Various packers will support various protection features. In particular, these anti-analysis features can additionally comprise: multilayer packing, interleaved execution of unpacking and the original program, shifting decode frames, etc. This is referred as the complexity of the packer in [START_REF] Ugarte-Pedrero | SoK: Deep packer inspection: A longitudinal study of the complexity of run-time packers[END_REF], which proposes to rank packers with a taxonomy including six increasing complexity classes (I to VI) based on the increasing difficulty to unpack the binary, gauged relatively to the multiple anti-analysis techniques that are added to the unpacking stub routine.

In-depth Scanning

To determine whether a binary sample is malicious, an AV needs to analyze its characteristics. If the AV determines that the sample is packed, a payload extraction is attempted before proceeding with the MW analysis. This is called in-depth scanning [1] (see Fig. 1).

The analysis pipeline starts with very lightweight syntactic operations, and may go on with more robust and expensive interventions. If the sample is found to be packed, payload extraction is attempted by a specialized or a generalized unpacker [START_REF] Martignoni | Omniunpack: Fast, generic, and safe unpacking of malware[END_REF]. Specialized unpackers are lightweight but require correct prior identification of the packer (and sometimes version). Generalized unpackers are intended to handle various packing algorithms, but are more costly, for lower success rates. Therefore, a correct classification of the packer (and version) is crucial for a good, cost-effective in-depth scanning, by deciding whether a specialized unpacker can be tried before a generalized unpacker. The classification process must also be efficient, to add limited overhead in the analysis workflow.

Clustering

Clustering is the task of dividing a set of elements in subsets (clusters) following some criterion. The elements can be treated individually (incremental clustering method) or they can be processed in batches (batch clustering method) [START_REF] Ackerman | Incremental clustering: The case for extra clusters[END_REF]. While the batch method attempts to capture the underlying structure of the elements in a compact and efficient way, the incremental method suits the scenario where new data continually arrive and recomputing the clusters from scratch becomes infeasible due to the volume of data. In particular, incremental clustering allows incremental learning, where knowledge is enhanced, integrated, adapted and evolved.

In practice, many clustering algorithms exist. They can be primarily categorized into prototype-based, hierarchical-based or densitybased [START_REF] Pn Tan | Chapter 8 Cluster analysis: basic concepts and algorithms[END_REF]. The latter have the particularity of not being sensitive to noise and can deal with different cluster sizes and different cluster shapes. DBSCAN [START_REF] Ester | A densitybased algorithm for discovering clusters in large spatial databases with noise[END_REF] is a typical density-based clustering algorithm widely used in many applications.

Finally, clustering can be evaluated by intrinsic or extrinsic metrics. Intrinsic metrics evaluate with some distance metric whether the elements in the same cluster are close while the elements in different clusters are distant. Extrinsic metrics evaluate the quality of a clustering by comparing it against a ground truth, also called gold standard, that represents the expected clustering.

RELATED WORK

Packer classification has been moderately tackled in literature. Most studied techniques rely on syntactic signatures, ML, or similarity.

Syntactic signatures are sequences of bytes that characterize a specific packer. Tools like PEiD [START_REF] Sconzo | Packerid[END_REF], Yara [START_REF]YARA[END_REF], and DIE [START_REF]Detect-It-Easy[END_REF] statically parse the packed binary and match it against a signature database. Since they rely on priorly generated rules, they are unable to detect new or sometimes slightly modified packers. Furthermore, these tools often need to be manually updated by an analyst who writes signatures as new packers are manually reverse-engineered. This is extremely costly in practice, given the tremendous number of new MW appearing every day, which increases the time during which new packers remain undetected by these tools.

More advanced approaches use ML techniques to classify packers. SL is the most prevalent technique in literature [START_REF] Biondi | Effective, efficient, and robust packing detection and classification[END_REF][START_REF] Kancherla | Packer identification using Byte plot and Markov plot[END_REF][START_REF] Sun | Pattern recognition techniques for the classification of malware packers[END_REF][START_REF] Zhang | Sensitive system calls based packed malware variants detection using principal component initialized MultiLayers neural networks[END_REF]. In SL, the ML algorithms build a classifier model by learning from a set of (syntactic or behavioral) features extracted from packed binaries, and from the corresponding labels provided as ground truth. This packer classifier model is then used to classify unlabeled packed binaries. SL performs well on packers belonging to classes for which the ML model was trained ( [START_REF] Biondi | Effective, efficient, and robust packing detection and classification[END_REF] achieved an F-score up to 0.9999 on more than 280k samples). However, it fails to recognize new packer classes, that were not present during training.

Other works [START_REF] Bat-Erdene | Entropy analysis to classify unknown packing algorithms for malware detection[END_REF][START_REF] Nguyen | Packer identification based on metadata signature[END_REF][START_REF] Li | A consistently-executing graph-based approach for malware packer identification[END_REF][START_REF] Saleh | A control flow graphbased signature for packer identification[END_REF][START_REF] Sconzo | I am packer and so can you[END_REF] extracted signatures from the unpacking stub code (see Sec. 2.1), then a similarity metric regroups packers into families. An unknown packed sample is classified by computing its distances to a referential of packer classes. This approach quantifies the similarity wrt. a referential of signatures, unlike traditional signature-based approaches that hinge on direct matching unable to capture small differences. The authors of [START_REF] Saleh | A control flow graphbased signature for packer identification[END_REF] claim their system can identify new packer classes, but do not validate it experimentally. In [START_REF] Nguyen | Packer identification based on metadata signature[END_REF], new custom packers are correctly classified only if the packer uses a set of well-known obfuscation techniques. Works [START_REF] Bat-Erdene | Entropy analysis to classify unknown packing algorithms for malware detection[END_REF][START_REF] Li | A consistently-executing graph-based approach for malware packer identification[END_REF][START_REF] Saleh | A control flow graphbased signature for packer identification[END_REF] can identify new packer classes, but rely on pairwise similarities, while we rely on clustering that adapts itself to packers evolution. Like us, [START_REF] Li | A consistently-executing graph-based approach for malware packer identification[END_REF] analyze a large dataset of manually and wild packed files, while [START_REF] Bat-Erdene | Entropy analysis to classify unknown packing algorithms for malware detection[END_REF][START_REF] Saleh | A control flow graphbased signature for packer identification[END_REF] study smaller datasets. Feature extraction in [START_REF] Li | A consistently-executing graph-based approach for malware packer identification[END_REF][START_REF] Saleh | A control flow graphbased signature for packer identification[END_REF] uses recursive traversal disassembly and [START_REF] Bat-Erdene | Entropy analysis to classify unknown packing algorithms for malware detection[END_REF] requires full execution with multiple entropy measurements, whose cost can be prohibitive in our clustering scenario.

Our work is the first we know of that provides a methodology relying on clustering to tackle rapid packers evolution. Moreover, we construct a robust pairwise distance metric that combines dynamically extracted unpacking stub assembly language (ASM) signatures, and a set of statically extracted structural features from the Windows Portable Executable (PE) packed files. This combination is more robust against obfuscation techniques and avoids ML overfitting. Finally, our post clustering selection strategy is new, and provides for each cluster a small subset of relevant samples that can undergo deeper and more costly analyses whose results can be extended to all samples in the cluster.

METHODOLOGY

This section starts with a brief overview of the methodology for our self-evolving classifier, before exploring each part in more details.

Overall Toolchain

Our approach comprises two phases (see Fig. 2). First, the offline phase exploits and models all available knowledge, by using available packed (binary) samples as well as packer labels to tailor the generation of clusters. In the second phase, the online phase, the system self-evolves by incrementally updating the clusters as new samples, packed with either previously seen or unseen packers, are processed. Both phases are divided into three main steps: feature extraction, distance computation and clustering. Feature extraction and distance computation are identical for the offline and online phase, whereas clustering differs notably. Joining supervised learning in the offline phase and unsupervised learning in the online phase makes the whole system learn in a semi-supervised method.

We rely on clustering because it can efficiently cluster similar samples that belong to the same packer family, regardless whether Initially, at t 0 , the offline phase trains the self-evolving packer classifier and tunes parameters that will be used in the online phase. The initial dataset contains packed samples and the corresponding ground truth labels. Various static and dynamic features are extracted from each packed sample, to represent it by a heterogeneous features set. To define a unique pairwise distance for pairs of packed samples, each individual feature yields a partial distance metric that is averaged with all the others to obtain the final distance. Clustering is then used to group similar packed samples into clusters. The best clustering is found by tweaking the distance between packed samples according to the ground truth, so that the obtained clustering combines homogeneity (clusters do not mix packers from different families) with the most coherent number of clusters (the closest to the number of packer families in the ground truth). At the end of this phase, the parameters that produce the best clustering, as well as the corresponding clusters, are the first clustering setup which serves as baseline for the second phase.

The online phase (t 1 , ..., t n ) has successive self-evolutions, processing one packed sample at a time, for as long as the model produces accurate results before requiring full retrain or supervisor intervention. In this phase, the same tasks are repeated for features extraction and distances computation. Then starting with the clustering setup obtained from the offline phase, the system self-evolves by relying on incremental clustering that dynamically includes the incoming packed samples, thus creating new clusters for new families and reshaping existing clusters with new variants. Since our system classifies new incoming packed samples in real-time, it can be used in production, hence reinforcing the security of the user.

Features Extraction

We extract 6 groups of packer features chosen according to state-ofthe-art [START_REF] Biondi | Effective, efficient, and robust packing detection and classification[END_REF]: metadata (21 features), sections (21 features), entropies (6 features), resources (2 features), import functions (5 features), unpacking stub mnemonic sequences (1 feature). A selection is done by testing all the possible non-repetitive group combinations. The most effective one is sections associated to the unpacking stub mnemonic sequences. This combination provides effectiveness as well as robustness against obfuscation techniques that can deceive each group taken separately. It also reduces ML over-fitting.

4.2.1

Unpacking stub mnemonic sequences. We perform a lightweight dynamic emulation of the first instructions that follow the binary Entry Point (EP). As instructions are fetched, the corresponding mnemonics1 are stored in a list, which is the mnemonic sequence feature. The rational is that runtime packers often start executing the unpacking stub routine before reaching the malicious payload Original EP (OEP); so the unpacking stub code can be a characteristic feature [START_REF] Nguyen | Packer identification based on metadata signature[END_REF][START_REF] Li | A consistently-executing graph-based approach for malware packer identification[END_REF][START_REF] Saleh | A control flow graphbased signature for packer identification[END_REF][START_REF] Sconzo | I am packer and so can you[END_REF]. Dynamic emulation has the advantage to thwart unpacking stub codes that use obfuscation techniques to impede static analysis, such as anti-disassembly and metamorphism (see Sec. 2.1). Furthermore, although an attacker can engineer a bunch of code protection that foreruns the unpacking code routine, this would not mislead our step since this bunch of code protection would serve as well to identify the packer.

PE sections.

By changing the program structure, packers introduce many artifacts into the sections of the binary. In this work, we extract 21 state-of-the-art features [START_REF] Biondi | Effective, efficient, and robust packing detection and classification[END_REF] related to sections:

Ten integer features representing the number of sections of the PE packed file that are: standard/non-standard; executable/writable/readable (and combinations); have raw data size zero; have different virtual and raw data sizes.

Seven boolean features: .text section not executable; a non-.text section is executable; .text section not present; EP not in .text or .tls section; EP not in a standard section; EP not in an executable section; and address not matching file alignment, Four ratio based features: ratio of standard sections to all sections; ratio between raw data and virtual size of the section containing the EP; maximum ratio of raw data to virtual size; and minimum ratio of raw data to virtual size.

Composite Pairwise Distance Metric

Since extracted features are numeric (relating to PE sections) or string sequences (mnemonic sequences), we need to derive a unique pairwise distance metric able to combine both types. To this end, we apply a Gower distance [START_REF] John | A general coefficient of similarity and some of its properties[END_REF], a composite metric overcoming the issue of mixed data type variables by being computed as the average of partial distances that range in [0, 1]. Our work has two different partial distance metrics: Manhattan distance for numeric features and Tappered Levenshtein distance for mnemonic sequences. These two distances are then normalized, and their average computed, thus providing our composite distance metric. Formally:

Gower (i, j) = 1 p p k =1 NormD (f k ) i j
(1) i and j are the indices of two samples in the dataset, NormD

(f k )
i j is the normalized partial distance metric applied wrt. the data type of the k th feature f , and p is the number of features. Each packed sample is represented by 22 features (a string and 21 numbers).

The Manhattan distance provides partial distance metrics for numeric features. The normalized partial distance of a numeric feature f between two samples of indices i and j is the ratio between the absolute difference of observations x (f ) i and x (f ) j and the absolute maximum range R (f ) observed for f among all samples:

NormManh (f ) i j = |x (f ) i -x (f ) j | |R (f ) | (2)
The Tapered Levenshtein Distance provides partial distance metrics for ASM mnemonic sequences [START_REF] Sconzo | I am packer and so can you[END_REF]. It has the advantage of quantifying the similarities between two ASM mnemonic sequences, in contrast to straightforward comparison that cannot capture small differences in the sequence. Furthermore, the tapered version proportionally decreases the weight of each element as they appear later in the sequence, punishing more differences in the beginning of the sequence and less in the end. In our work, the intuition behind tapering is that most of the times the unpacking stub routine is located directly at the binary EP, and thus the order in which the instructions appear is important. Nonetheless, since the length of the unpacking stub is a priori unknown, the focus is to fetch as few instructions as possible to attain the optimal balance between efficiency and information gain for packer classification. The normalized partial distance of a string mnemonic sequence f between two packed samples i and j, is formally defined as:

NormT apLev (f ) i j = L (f ) (S i , S j ) -1 k =0 W (f ) (S i ,S j ) (k)(1 -k L (f ) (S i , S j ) ) C (3)
where S i and S j are the respective mnemonic sequences of the two packed samples whose indexes are i and j. L (f ) (S i ,S j ) is the maximum length between S i and S j . W (f ) (S i ,S j ) (k) is a factor which is equal to 0 if the ASM mnemonic of S i and S j are equal at the position k, or equal to 1 otherwise. Finally, C is the maximum length of mnemonic sequence extraction, used to normalize the distance into [0, 1].

Example 1. Let C be set to 50, and S i and S j the following ASM mnemonic sequences, extracted from packed samples i and j: S i = {push, mov, push, push, push, mov, push, mov, sub}, S j = {push, mov, mov, push, add, mov, add, mov, sub},

then L (f ) (S i ,S j ) = 9 and NormT apLev (f ) i j = 0 + 0 + (1 -(2/9)) + 0 + (1 -(4/9)) + 0 + (1 -(6/9)) + 0 + 0 = 1.67/50 = 0.033

Clustering: Batch and Incremental

In both offline and online phases we use DBSCAN [START_REF] Ester | A densitybased algorithm for discovering clusters in large spatial databases with noise[END_REF] as clustering algorithm, because it: (i) does not require the a priori number of clusters, which fits our ambition of discovering new packers; (ii) can find arbitrarily-shaped clusters, since the packers may be different in terms of complexity (see Sec. 2.1), packing techniques, or how they overlay the binary; (iii) has the notion of noise, which can have multiple interpretations in our context: rare (singleton) packers, outliers, or packers using very sophisticated obfuscation techniques and thus hard to group under clusters; (iv) gives control on parameters (eps2 and minPts3 ), which allows parameter tuning in the offline phase.

Scattered representative points.

To ease locating the clusters in the hyperplane while reducing comparisons complexity during the incremental update process, we select for each cluster a subset of its points to represent its geometry. To this end, we target the most scattered points of the cluster, which we call Scattered Representative Points (SRPs), see Fig. 3.

Finding the most scattered points of a cluster is akin to the farthest neighbors traversal problem: given a set of N points, find the X points that are the farthest apart from each other. Heuristics exist in literature to solve this problem [START_REF] Erkut | A comparison of p-dispersion heuristics[END_REF]. In our work, we tradeoff between precision and performance, with a greedy approach : first take the two farthest points, then incrementally select points for which the sum of distances to the already selected points is the greatest, repeating this until a specific number of representative points (n r p ) have been selected. This n r p is equal to K √ N c , where N c is the number of elements of cluster c, K is a positive constant (that can be experimentally tuned), and . is the round up number. This means that each cluster has a different n r p , at least equal to 1, that grows dynamically with the number of elements of the cluster. 4.4.2 Clustering in the offline phase. In this phase, DBSCAN parameter (eps) is tuned to achieve the best clustering wrt. the provided ground truth. The clusters are evaluated according to their homogeneity and number wrt. the number of packer families classes in the ground truth. The trade-off between these two constraints is established via clustering metric AMI (see Sec. 7).

The intuition behind the offline phase is to derive a generalized eps that is learned from the already available labeled samples. This experimental eps should work for a big variety of packers and give the incremental clustering step the ability to handle new unseen packers, hence the importance of providing a well-varied packer training set at the beginning. In practice, this variety represents various packer complexities, and techniques, e.g. self-installers, cryptors, compressors, protectors and virtualizers.

Parameter minPts is left as supervisor choice for the desired minimum number of samples in clusters. Assuming that some unknown packers (families) can be spread with very few elements (e.g. only 3), the value of this parameter should be low so that our clustering encompasses small clusters (in addition to larger ones).

4.4.3

Incremental clustering in the online phase. The online phase is responsible for updating the existing clustering as new samples come in. To this end, we customize an incremental version of DBSCAN [START_REF] Symvoulidis | An Incremental DBSCAN approach in Python for real-time monitoring data[END_REF] including a specific update policy and a set of optimizations techniques. This update policy covers three cases, checked in the following order: A: The new sample joins the nearest cluster when at least minPts sample, including the new one, are within radius eps. B: A new cluster is formed when at least minPts unclassified samples (noise), including the new one, are within radius eps. C: The new sample remains unclassified when not A nor B. The idea to optimize the computations is to get gradually closer to the hyperplane region where the potential points for case A are located. Therefore, in the first step, we compute the distances to the set of SRPs of each cluster, as illustrated in Fig. 3, to find the nearest cluster. In the second step, we delimit the region of points around the nearest SRP for which distances have to be computed. By exploiting the triangle inequality, using the distances already computed between the nearest SRP and the points in the cluster, we identify the set of points that are certainly closer or further than eps from the new point. These points can thus be directly accepted or rejected (without distance computation) within the update policy. Then, only the remaining points (those we can not decide using the triangle inequality) would require distance computation.

If the new sample joins the nearest cluster (case A), the set of SRPs of the cluster may have to be updated. Such update, if performed frequently (e.g. at each cluster modification), would make the incremental process costly. Therefore, to be efficient while still capturing the evolving geometry of the cluster, we limit the update of SRPs to be recomputed only when n r p increases.

POST CLUSTERING SAMPLES SELECTION

After some amount of updates, an analyst may want to select a subset of relevant samples4 from a cluster for further packer analysis.

Our strategy consists in representing the cluster by multiple connected regions, from which we select what we call Post Clustering Relevant Samples (PCRS). The diameter of these regions is set up by the analyst and allows for quicker or more detailed view on the clusters. The selected samples are ranked according to their region density in order to provide a measure of their relevance in the cluster. We call this measure density marker.

Our PCRS selection strategy (see Fig. 4) assumes that any shape generated by DBSCAN consists of connected core points 5 . Core points that are close (within eps radius) are relatively similar. A core point can be selected to represent the points (including core points) comprised within its region. More precisely, for given a cluster C, for each of its core points P i our procedure visits, we identify the list |P k ∈ V}. At the end of the procedure, the cluster is represented by the list of visited core points V, for which samples with higher ρ r are more relevant for further analysis.

DATASETS AND GROUND TRUTH

In our experimentation, we rely on two datasets: a MW feed and a synthetic dataset. We detail the origin, the collection period and the ground truth construction for each dataset.

Malware Feed

This first dataset consists of real packed binaries selected from a MW feed (unpacked and packed MW binaries) from Feb. 2017 to Oct. 2017 provided by Cisco. As our contribution focuses on packers classification, we select from the feed the binaries for which there is a consensus on the packer family label in the packing detection tools (DIE, Yara, PEiD, and a Cisco proprietary tool) used to build the ground truth. A consensus is met when at least three of these tools agree on the packer family (regardless of the packer version). With this 3-consensus, we selected 16 159 binaries out of the whole feed dataset of 281 344 binaries. Although it discarded many potentially packed binaries, the 3-consensus provides a higher quality ground truth, hence higher reliability for training and evaluation. Table 1 summarizes selected packer families, as well as the packer version indicated by DIE to illustrate a possible version labeling.

The complexity classes (see Sec. 2.1) of most of these packers range from I to III, like more than 85% of the world-wide packers evaluated in [START_REF] Ugarte-Pedrero | SoK: Deep packer inspection: A longitudinal study of the complexity of run-time packers[END_REF]. This means our packers are quite representative in terms of complexity. They also use diverse packing techniques: self-installers, compressors, cryptors, protectors, virtualizers.

Synthetic Dataset

We created a second dataset of 18 798 packed binaries 6 . On a freshly installed 32-bit Windows 7, we collected 694 PE clean binaries mainly from the system 32 folder and packed them with 31 public, commercial, professional and custom packers. The fact these binaries are cleanware and not MW is not a problem, since we focus mainly on packers, which are not all malicious. Packers "Custom Packer i", i ∈ [1..10], come from public repository Github. Their families are not found by PEiD, Yara nor DIE. Although we could just use known packers (e.g. UPX, Armadillo) to simulate the arrival of new packer classes after training, these extra Custom Packers more concretely simulate the arrival of new packers. Indeed, in practice MW can simply be packed with a very recent custom packer, taking advantage of the relatively unknown packer class to evade MW detection systems before these are updated.

For all 31 packers default settings were used when packing the binaries. Packing failed in some cases because the binaries were too small to be packed, or their PE structure could not be modified. Table 2 summarizes the number of samples of each packer family and the version used. Github references are given for custom packers.

This dataset is quite representative as well, because the packers complexity classes range from I to III (except Armadillo that has the class IV [START_REF] Ugarte-Pedrero | SoK: Deep packer inspection: A longitudinal study of the complexity of run-time packers[END_REF]), and their packing techniques are quite different.

PERFORMANCE METRICS

Both extrinsic and intrinsic metrics are used to evaluate clusters.

Extrinsic Metrics

Our ground truth packed samples are labeled by their packer family. Each family comprises many variants (different versions in Table 1; this could also be different configurations or polymorphic instances).

Our feed dataset has no absolute ground truth, since labeling tools do not agree on versions. Variants may be far apart wrt. eps, so we do not punish a clustering procedure splitting a family into different clusters, provided sub-clusters contain elements of the same family. In this context, the homogeneity score indicates how much a cluster contains samples belonging to a single family (class). Let T be the ground truth classes, and C be the predicted clusters by the clustering algorithm, then the homogeneity score h is given by:

h = 1 -H (T |C)/H (T ) (4)
where H (•) is entropy and H (•|•) conditional entropy. h ∈ [0, 1], low values indicating low homogeneity. h does not punish dividing one class in smaller clusters, so high homogeneity is easy to achieve with a large number of clusters. h is 1 if every element is clustered into its own size-1 cluster, so we use this metric to evaluate our clustering homogeneity only, not its global extrinsic quality. The Normalized Mutual Information (N MI ) trades-off between homogeneity of clusters and their number. We use the Adjusted Mutual Information (AMI ), an adjusted-for-chance version of N MI highly recommended in the clustering literature [START_REF] Nguyen | Information theoretic measures for clusterings comparison: Variants, properties, normalization and correction for chance[END_REF], defined by:

AMI (T , C) = I (C,T ) -E[I (T , C)] H (C) * H (T ) -E[I (T , C)] (5)
where I (•) is the mutual information and E[•] is the expectation. AMI ∈ [0, 1], higher values indicate more homogeneous clusters and/or a number of clusters closer to the number of packers families in T . AMI is 1 when T and C are identical and 0 when any commonality is due to chance. This metric punishes clustering with large number of clusters, since such clustering has a high H (C).

Intrinsic Metrics

We use DBCV (Density-Based Clustering Validation) [START_REF] Moulavi | Density-based clustering validation[END_REF], that can validate arbitrarily-shaped clusters. This metric computes the density within a cluster (density sparseness), and the density between clusters (density separation). For a clustering C = {C i }, 1 ≤ i ≤ l:

DBCV (C) = l i=1 |C i | /|O | V c (C i ) (6)
where |O | is the number of samples, and V c (C i ) is the validity index of cluster C i , 1 ≤ i ≤ l, defined as:

V c (C i ) = min 1≤j ≤l, j i DSPC(C i , C j ) -DSC(C i ) max min 1≤j ≤l, j i DSPC(C i , C j ) , DSC(C i )
where

DSPC(C i , C j )

EXPERIMENTAL EVALUATION

This section starts with an overview of software and hardware implementations, then presents the experimental evaluation we performed on our offline and online phases, and the results obtained.

All experiments were performed in Python 3.6.8 on a server with four 14-core processors at 2GHz with 128 GB of RAM.

The selection of the most effective features groups combinations was based on the best AMI score obtained in the offline phase.

We used the framework Radare2 [START_REF]Radare2[END_REF] to emulate the unpacking code execution and get the trace of ASM mnemonic sequences. Execution is stopped when the ASM sequence length reaches 50 mnemonics, a tradeoff between relevant information (unpacking stub code) and cost of extraction. In [START_REF] Sconzo | I am packer and so can you[END_REF], up to 30 mnemonics are statically extracted. We slightly extended this length to 50 to improve the relevant information quality. The average time needed to extract the ASM sequence 0.23 second per sample.

We computed the PE sections features from the PE header of the packed file using a C++ PE parser able to handle (packed) MW samples [START_REF]PeLib[END_REF]. The average time needed to extract these features is 0.014 second per sample.

We largely modified the online implementation [START_REF] Symvoulidis | An Incremental DBSCAN approach in Python for real-time monitoring data[END_REF] of the incremental DBSCAN to fit our methodology. For the batch version of DBSCAN and the evaluations metrics, we used Scikit-learn [START_REF]scikit-learn: Machine Learning in Python[END_REF].

Scenarii Definition

The two datasets share common packers, but also have their own (see Tables 1 and2). So we designed two scenarii to exhibits the behavior of our system when facing the arrival of known packers as well as new, unknown ones: MF/S: we use the MW feed as training set in the offline phase, then the Synthetic dataset as test in the online phase. S/MF: we use the synthetic dataset as training set in the offline phase, then the MW feed as test in the online phase.

Offline Phase

This phase supervises the creation of clusters with each training set, given the ground truth, in each scenario. The goal is to fine-tune eps according to the AMI score, the best found eps will then be used all along the online phase against the testing set, in each scenario. In both scenarii, we set the value of minPts to 3 (see Sec. 4.4.2). For eps, we tune it over [0.01, 2] with 0.0025 increments.

Table 3 summarizes for each training set the best results achieved wrt. AMI score. Homogeneity h and number of clusters are given to explain the AMI score and detail the obtained clustering. The best eps found slightly differs between the two training sets, due to the bias caused by the different variety of packers in each training set. The resulting clusters and their contents are presented in the column labeled "offline phase" in Table 6.

Online Phase

In this phase, we first study the impact of n r p on the effectiveness and update time of our system. Then, we evaluate the robustness of our solution over time. Finally, we test our PCRS selection strategy and discuss how it optimizes the cost of post clustering analysis tasks.

Scattered Representative

Points. Here, we study the impact of n r p (see Sec. 4.4.1) on the effectiveness and update time of our model. Thus, we vary K in K √ N c and then select a K that provides effectiveness while keeping our solution reasonably fast. For both scenarii, we try K among {10 -2 , 10 -1 , 1, 10, 100}, in order to largely vary n r p . With our dataset, when K = 10 -2 , n r p is 1 (the minimum possible) for all clusters; when K = 100, n r p equals the number of samples (the maximum possible) for all clusters. Table 4 presents the obtained results. The update time is the average time in seconds to update the clustering when a new sample arrives, without considering features extraction time.

Impact on effectiveness. In Table 4, we observe in both scenarii that the higher the K, the slightly higher the AMI score, until stabilizing at K = 10. The AMI score is controlled by the ratio between homogeneity and number of clusters. Homogeneity stays stable when K increases, but the number of clusters decreases then stabilizes, so the AMI score increases then stabilizes. Thus, reaching K = 10, the n r p becomes sufficient for our model to achieve its best effectiveness. When SRPs are too few to well represent the geometric shape of some or all clusters, the model does not always find the nearest cluster (see Fig. 3). Thus, the new sample stays "unclassified" or contributes to creating a new cluster, instead of joining the nearest existing cluster.

Impact on update time. In Table 4, the more K increases the more update time increases (drastically). For K = 10 -2 , average update time is around one second. For K = 100, it is around 50 seconds, because many more comparisons with SRPs are performed to find the nearest cluster. This confirms the paramount importance of SRPs to optimize computation in the update process.

Optimal K selection strategy. The K trades-off between effectiveness and update time. This work aims to be highly effective and reasonably fast, so we discard all K values leading to an update time above 1.5 second. We then select the K with the highest AMI score in the solutions left. K = 10 -1 appears as the optimal solution for both our scenarii, and is thus used in our next experiments.

Effectiveness and robustness of SE-PAC.

Here, we evaluate in more details the effectiveness of our SE-PAC (Self-Evolving PAcker Classifier) system on the various update uses-cases (see Sec.4.4.3). Then we study how this effectiveness evolves over time in order to gauge the robustness of the model. The values of eps, minPts, and K are selected as previously described.

Time-flow of incoming samples. We simulate the arrival of the test packers over several months. Each month, a number of specific and common packers (see Tables 1 and2) appear in each scenario. The specific packers represent new packer classes, and the common packers represent variants. The specific packers arrive in a random order, one specific packer appearing each month. The experimental test period covers 17 months (17 specific packers) for MF/S and 15 months (15 specific packers) for S/MF. The samples of each specific packer are equally distributed from the arrival month of their packer till the end of experiment: in MF/S, 125/17 samples of Custom Packer 1 appear in month 1, the rest is then equally distributed over the 16 months left; 22/16 samples of Custom Packer 2 appear in month 2, the rest is distributed over the 15 months left. The samples of common packers are equally distributed through the whole experimental period: in MF/S, packers ASPack and UPX appear monthly with a quantity of 633/17 and 1158/17 respectively. Table 5 summarizes the final results regarding AMI, homogeneity, number of clusters, and DBCV obtained after the whole update process. Fig. 5 to 8 present the monthly evolution of those metrics. We now explain and discuss these results. AMI, homogeneity, and number of clusters evolution. In MF/S, AMI stays high and quite constant over time. In S/MF it slightly decreases (see Fig. 5), because over time S/MF forms higher number of clusters (which the AMI metric punishes, see Sec. 7.1) than MF/S (see Fig. 7). Indeed, the scenario S/MF is more likely to classify an incoming packer to a new cluster, because the eps range (= 0.06) is smaller, so the incoming samples of some test packers may not be grouped under one cluster but form new additonal clusters instead. Therefore, higher homogeneity in S/MF is maintained since different packer families are more likely not to mix (see Fig. 6). DBCV evolution. The significant decrease of the DBCV score (see Fig. 8) was expected, since SE-PAC tends to find for some packers multiple but very close clusters, which thus strongly decreases their density separation. Being multiple, they strongly impact the global mean of the intrinsic clustering quality DBCV(C). This score is worse in MF/S than in S/MF, because the best eps (= 0.08) is higher in MF/S, hence the model tends to have lower density within clusters and higher density between clusters.

Table 6 presents the final results obtained by SE-PAC after the offline and online phases, considering the content of clusters found and the DBCV score, for each packer family. We explain and discuss the results of this table next.

Misclassifications. They are marked in italics: e.g. in MF/S, one sample of Custom packer 2 is wrongly classified with both samples of Custom packer 10 and one sample of AutoIt, in cluster 47. Since eps tuning trades off between correct classifications and number of clusters, it may lead to misclassifications, which are reported in the offline phase . We chose the best AMI score. Experiment shows that scenario S/MF generates a smaller eps in the offline phase, resulting in less misclassifications during offline and online phases. Specific packers. In both scenarii, despite some misclassifications, for most specific packers, including the custom ones, new clusters are created. This shows our system is able to identify new packers.

Common packers. They either joined their respective existing packer family clusters or formed new ones, or both of them. For example, in MF/S all samples of ASPack joined their family cluster 2, while all samples of eXPressor formed the new cluster 39. For FSG, many samples joined existing cluster 6, while the others formed new clusters 25, 40 and 56. Some common test packers did not join their existing family clusters mainly because their versions differ greatly (wrt. eps) from the one used in the training set. For example, in MF/S samples of Themida version 2.4.5.0 (see Table 2) used as test formed the new cluster 45, instead of joining their packer family cluster 19 that hosts a different version of the same packer. The same happened to packers eXPressor, Petite, WinRAR and WinZip.

Finally, multiple sub-clusters were formed for some packers families, because of: (i) Different versions: e.g. see UPX, NSIS and InnoSetup in Table 1; (ii) Obfuscation: e.g. YodaCryptor generates polymorphic instances of its unpacking code by using the instruction substitution technique that tampers quite arbitrarily the mnemonic sequence without affecting its behavior, which makes the grouping of ASM sequences harder, causing additional clusters, and noise. Not learned (66 -648), (-1 -3) (13 -648), (-1 -3) (13 -648), (-1 -3) (66 -0.9) (13 -0.9) Custom Packer 9

Not learned (55 -547) (14 -547) (14 -547) (55 -0.9) (14 -0. (1 -57%), (2 -32%), (3 -4%), (4 -3%), (5 -1%), (6 -1%), (7 -0.4%) , (8 -0.3%), (9 -0.3%), (10 -0.1%) , (11 -0.1%), (12 -0.1%) (13 -0.1%), (14 -0.1%) , (15 -0.1%) (16 -0.1%) , (17 -0.1%)

78

(1 -50%), (2 -21%) , (3 -14%), (4 -7%), (5 -7%) 66

(1 -100%)

The total number of samples inside all these clusters is 34613 in MF/S and 34304 in S/MF. Selection radius r is given by r = α * eps, where eps is the best eps found for each scenario, and α is evaluated over {1, 1.5, 2}.

Table 7 presents the results of our PCRS selection strategy on all the previously found clusters, with different radii r . For r = 1 * eps, the number of PCRS is 0.6% (220/34613) of the total number of samples in clusters in MF/S, or one PCRS for 157 samples, and 0.7% (257/34304) in S/MF, or one PCRS for 133 samples. This ratio tends to stabilize when the selection radius is enlarged, the number of PCRS converging towards the number of clusters found.

Table 8 shows the results in MF/S of our PCRS selection strategy on three individual clusters, with r = 1 * eps. The PCRS are ranked by density marker. Clusters 12, 78 and 66 correspond respectively to PECompact and custom packers 7 and 8. The difference in number and distribution of the PCRS logically lies on how the samples of a cluster are scattered in the hyperplan. For example, cluster 12 needs 17 PCRS, because PECompact uses a random key to generate polymorphic instances of the unpacking stub.

DISCUSSION

In this section, we first give further insights on our results, then we discuss the possibility of human interaction when using our approach over a large time frame. Finally, we examine experimental properties influencing our results validity, and limitations.

Findings and Insights. Our results show that our incremental system stays valid over time. Indeed, keeping high homogeneity at the cost of a few additional clusters is favored. In that sense, it appears that the S/MF scenario is the most suitable. Reducing eps would reduce the cost of supervisor intervention and ensure longer user protection.

Furthermore, in spite of a sharp decrease of the intrinsic quality of our model (see Fig. 8), extrinsic quality remains effective (see Fig. 5). Indeed, our update policy does not autonomously merge close clusters, which prevents potential upcoming misclassifications, at the cost of a few additional clusters.

Custom packers were accurately classified (see Table 6). This validates the efficiency of the chosen features to represent packers. This also hints that these packers are simply inspired from wellknown packers. In parallel, the difficulty to group some samples gives insights on whether the packer was originally developed for obfuscation purposes, like YodaCryptor or PECompact, or for mere compression and encoding like WinRAR and WinZip. This could be further exploited by an analyst for threat intelligence.

Our PCRS selection strategy may reduce post clustering complexity by a factor of up to 157 (see Sec. 8.3.3), an important optimization for concrete tasks like packer analysis and/or unpacking. Therefore, with minimal cost, packer classification, thus unpacking, systems can be updated, which means updating signature-based tools, ground truth labels, specialized unpacking functions, and generic unpacking heuristics.

Our methodology of cluster evolution is fully portable, and our feature extraction can be adapted to other executable file formats.

When and How to Retrain? After a large amount of incremental updates, a human intervention may be useful, hence the question of when and how to retrain.

One approach is to exploit the extrinsic metrics that use the available ground truth to detect misclassifications. We distinguish two cases: (i) misclassification of known packers, where the error can be detected (see for example our experiment MF/S with the mix between WinZip and WinRAR); (ii) misclassification of unknown packers, where the error is not detectable as long as the samples inside the clusters are not further analyzed and labeled.

Another approach relies on intrinsic metrics, like DBCV, that can indicate that some packers are very close, and thus prevent potential upcoming misclassifications.

Based on the metrics above, a trigger policy might be adopted to rise an alarm for retraining, which means adjusting eps, clustering from scratch, then continuing the incremental clustering.

Threats to Validity. Our clustering updates do not autonomously merge or split clusters. This provides our system a high resilience over time, by prohibiting the autonomous merging of close different packers, at the cost of a few additional clusters. Such operations can be done manually by (re-)labeling the involved clusters if necessary, which means giving the same ID for clusters that would merge, and adding new IDs for clusters that would result from a split.

Noise does not impact our approach, because noise points are not discarded but kept to be re-clustered or left unclassified. In practice, noise can be hard-to-group samples due to obfuscation, or rare (singletons) packers. Further post clustering analysis could reveal their exact nature.

Limitations and Future Work. The tapered Levenshtein distance we applied on our ASM sequences remains fragile against highly polymorphic engines that generate very different variants of the same unpacking stub code. If these variants are few, the number of clusters generated remains acceptable; otherwise, our clustering system will produce a very high number of clusters. Future work should consider the extraction of more semantic features, and thus the use of a semantic distance metric, in order to better mitigate such high and complex polymorphism.

CONCLUSIONS

This paper presented a self-evolving packer classifier that deals with the issue of rapid evolution of packers. We proposed a composite pairwise distance metric that is constructed from the combination of different types of packer features. We derived an incremental clustering approach able to identify both (variants of) known packers (families) and new ones, as well as automatically and efficiently update the clusters.

We evaluated our solution on two datasets: MW feed, and synthetic. The results showed that our classifier is effective and robust over time in identifying both known and new packer families. Indeed, our approach constantly enhances, integrates, adapts and evolves packer knowledge, making our classifier effective for longer times.

Furthermore, our work includes a new post clustering strategy that selects a subset of relevant samples from each cluster found, to optimize the cost of post clustering processes.

We thus believe our work can help security companies, researchers and analysts to quickly, effectively and continually update their packer classification, and thus unpacking, systems to ensure a better continuity of security for users over time.

Figure 1 :

 1 Figure 1: Typical workflow of in-depth scanning

Figure 2 :

 2 Figure 2: Overall toolchain

Figure 3 :

 3 Figure 3: Nearest cluster search in incremental update

Figure 4 :

 4 Figure 4: PCRS selection strategy. Note that the selection of the first core point to visit is done randomly.

8. 3

 3 .3 PCRS selection. This experiment evaluates how our PCRS selection strategy (see Sec. 5) performs on the previously obtained clusters.

Figure 5

 5 Figure 5: AMI evolution

Table 1 :

 1 Malware feed. Packers in blue italics are specific to this dataset. Packers in black belong to families common to both MW feed and synthetic datasets. "v?" is unspecified version. "x" is one or multiple sub-versions.

	Packers	(version, # samples)	Total	Packers	(version, # samples)	Total
	ActiveMARK (v?, 2), (v5.x, 1)	3	NsPacK	(v?, 1), (v3.x, 13)	14
		(v1.08.x, 2), (v2.1, 13),
	ASPack		5833	Packman	(v1.0, 23)	23
		(v2.12-2.42, 5818)
		(v1.0, 1),
	ASProtect		175	PCGuard	(v4.06, 3), (v5.0x, 1)	4
		(v1.23-2.56, 174)
	AutoIt	(v3, 1036)	1036	Shrinker	(v3.5, 3)	3
	ExeStealth	(v2.74, 1)	1	PEPACK	(v1.0, 6)	6
	eXPressor	(v1.3, 11), (v1.4.5.x, 1)	12	PESpin	(v1.3x, 6)	6
	FishPE	(v1.3, 3)	3	Petite	(v2.1, 2), (v2.2, 7)	9
	FSG	(v1.33, 2), (v2.0, 11)	13	RLPack	(v1.15-1.18, 1)	1
		(v?, 51), (v1.12.9, 1),
					(v19x, 1),
		(v1.3.x, 3), (v2.0.x, 6),
					(v20x, 14),
		(v3.0.x, 7), (v4.0.x, 4),
					(v2.7x, 12),
	InnoSetup	(v4.1.4, 1), (v4.2.x, 4),	934	PECompact		1226
					(v2.80x, 1),
		(v5.0.x, 4), (v 5.1.x, 40)
					(v2.9x.x, 13),
		(v5.2.x, 35), (v5.3.x, 73),
					(v3.0x.x, 1185)
		(v5.4.x, 45), (v5.5.x, 660)
		(v?, 1), (v7.01.x, 1),
	InstallShield		4	Themida	(v1.8.x-1.9.x, 12)	12
		(v9.00.x, 1), (v10.50.x, 1)
					(v0.1x/0.20/0.21/0.24,
	MEW	(v1.1-1.2, 217)	217	UPack	1), (v0.24-0.27/0.28, 19),	41
					(v?, 21)
	MoleBox	(v2.3.3-2.6.4, 7)	7	WinRAR	(v?, 35)	35
					(v0.6x, 2), (v0.7x, 5),
					(v1.0x, 40), (v1.2x, 2157),
	NeoLite	(v1.0, 2)	2	UPX	(v1.9x, 14), (v2.0x, 114),	4549
					(v2.9x, 6), (v3.0x, 1599),
					(v3.9x, 609)
		(v?, 361), (v1.x, 5)
		(v2.0x, 47), (v2.1x, 20),
	NSIS	(v2.2x, 28), (v2.3x, 33),	1916	WinZip	(v3.1, 66)	66
		(v2.4x, 977), (v2.5x, 43),
		(v3.0x, 397), (v9.99, 4)
				Wise	(v?, 8)	8
	MW feed		All packers		16159

Table 2 :

 2 Synthetic dataset. Packers in blue italics are specific to this dataset. Packers in black belong to families common to both MW feed and synthetic datasets.

	Packers	(version, # samples)	Total	Packers	(version, # samples)	Total
	Armadillo	(v2.52, 628)	628	MEW	(v1.1, 634)	634
	ASPack	(v2.36, 633)	633	mPress	(v2.19, 593)	593
	Custom Packer 1 [4]	(v1.0, 125)	125	NeoLite	(v2.0, 617)	617
	Custom Packer 2 [9]	(v1.0, 22)	22	PackMan	(v1.0, 640)	640
	Custom Packer 3 [7]	(v1.0, 277)	277	PECompact	(v3.03.23, 670)	670
	Custom Packer 4 [3]	(v1.0, 648)	648	PELock	(v2.08, 621)	621
	Custom Packer 5 [10] (v1.0, 655)	655	PENinja	(v1.0, 666)	666
	Custom Packer 6 [2]	(v1.0, 635)	635	Petite	(v2.4, 625)	625
	Custom Packer 7 [14] (v1.0, 651)	651	RLPack	(v1.21, 645)	645
	Custom Packer 8 [6]	(v1.0, 651)	651	telock	(v0.98, 595)	595
	Custom Packer 9 [5]	(v1.0, 547)	547	Themida	(v2.4.5.0, 612)	612
	Custom Packer 10 [15] (v1.0, 655)	655	UPack	(v0.39, 664)	664
		(v1.8.0.1,			(v3.91, 579)
	eXPressor		668	UPX		1158
		668)			(v3.95, 579)
	ezip	(v1.0, 597)	597	WinRAR	(v5.60, 694)	694
	FSG	(v2.0, 630)	630	WinZip	(v5.0, 689)	689
				YodaCryptor (v1.2, 653)	653
	Synthetic dataset			All packers		18798

  is the density separation between clusters C i and C j , and DSC(C i ) is the density sparseness of cluster C i . DBCV (C) ∈ [-1, 1], higher values indicate a clustering with high density within clusters and/or low density between clusters.

Table 3 :

 3 Summary of results of the offline phase

	Training set AMI	h	# clusters best eps minPts
	MW feed	0.941 0.987	38	0.08	3
	Synthetic	0.985 0.993	43	0.06	3

Table 4 :

 4 Impact of n r p on the effectiveness and update time per sample

				Scenario
	K	AMI	MF/S h # clusters	update time (s)	AMI	S/MF h # clusters	update time (s)
	10 -2 0.933	0.960	1.097	0.934	0.981	1.066
			82			95
	10 -1 0.936	0.959	1.190	0.935	0.981	1.125
			80			95
			0.960			0.981
	1	0.945		3.245	0.937		3.035
			76			91
			0.960			0.981
	10	0.948		22.950	0.937		22.378
			73			91
			0.960			0.981
	100	0.948		51.196	0.937		49.544
			73			91

Table 5 :

 5 Summary of the final results

	Scenario AMI	h	# clusters DBCV
	MF/S	0.936 0.959	80	0.285
	S/MF	0.935 0.981	95	0.575

Table 6 :

 6 Cluster contents and DBCV score for each packer family, in both scenarii, after both offline and online phases. "Not learned" in the offline phase column indicates training does not include the packer, so the packer is considered specific, thus new, when used as test packer. "No score" means there is no cluster to evaluate. Cluster ID "-1" means noise. Results in italics are misclassifications.

				Content of clusters:			DBCV score per cluster:
	Packers	Scenario MF/S	(Cluster ID -# samples)	Scenario S/MF	(Cluster ID -score) Scenario MF/S Scenario S/MF
		Offline phase	Online phase	Offline phase		Online phase	Online phase	Online phase
	ActiveMARK	(-1 -3)	(-1 -3)	Not learned		(-1 -3)	No score	No score
	ASProtect	(4 -173), (-1 -2)	(4 -173), (-1 -2)	Not learned		(62 -82), (73 -9), (81 -81), (-1 -3)	(4 -0.6)	(62 --0.1), (73 --0.1), (81 --0.1)
	AutoIt	(25 -1), (36 -1027), (37 -4), (-1 -4)	(25 -1), (36 -1027), (37 -4), (47 -1), (-1 -3)	Not learned		(42 -1027), (90 -3), (-1 -6)	(25 -0.6), (36 -0.8), (37 -0.2), (47 --0.2)	(42 -0.6), (90 -1)
	ExeStealth	(-1 -1)	(-1 -1)	Not learned		(-1 -1)	No score	No score
	FishPE	(20 -3)	(20 -3)	Not learned		(37 -3)	(20 --1)	(37 -0.7)
		(32 -870), (33 -38),					(56 -610), (57 -260),	(56 -0.1), (57 -0.9),
	InnoSetup	(34 -8), (35 -3),	(32 -870), (33 -38), (34 -8), (35 -3), (-1 -15)	Not learned		(61 -38), (80 -8), (84 -3),	(32 -0.4), (33 -1), (34 -0.8), (35 -1)	(61 -1), (80 -0.7),
		(-1 -15)					(-1 -15)	(84 -1)
	InstallShield	(7 -4)	(7 -4)		Not learned		(74 -4)	(7 -0.2)	(74 -0.9)
	MoleBox	(8 -7)	(8 -7)		Not learned		(85 -7)	(8 -0.8)	(85 -0.9)
	NsPacK	(9 -9), (10 -5)	(9 -9), (10 -5)	Not learned		(82 -9), (92 -5)	(9 -0.8), (10 -0.7)	(82 -0.8), (92 -0.7)
								(65 -0.9), (66 --1),
							(65 -6), (66 -205), (67 -112),
	NSIS	(7 -3), (29 -12), (30 -1730),	(7 -3), (29 -12), (30 -1730), (31 -130), (-1 -41)	Not learned		(68 -39), (69 -52), (70 -399), (71 -17), (72 -10), (76 -22),	(7 -0.2), (29 -0.4), (30 -0.2), (31 -0.5)	(67 -0), (68 --1), (69 -0.2), (70 -0.2), (71 -0.5), (72 -0.6),
		(31 -130), (-1 -41)					(77 -993), (78 -8), (79 -6),
								(76 -0.5), (77 --1),
							(-1 -47)
								(78 -1), (79 -0.7)
	PEPACK	(17 -5), (-1 -1)	(17 -5), (-1 -1)	Not learned		(88 -5), (-1 -1)	(17 -0.7)	(88 -0.7)
	PESpin	(27 -3), (-1 -3)	(27 -3), (-1 -3)	Not learned		(94 -3), (-1 -3)	(27 -0.9)	(94 -0.958)
	PCGuard	(26 -3), (-1 -1)	(26 -3), (-1 -1)	Not learned		(93 -3), (-1 -1)	(26 -1)	(93 -1.0)
	Shrinker	(28 -3)	(28 -3)	Not learned		(60 -3)	(28 -0.6)	(60 -0.8)
	Wise	(7 -8)	(7 -8)		Not learned		(83 -8)	(7 -0.2)	(83 -0.6)
	Armadillo	Not learned	(38 -627), (-1 -1)	(0 -628)		(0 -628)	(38 -0.5)	(0 -0.6)
	Custom Packer 1	Not learned	(65 -123), (-1 -2)	(5 -123), (-1 -2)		(5 -123), (-1 -2)	(65 -1.0)	(5 -1.0)
	Custom Packer 2	Not learned	(47 -1), (54 -16), (77 -5)	(6 -22)		(6 -22)	(47 --0.2), (54 --0.5), (77 --0.3)	(6 -0.9)
	Custom Packer 3	Not learned	(48 -277)	(7 -277)		(7 -277)	(48 -1)	(7 -0.9)
	Custom Packer 4	Not learned	(53 -646), (-1 -2)	(8 -648)		(8 -648)	(53 -0.3)	(8 -0.5)
	Custom Packer 5	Not learned	(62 -651), (-1 -4)	(9 -654), (-1 -1)		(9 -654), (-1 -1)	(62 -0.6)	(9 -0.6)
	Custom Packer 6	Not learned	(58 -635)	(10 -635)		(10 -635)	(58 -0.8)	(10 -0.8)
	Custom Packer 7	Not learned	(49 -646), (78 -3), (-1 -2)	(11 -648), (12 -3)	(11 -648), (12 -3)	(49 -0.7), (78 -1)	(11 -0.7), (12 -0.9)
	Custom Packer 8

Table 7 :

 7 # of PCRS

	Radius r	# of PCRS MF/S S/MF
	1 * eps	220	257
	1.5 * eps	105	102
	2 * eps	96	94

Table 8 :

 8 Overview of some clusters after PCRS selection (MF/S)

	Cluster	(PCRS rank -
	ID	density marker)

In assembly language, mnemonics specify an opcode that represents a complete and operational machine language instruction.

eps specifies the radius of a neighborhood wrt. some point.

minP t s is the minimum number of points within radius eps required to form a cluster.

Not to be confused with SRPs.

P is a core point if at least minP t s points (including P ) are within a radius eps of it.

For access to this dataset, please contact the authors.

ACKNOWLEDGMENTS

The authors want to thank Cisco for providing the MW feed and stimulating discussions; Stefano Sebastio for his valuable discussions and his help in structuring this paper in its early stages; Stéphane Ubeda for his constructive insights; the four anonymous reviewers for the thoughtful comments in their reviews that helped us significantly improve this paper.


G S Aglietti
email: aglietti@surrey.ac.uk

B Taylor

S Fellowes

S Ainley
email: s.ainley@sstl.co.uk

D Tye

A, Zarkesh C Cox

A Mafficini

N Vinkoff

K Bashford

T Salmon

C Burgess

A Hall

T Chabot

K Kanani

C Bernal
email: c.bernal@isispace.nl

F Chaumette
email: francois.chaumette@inria.fr

A Pollini

W H Steyn
email: whsteyn@sun.ac.za

SSC19-XI-06 REMOVEDEBRIS MISSION, IN ORBIT OPERATIONS

The RemoveDebris mission has been the first Active Debris Removal (ADR) mission to give in orbit demonstrations of cost effective technologies that can be used to obser ve, capture and dispose of space debris.

The craft was launched to the ISS on the 2nd of April 2018, on board a Dragon capsule. From here the satellite was deployed via the NanoRacks Kaber system into an orbit at 405km altitude and has performed key technology demonstrations including the use of a net, a harpoon, vision-based navigation (VBN) and a dragsail in a realistic space operational environment.

Two CubeSats have been released by the main platform and used as targets for the net demonstration and for the VBN, whereas the harpoon demonstration has used a target mounted at the end of a boom deployed from the platform. These have been the first ever in-orbit successful demonstrations of technologies for large space debris capture. The dragsail demonstration presented some anomalies, however the lessons learned have already been implemented in new successful dragsails already deployed in space missions. This paper briefly outlines the development of the mission, discussing some of its challenges, and focusses on the various in orbit experiments, describing the operations and overall outcomes .

INTRODUCTION

This article describes the RemoveDEBRIS mission, and in particular it focuses on its execution, from the launch of the craft to the ISS -from where the satellite was then deployed in orbit on the 20th of June 2018 -to the end of the in-orbit mission operations in March 2019. Lift off was on the 2nd of April 2018, on board a Dragon capsule on a Space X Falcon 9 Rocket used for the periodic resupply of the ISS [1], and the capsule arrived at the ISS 2 days later.

This mission has been developed by a consortium of 10 institutions (see Table 1), supported by a research grant of the European Commission. RemoveDEBRIS has been the first mission to achieve a successful in-orbit demonstration of technologies for the active removal of space debris [START_REF] Stokes | Space Debris -Encyclopedia of Aerospace Engineering -Klinkrad[END_REF]. Technologies that are particularly suitable for large debris such as satellites that are no longer working, and which are currently tracked [START_REF] Petit | Tracking complex targets for space rendezvous and debris removal applications[END_REF] in "busy" orbits, posing a threat for new satellites.

The consortium came together in 2012-13, and the project started in 2013. The evolution of the design is recorded in various journal articles [START_REF] Forshaw | RemoveDEBRIS: an in-orbit active debris removal demonstration mission[END_REF][START_REF] Taylor | The RemoveDebris Mission, From Concept To Orbit[END_REF] and international conference proceedings [START_REF] Taylor | The RemoveDebris Mission, From Concept To Orbit[END_REF][START_REF] Forshaw | The RemoveDebris ADR Mission: Launch from the ISS, Operations and Experimental Timelines[END_REF][START_REF] Taylor | RemoveDebris Preliminary Mission Results[END_REF][START_REF] Forshaw | Surrey Space Centre: A Survey of Debris Removal Research Activities[END_REF].

Various technologies have been conceived to capture space debris, as reported in [START_REF] Shan | Review and comparison of active space debris capturing and removal methods[END_REF][START_REF] Mark | Review of Active Space Debris Removal Methods[END_REF] and the RemoveDEBRIS project aimed at progressing some of the most cost effective technologies, as cost will be a significant factor in determining the future of Active Debris Removal (ADR).

In essence the mission consisted of a main mini satellite platform of approximately 100kg mass that has released two 2U cubesats which acted as space debris. As the two cubesats were released at low speed it was not necessary for the platform to have its own propulsion system in order to "chase" its targets, but these slowly drifted away allowing the testing of the technologies when the targets (i.e. the cubesats) were at an appropriate distance from the mothercraft.

The first cubesat, DSAT#1, was released on the 16th of September 2018 and, after a slow speed push-off from the mothercraft, whilst drifting away, it deployed inflatable structures in order to increase its size becoming more representative of real larger space debris. The cubesat has then been captured by a net launched by the mothercraft when this was approximately 10 meters away, with the whole operation recorded by the supervision cameras mounted on the mothercraft.

The second cubesat, DSAT#2, was released on the 28th of October 2018, with a low speed ejection from the satellite platform and while drifting away it was observed using the Vision Based Navigation (VBN) system to test its hardware and algorithm capability. DSAT#2 also relayed its own measured position and attitude data back to the mothercraft for validation purposes.

Next the harpoon experiment was performed, where a small Honeycomb panel of construction analogous to that used in standard older satellites structures was deployed using a boom that positioned it at a 1.5 meter distance from the platform. This panel/target was then hit by the harpoon fired from the satellite platform.

The last experiment consisted in the deployment of a dragsail, as during any mission de-orbiting of the satellite would be the last phase of the in-orbit operations. This last experiment showed some anomalies that will be discussed in the paper.

The mission design has tried to ensure that the payloads are as representative as possible for future missions and have scalability potential to larger classes. In certain cases, the mission had to give priority to practicality, satisfying regulatory (licensing) requirements or safety requirements. For instance, sizing of the platform and payload targets was in part selected to ensure the artificial debris would re-enter in a timely fashion whether or not the mission was successful. Similarly a low altitude orbit was selected to ensure prompt disposal of the mission. This led to a launch from the ISS, as its orbit, at approximately 405km altitude guaranteed a rapid re-entry of all the objects.

One of the aims of the mission was to demonstrate that the debris removal demonstration can be performed at "low cost", which posed significant limitations on the budget. The need to contain cost pointed again to a launch from the ISS as a more cost effective launch solution in comparison to available piggy back launches. In turn, the launch from the ISS imposed some limitations on the size and mass of the craft, together with some restrictions and further design & test requirements in order to guarantee, at all times, the safety of the ISS and its crew.

MISSION DEVELOPMENT

The various elements of this mission were developed by the partners of the consortium as shown in Table 1. The payloads were designed, built and initially tested at the partners' facilities, and then delivered to SSTL for the final AIT of the platform.

Aglietti

3
33 rd Annual AIAA/USU Conference on Small Satellites The overall schedule of the project is shown in Table 2 and the plans for the in-orbit demonstrations are pictorially summarized in Figure 1.

Concerning the launch, as the craft was stored as cargo in the Dragon capsule, this posed some challenges in terms of determining exactly the vibration environment that the craft would have experienced, and derive appropriate levels for testing. In addition the load path was completely different from a standard launch where the satellite is constrained by its release mechanism Payloads: CubeSat avionics Some other challenges for the development of the hardware related to ensuring compliance with the NASA safety requirements that had to be demonstrated during the three levels of the NASA safety reviews. Items such as the Cold Gas Generators and the battery presented some issues, the first related to the nature of the chemicals in the device, the latter due to its size and energy. The RemoveDEBRIS platform used an 80 cell battery supplied by ABSL consisting of 1400mAh SONY US18650S in a 8s10p configuration. Although ABSL are market leaders in the manufacture and Those mentioned above are just representative examples, and the lesson learned from the process is that early engagement with the NASA safety board enables to integrate the required features directly in the design, rather than forcing modifications afterwards.

LAUNCH AND DEPLOYMENT OPERATIONS

At the end of AIT activities in the SSTL cleanroom in Guildford UK, the satellite was shipped to Cape Canaveral for launch For protection purposes during transportation, aluminum honeycomb panels were mounted on the sides of the satellite, and the assembly was then incased in a foam shell (see Figure 2). The foam shell was then encased in an aluminum box, as used for the vibration testing, and this was finally enclosed in the transportation case.

Once at the launch site, the external casing was removed, leaving the craft with its protective panels in the foam shells. In this configuration the craft was put in the cargo transfer bag (CTB) and finally in the Dragon capsule.

Launch was nominal and when the craft arrived on the ISS the CTB, foam casing and protective panels were removed and the craft was mounted on the sliding table in the Japanese module airlock (see Figure 3). Once on the other side of the airlock the craft was handled by the ISS robotic arm and release as shown in Figure 3).

Commissioning and Early Operations Phase (LEOP)

Contact with the craft was made during the first pass after power up, over the SSTL groundstation in Guildford UK. Note that due to ISS safety requirements the craft had to be kept switched off for at least 30 minutes from its release from the ISS.

The telemetry that was downloaded showed that the spacecraft was performing nominally, e.g. Battery was fully charged, and temperatures as expected.

Commissioning progressed with switch on of the spacecraft On Board Computer the progressed with detumbling from the slow initial angular rate to a controlled attitude state. Attitude and Orbital Control System commissioning progressed until the platform was in a coarse Nadir pointing mode.

The next phase involved some platform checks, to verify health and functioning of the key modules not Aglietti 5 33 rd Annual AIAA/USU Conference on Small Satellites already checked. Prime and redundant RF receivers, low rate transmitters and low level command links were tested. The spacecraft then performed a series of AOCS maneuvers to verify performance against that required for executing payload experiments.

The final phase was the payload calibration and characterisation. The Supervision cameras and VBN camera were tested over a range of exposures and frame rates which were planned for use on the experimental demonstrations and related parameters were adjusted.

IN ORBIT DEMONSTRATIONS

Net capture demonstration

The first demonstration to take place was the Net capture. This demonstration required the release of the Cubesat DSAT#1, at low speed (V=5cm/s), and this to inflate its deployable structures in order to become more representative of the size of a large space debris. DSAT#1 in its stowed and deployed configuration is shown in Figure 4.

with lateral inflatable booms deployed

On the 16 th of September, DSAT#1 was deployed by the ISIS deployer as planned, and triggered by a timer its deployables were actuated. Measurements of the velocity with which the cubesat drifted away from the mothercarft showed a speed of approximately 7.5m/s; slightly higher than planned but still appropriate for the experiment. Two of the four lateral deployable booms deployed as planned (Figure 5) and so did the longitudinal deployable boom. The latter is visible in the video-footage of the Net capture experiment, as recorded by the two surveillance cameras mounted on the mothercraft to video the experiment.

VBN Demonstration

The purpose of the VBN demonstration was to assess the state-of-the-art of Image Processing (IP) and navigation algorithms based on actual flight data, acquired through two sensors: a standard high quality camera and a flash imaging LiDAR system.

The device is shown in Figure 7, together with the cubesat DSAT#2 that was released by the mothercraft in order to be observed by the two cameras to then be able to reconstruct the dynamics of the object from the "pictures" acquired via the cameras. 33 rd Annual AIAA/USU Conference on Small Satellites One of the challenges is to recognise the target independently from the background (see Figure 8), and this experiment provided a wealth of real data to assess the performances and robustness of the VBN algorithms. Lidar imagery directly delivers information about the target distance, and this data was compared with the measurements obtained by the GPS on board the CubeSat, which were relayed to the mothercraft via an inter satellite link. This data and the GPS information for the mothercraft allowed calculation of the distance between the objects, and use of this as a reference to establish the quality of the LiDAR measurements, which was found to be in line with the expectations.

Harpoon Demonstration

The harpoon demonstration was carried out firing the Harpoon on a target representative of structural panels on old, large satellites, which are potential targets for this technology. The target was deployed at the end of a 1.5m long boom as shown in Figure 10, and more details can be found in [START_REF] Aglietti | An overview of the mechanisms and deployables on the removedebris ADR mission[END_REF][START_REF] Fernandez | Design and development of a gossamer sail system for deorbiting in low earth orbit[END_REF]. As the target was deployed a significant oscillation developed on the structure with the target oscillating around its nominal position as shown in Figure 11. The oscillations were excited by the inputs produced by on board equipment (AOCS), and minimizing the action of the AOCS it was possible to stabilize the boom in order to be able to carry out the experiment with sufficient reliability.

Figure 12: Harpoon imbedded in the target

On the 8 th of February 2019 the harpoon was fired at the target. The harpoon travelled at a speed of 19m/s and hit the target in the centre as shown in Figure 12. The target was snapped off of the end of the boom (see Figure 13), due to the mechanical shock, it was retained by the harpoon which was tethered to the mothercraft.

The floating target eventually wrapped itself around the deployable boom as shown in Figure 13.

Dragsail Demonstration

The last experiment to be performed was the dragsail, as in any mission the deployment of this device to deorbit the craft would be the last phase of the in-orbit operations.

This payload that was delivered for integration in the mothercraft is shown in Figure 14 and when operated, the inflatable mast extends 1m out of the enclosure and CFRP booms deploy radially outwards to unfold the sail. Once deployed the dragsail is very similar to that used for the cubseat InflateSAIL that is shown in Figure 15 (see refs. [14, 15 16]). As this payload was mounted on the back of the mothercraft in order not to interfere with the other payloads (Net, VBN and HTA) it was not possible to video this experiment, as all the supervision cameras were on the other side of the craft, to monitor the other three demonstrations. For the Dragsail, successful demonstration would have been indicated by a significant increase in the decay rate of the mothercraft, by some changes in the outputs pattern of the solar panels (as these at times would be obscured by the sails), and by an increase in the brightness of the satellite from ground observations.

The command to deploy the sail was given on the 4 th of March 2019. From the ground, a small increase in the brightness of the object (the RemoveDEBRIS mothercraft) was detected, however, there was no significant change in the output of the solar panels, and the decay of the altitude of the object has not accelerated as expected (see Figure 16). These factors point to a possible partial deployment of the sail. 33 rd Annual AIAA/USU Conference on Small Satellites However based on the lesson learned from the development and MAIT of the RemoveDEBRIS' dragsail, improvements were made on the dragsail of the cubesat InflateSAIL and on two further dragsails (see Figure 18) that were used for the Spaceflight Industries' SSO-A mission. All three sails have deployed successfully in orbit with InflateSAIL having already re-entered and therefore the development of the RemoveDEBRIS dragsail had its usefulness as it paved the way for the development of these commercial devices.

Figure 18: Dragsail for the Space Flight Industries' SSO-A mission

One final comment is that even without the dragsail fully deployed, the two cubesats and the craft are deorbiting as planned. With reference to Figure 16, the first of the cubesatas has already been de-orbited (2nd of March 2019), the second should be de-orbited in the next few months, and the mothercraft during its first year in orbit has already lowered its altitude by more than 10km, and therefore is due to completely de-orbit, burning in the atmosphere in the next couple of years.

Considering that the platform was released in orbit at an altitude slightly higher than planned (405km, versus the 400km used for the simulations in Figure 17), the decay of the craft is consistent with what was initially predicted, reported in Figure 17, and indeed well within the current guidelines.

CONCLUSION

This article has briefly described the RemoveDEBRIS mission, with emphasis on the in-orbit operations.

The demonstrations of the Net and Harpoon target technologies have confirmed that these are indeed viable technologies for the removal of large space debris. The hardware will need scaling up, due to the larger size of potential real targets, but the basic technology is sound and the in orbit demonstrations have provided a valuable experience to de-risk future developments.

The VBN demonstration has also been successful, collecting a great amount of data and proving the performance of hardware and software in the real environment.

The dragsail experiment manifested some anomalies, however, this has paved the way for successful commercial exploitation in the new devices that have been produced by SSC.

The mission has also been successful in getting a variety of institutions working together to tackle a global issue, from large to small companies, universities and research centers, sharing best practice and improving their competitiveness.

Figure 1 :

 1 Figure 1: N1 to N4: net experiment, V1 to V3: vision-based navigation experiment, H1 to H4: harpoon experiment, D1 to D3: dragsail experiment.

Figure 2 .

 2 Figure 2. Top Left: RemoveDEBRIS, Top Right: RemDEB with protective panels going in the foam clam-shell, Mid Left CAD model of RemDEB with protective panels, Mid Right: RemDEB in the clam shell, Bottom Left: Assembly in Aluminum casing, Bottom Right: Assembly in Aluminum casing going in transportation case.

Figure 3 .

 3 Figure 3. Left: RemoveDEBRIS mounted on the sliding table of the airlock, Right: RemoveDEBRIS at the moment of the release from the robotic arm of the ISS

Figure 4 .Figure 5 :

 45 Figure 4. Left: DSAT#1 in its stowed configuration; Right: DSAT#1 with its inflatable structures fully deployed

Figure 6 :

 6 Figure 6: Moment of the Net capture of DSAT#1, one of the satellite sails is shown, between the lateral and longitudinal booms Figure 6 shows the moment of the capture, at the edge of the Net, from where it is possible to see one of the 4 sails of DSAT#1, between one of the lateral booms and the longitudinal boom.

Figure 7 .

 7 Figure 7. Left: Vision Based Navigation payload, Right: DS-2 target in deployed state

Figure 8 :

 8 Figure 8: DSAT#2 with different backgrounds.

Figure 9 :

 9 Figure 9: Left: View of DSAT#2 with shape contours, Right: image from LiDAR camera

Figure 10 :

 10 Figure 10: Harpoon Target Assembly in its deployed configuration.

Figure 11 :

 11 Figure 11: Target deployed at the end of the boom, in green the nominal position and in red the positions at the extreme of the scallions whose direction is indicated by thee red arrows

Figure 13 :

 13 Figure 13: Left Target captured by the harpoon, floating in space tethered to the mothercraft. Target and tether line wrapper around the boom.

Figure 14 :Figure 15 :

 1415 Figure 14: RemoveDEBRIS dragsail payload

Figure 16 : 2 Figure 17 :

 16217 Figure 16: RemoveDEBRIS altitude of various objects. Blue -ISS, Orange -RemoveDEBRIS mothercraft, Grey -DSAT#1, Green DAT#2

Table 1 : RemoveDebris Overall Mission Chronology Partner Country Business Roles in the project

 1

	SSC (coordi nator)	UK	University (Research)	Project management CubeSats, Dragsail, Harpoon Target Assy
	SSTL	UK	Satellite Prime	Platform provider, Satellite operations
	Airbus D&S	D		Payloads: Net
	Airbus D&S	F	Prime for space transportation and satellites	Mission & System Eng., P/oads: Vision-Based Nav. & VBN algorithms
	Airbus D&S	UK		Payloads: Harpoon
	Ariane Group	F	Prime for space transportation and satellites	Mission & System Engineering
	ISIS	NL	SME, nanosatellites	Payloads: CubeSat deployers
	CSEM	CH	Research Institution	Payloads: LiDAR camera
	INRIA	F	Research Institution	Payloads: VBN algorithms
	STE	South Africa	University (Research)

Table 2 : RemoveDebris Overall Mission Chronology Event Date

 2

	Start of RemoveDEBRIS project	October 2013
	(Kick off)
	PDR (Preliminary Design Review)	December 2014
	Platform CDR (Critical Design	March 2017
	Review)
	Satellite FRR (Flight Readiness	December 2017
	Review) & AR (Acceptance Review)
	Transfer to US	December 2017
	Launch	2 nd April 2018
	Release from ISS	20 th June 2018
	End of LEOP & commissioning	August 2018
	Net Experiment	16 th September 2018
	Vision Based Navigation Experiment	28 th October 2018
	Harpoon Experiment	8 th February 2019
	DragSail Experiment	4 th March 2019
	End of Life (planned)	2020-2021

Acknowledgments

This research is supported by the European Commission FP7-SPACE-2013-1 (project 607099) 'RemoveDEBRIS -A Low Cost Active Debris Removal Demonstration Mission', a consortium partnership project consisting of: Surrey Space Centre (University of Surrey), SSTL, Airbus DS (formerly Astrium) GmbH, Airbus SAS, Airbus Ltd, Airbus Safran Launchers, Innovative Solutions in Space (ISIS), CSEM, Inria, Stellenbosch University.

Aglietti

33 rd Annual AIAA/USU Conference on Small Satellites The authors would also like to acknowledge the help and support of launching agent NanoRacks as this has been crucial to deliver successfully this mission.