dataesr/scientific-paragraphs-categorization huggingface dataset:
r. t. the source code of the PUT, written in a high-level programming language. On the contrary, many fuzzers, like AFL and AFL++, compute (decision) coverage at assembly level, which, considering common compilation approaches, is close, but not perfectly equivalent, to doing it at source level. Notably, in the C/C++ programs usually considered in fuzzing research, logical expressions at decision points often rely on lazy logical operators (&& or ||). Such expressions are usually compiled into assembly code doing a short-circuiting evaluation of their atomic conditions, which adds (nested) decisions in the assembly for each of these atomic conditions. When the assembly includes such additional nested decisions, one can check that AFL's DC at assembly level is a stronger criterion than both DC and CC at source level (i.
e. a test suite satisfying AFL's DC at assembly level will satisfy both DC and CC at source level, while a test suite satisfying either DC or CC at source level may require additional tests to satisfy AFL's DC at assembly level). Yet, MCC at source level remains a stronger criterion than AFL's DC at assembly level (because a test suite satisfying AFL's DC at assembly level may not cover all the possible combinations of atomic truth values). As a consequence, using (source-level) CC to pilot a fuzzer like AFL should provide only a limited additional guidance compared to vanilla AFL, while using MCC should be a better guide  3. Mutation criteria. Mutation criteria are derived from the research eforts in mutation testing  [28]. Test objectives consist here of mutants, i. e. slight variants of the program under test, seeded with common faults.
FINE-GRAINED COVERAGE-BASED FUZZING 4. 1 General principle Given the (source) code of a program and a label-encodable code coverage criterion  4  , our approach transforms the original program into a semantically equivalent program , so that fuzzing with a coveragebased fuzzer is the same as fuzzing and keeping the inputs that increase coverage w. r. t. as additional seeds for subsequent mutations. In practice, transforming into works as follows. For each label corresponding to one of the test objectives required by the coverage criterion for (e. g. truth values to activate, mutants to kill), we add an empty conditional statement at the same location in as and whose entry condition is 's predicate. This transformation process is illustrated on a simple code snippet at Figure  6. When fuzzing , the fuzzer will save as a seed for mutation any input that covers a previously uncovered code branch.
IMPLEMENTATION We have implemented our program transformation approach for C programs as passes in the Clang open-source compiler infrastructure  [35]. Our implementation involves recursively traversing the Abstract Syntax Tree (AST) of our target program using recursive visitors provided by the Clang API. Our program normalisation pass transforms the expressions that will subsequently be involved in the labels from the MCC or WM criteria, in case they contain side-efects (The Clang's AST provides the HasSideEffects() primitive to detect them). Our program annotation pass inserts robust conditional statements for the MCC and WM (ABS, AOR, COR and ROR operators) criteria, using the Rewriter class provided by the Clang API. The conditionals are made robust by analysing their predicate and preixing unsafe operations (like pointer accesses and number divisions) with a guarding atomic condition (like checking that the pointer is not null and the divisor diferent from zero).
We have carefully inspected by hand the assembly code produced after (1) transforming a sample program with our passes, (2) instrumenting the transformed code with the fuzzer coverage measurement harness and (3) compiling the result with gcc, in order to make sure that our transformation was compatible with (and thus not tampered) by the harnessing or compilation processes. This inspection revealed that preventing such tampering requires deactivating aggressive compiler optimisations and adding the asm volatile (""::: "memory"); statement in the body of the inserted conditional statements. Our optional step, where infeasible/trivial conditionals are detected (and pruned out), is implemented by diverting the static analyses of a standard compiler (namely, gcc), in a similar way to Papadakis et al.
Experimental setup To collect data to answer our research questions, we use our code transformation tool to add conditional statements for MCC and WM objectives to the programs of two standard benchmarks used in fuzzing research, namely LAVA-M  [17]  and MAGMA  [18]. LAVA-M involves small and single-ile C programs, automatically seeded with 2,368 artiicial bugs at a very high density (one bug every six lines of code in average). MAGMA involves large and multi-ile C programs (sometimes to be compiled to a set of several independatant executables)  7  , manually injected with 116 real bugs at a low density (one bug every 6k lines of code in average, i. e. three orders of magnitude less density than in LAVA-M). Both benchmarks provide built-in logging mechanisms, which report when the bugs are triggered during a fuzzing campaign (with a unique ID per bug to avoid double counting).
Program instrumentation, build and sanity checks Instrumenting the LAVA-M and MAGMA benchmark programs to make the MCC and WM coverage objectives explicit lead to 337,311 conditionals being inserted in the code. Considering that each conditional represents one additional line of code, the instrumentation increased the size of programs by 46% on average, varying between one conditional every line of code (in the libxml2 program) and one conditional every ive lines of code (in the who program). Note that the instrumented program is aimed at being used during fuzzing campaigns only and not in production. A detailed breakdown of the conditionals insertion numbers can be found in Table  2. Manual inspection revealed that the diferent coding styles of the instrumented programs lead to diferent densities of coverage objectives of all types.
For example, the huge number of MCC objectives for libxml2 is due to the common use of "one by one character comparisons in single condition guards" within the libxml2 codebase, e. g. Code instrumentation slows down the program builds, as instrumentation itself takes time to complete and the instrumented program is larger to compile. A detailed breakdown of the build slowdown numbers can be found in Table  3  for the MAGMA programs (all build times for the LAVA-M programs are less than one second, so that overhead data are not really meaningful). In total, the instrumentation overhead makes building the MAGMA programs more than seven times slower. It should be noted that most of the slowdown comes from the preprocessing phase, where we leverage the clang-tidy tool to format the original code (e.
In addition, because of the added conditionals, AFL++'s harness generates more coverage data to be subsequently processed by the fuzzer, slowing down the fuzzing loop. Plotting throughput vs. increase of program size (Figure  12a ) shows that the decrease in fuzzer's throughput is well correlated with the relative increase of the PUT's size, caused by the conditionals added by our instrumentation. Put another way, the denser the PUT is instrumented with explicit ine-grained coverage objectives, the more the fuzzer's throughput is usually reduced. The efect of adding our instrumentation over the number of seeds saved by the fuzzer seems more intricate, as both rises and falls are observed from one setting to another. This complex inluence can be mainly explained by a couple of intertwined but opposing forces.
) synthesized by the corresponding averaged value in   the same fuzzing budget. In the other hand, as more conditionals are added in the code by our instrumentation, a higher fraction of the generated inputs are considered as interesting by the fuzzer and saved as seeds in the pool. Depending on how these two forces combine during the fuzzer run, the net efect will be either a rise or fall of the number of saved seeds, compared to fuzzing the program without instrumentation. Adding our instrumentation also impacts the number of PUT's edges covered during a fuzzer run. Most of the time, this impact is negative (i. e. less edges are covered) and quite well correlated with the decrease in fuzzer's throughput (Figure  12b ). This can be explained by the fact that, as the fuzzer's throughput decreases, the fuzzer has less chance to discover new branches within the same fuzzing budget.
Another way to look at the bug inding results is by focusing on how the number of discovered bugs in who evolves when combining the MCC and WM criteria. Each of the two criteria taken separately enables inding more bugs than without instrumentation (133 with MCC, but with a strong uncertainty, and 98 with WM). Yet, instrumenting the program with the objectives from both criteria together leads to no measurable diference between the number of discovered bugs with and without instrumentation. One hypothesis to explain this behaviour is that, in this last setting, as the fuzzer's throughput gets much more reduced than in the irst two, it reduces also the chance for the fuzzer to ind bugs within the same fuzzing budget. A reduced fuzzing throughput could also explain why the fuzzer misses some bugs in MAGMA, compared to fuzzing without instrumentation.
In addition, these changes come at a very high price, as detecting the infeasible and trivial conditionals for LAVA-M required 22 hours and 43 minutes of analysis. This high cost makes our detection approach impossible to scale to the MAGMA programs, as it requires building each program once per inserted conditional, which is intractable in reasonable time for large programs including many conditionals. While using a dedicated static analysis may improve the scalability and performance of our pruning stage, we chose to consider a much simpler way to reduce the objective density in the MAGMA programs. We detail and evaluate this technique in the next subsection. Discarding subcategories of coverage objectives. A simpler way to reduce the density of ine-grained objectives in instrumented programs is simply discarding some categories of these objectives.
Reported increase or decrease values are against QSYM applied on the original PUT. Table  7. P-values from the MannśWhitney U test  [36]  corresponding to data reported in Table  6. In a nutshell, each p-value can be seen as an estimated probability that the diference (increase in throughput, reduced number of bugs, etc. ) synthesized by the corresponding averaged value in Table  6  would be due to the randomness of the two compared datasets. The p-values in this table are coloured in green if they are smaller than 2% (diference has among the highest probabilities to be real), in orange if they are between 2 and 50% (diference has more probability to be real than caused by randomness) and in red if they are above 50% (diference has less probability to be real than caused by randomness). Table  9.
P-values from the MannśWhitney U test  [36]  corresponding to data reported in Table  8. In a nutshell, each p-value can be seen as an estimated probability that the diference (increase in throughput, reduced number of bugs, etc. ) synthesized by the corresponding averaged value in Table  8  would be due to the randomness of the two compared datasets. The p-values in this table are coloured in green if they are smaller than 2% (diference has among the highest probabilities to be real), in orange if they are between 2 and 50% (diference has more probability to be real than caused by randomness) and in red if they are above 50% (diference has less probability to be real than caused by randomness). Summary of answer to RQ2 (impact of careful objective selection).
Threats to validity Threats to internal validity. A irst class of threats to the internal validity of our conclusions arise because the software artifacts that we used, including (1) our toolset to instrument code with explicit ine-grained coverage objectives, (2) the studied AFL++ and QSYM fuzzers and (3) our experimental infrastructure to run fuzzing campaigns and collect relevant data, could be defective. However, we have crosschecked our results in several ways. First, some hand-picked fragments of the instrumented programs have been manually inspected and veriied, in order to make sure that the code instrumentation process did produce the expected source code and that the instrumentation was not tampered by compilation to assembly code. Second, the behaviour of the original and instrumented programs were manually compared on a curated set of inputs, to make sure that the inserted label-derived conditional statements had not altered the semantics of the programs.
To double-check the proper conservation of program semantics modulo our instrumentation, we have also taken advantage of the performed massive fuzzing campaigns, to make sure that the instrumented code did not trigger any inexplicable crashes compared the original one. Our experimental infrastructure has been tested on small-scale fuzzing campaigns, where we have checked that it was producing consistent results for a set of signiicantly diferent fuzzer conigurations. All these sanity checks succeeded. In addition, the code of our instrumentation toolset and experimental infrastructure has been reviewed by at least two and up to three diferent developers. It has been made available as an open-source artefact for review by the community. At the heart of our experimental evaluation, AFL++ is a solid, community-maintained and open-source fuzzer.
The key idea is to use iner-grained metrics such as edge coverage for seed selection and coarser-grained metrics such as block coverage for clustering. Furthermore, the technique uses a reinforcement learning-based hierarchical scheduler for seed selection. Contrary to these two works, our method does not alter the fuzzer to handle additional metrics, but it adds branches encoding the new objectives directly to the tested program, enabling of-the-shelf reuse of any fuzzer based on branch coverage. In addition, these two works focus either on shallow standard metrics, like block and branch coverage, or on their own ad-hoc variants of branch coverage, while our work proposes to leverage the many ine-grained metrics widely studied in the software testing literature. However, our method does also increase the number of inputs taken as seeds and thus hampers the performance of the fuzzer for this reason as well.
In addition, the metrics that we currently support are iner-grained than branch coverage but coarser-grained than path coverage, possibly providing a better compromise between fuzzing precision and seed explosion. Fioraldi et al. [42]  consider to save as seeds any input that violates likely block-level invariants of the program, collected through a prior dynamic analysis. The technique considers thus a very diferent source of information than ours to guide the fuzzer and, again, it requires the modiication of the fuzzer to capture the violations of invariants. A blog post from 2016  [43]  proposes to help fuzzers penetrate blocks guarded by a magic bytes comparison, through splitting the guard into nested smaller comparisons. While this mechanism also relies on additional branches in the code to guide the fuzzer, its essence is splitting a hard-to-penetrate branch into an equivalent sequence of easier-to-penetrate branches.
As in our discussion of Quian et al. in the previous paragraph, it is interesting to notice that the issues and results reported by Mantovani et al. can also be related to ours. First, solutions had also to be found to reduce the number of considered additional test objectives, in order to avoid overwhelming the fuzzer and to reduce the overhead. These solutions involve considering the deinition-use pairs only from a subset of the PUT's variables, as well as pruning out redundant objectives  [30]. Second, the authors also report that their technique slows down the fuzzer (by 10-14% in average) and reduces the total number of edges that it covers. In addition, they report that their technique can discover diferent bugs, compared to the original fuzzer, on code with a "data-dependent structure".
The preliminary results suggest that (1) fuzzing each mutant for ive minutes within a 10 hours total fuzzing budget implied that only a tiny subset of the mutants (1-2%) could actually be fuzzed and (2) the approach seems to improve the bug inding power of the fuzzer on the fuzzgoat bug-laden program (about 1k lines of code). Finally, two (non-peer-reviewed) research proposals have recently been made public about combining mutation coverage and fuzzing. Laybourn et al. [44]  propose to use mutation coverage to augment the coverage feedback of fuzzers, while Gopinath et al. [46]  evaluate the challenges of using mutation coverage to build fuzzing benchmarks.
We have used this approach to evaluate the impact of supporting two representative ine-grained coverage metrics (multiple condition coverage and weak mutation) over the performance of a state-of-the-art grey-box and hybrid fuzzer (AFL++ and QSYM) with the standard LAVA-M and MAGMA benchmarks. This evaluation has revealed that our guidance mechanism, where the fuzzed code is instrumented with additional branches, is efective and could possibly be leveraged in other contexts, like with human directives or bug preconditions from static analysers. However, this evaluation has also revealed that the impact of ine-grained metrics was hard to predict before fuzzing and most of the time either neutral or negative, so that we do not recommend using them as a general means to guide fuzzers. Yet, it remains an open question whether such metrics could be useful in some speciic favorable circumstances, like for limited parts of the codebase or as a complement to classical fuzzing campaigns.
69 0. 69 0. 151 0. 18 0. 095 0. 095 0. 095 0. 905 0. 008 0. 008 0. 548 0. 519 tifcp 0. 016 0. 016 0. 008 0. 017 0. 008 0. 008 0. 016 0. 056 0. 008 0. 008 0. 008 0. 056 read_memory 0. 016 0. 016 0. 008 0. 017 0. 008 0. 008 0. 016 0. 056 0. 008 0. 008 0. 008 0. 056 xmllint 0. 008 0. 008 0. 008 0. 233 0. 008 0. 008 0. 151 0. 424 0. 008 0. 008 0. 008 0. 233 sqlite3 0. 151 0. 151 0. 016 0. 424 0. 056 0. 056 0. 008 0. 6 0. 008 0. 008 0. 008 0. 233 server 0. 841 0. 841 0. 753 0. 424 0. 222 0. 222 0. 222 0. 424 0. 032 0. 032 0. 008 0. 424 client 0. 016 0. 016 0. 069 1 0. 69 0. 69 0. 042 1 0. 095 0. 095 0. 141 1 x509 0. 222 0. 222 0. 401 0. 424 0. 69 0. 69 0. 172 1 0. 402 0. 402 0. 209 0. 424 would be due to the randomness of the two compared datasets. The p-values in this table are coloured in green if they are smaller than 2% (diference has among the highest probabilities to be real), in orange if they are between 2 and 50% (diference has more probability to be real than caused by randomness) and in red if they are above 50% (diference has less probability to be real than caused by randomness).
This article introduces a novel approach for building a robust Automatic Gesture Recognition system based on Surface Electromyographic (sEMG) signals, acquired at the forearm level. Our main contribution is to propose new constrained learning strategies that ensure robustness against adversarial perturbations by controlling the Lipschitz constant of the classifier. We focus on nonnegative neural networks for which accurate Lipschitz bounds can be derived, and we propose different spectral norm constraints offering robustness guarantees from a theoretical viewpoint. Experimental results on four publicly available datasets highlight that a good tradeoff in terms of accuracy and performance is achieved. We then demonstrate the robustness of our models, compared with standard trained classifiers in four scenarios, considering both white-box and black-box attacks.
The robustness is ensured by using a novel learning algorithm for training feedforward neural networks. -To show that a good accuracy-robustness balance can be reached. To do so, we train the system under carefully crafted spectral norm constraints, allowing us to finely control its Lipschitz constant. A tight Lipschitz constant is efficiently estimated by focusing on neural networks with positive weights as in Reference  [13]. -To demonstrate the performance of the final architecture in real-life experiments where we show that the proposed robust model outperforms those trained conventionally. -To analyze how our system behaves when the input is affected by different noise levels, simulating perturbations that may occur in real scenarios. -To show the validity of our solution by experimenting on four distinct publicly available sEMG gestures datasets.
sEMG Datasets We test our proposed training scheme on four online datasets containing EMG information of different hand gestures. The first three were acquired using Myo armband, a device developed by Thalmic Labs, equipped with eight sEMG sensors displayed circularly, while the last one was acquired using 10 active double-differential OttoBockMy-oBock13E200 sEMG electrodes. 2 Myo-sEMG. The first dataset, detailed in Reference  [21]  contains EMG signals characterizing 7 hand gestures correlated to the primary movements of the hand. There are four mobility gestures (i. e. , wrist flexion and extension, ulnar, and radial deviation) and two gestures used for grasping and releasing objects (i. e. , spread fingers and close fist). The 7 th gesture characterizes the neutral position, corresponding to the relaxation of the muscles.
13Myo-sEMG. The second dataset includes 13 gestures: the same 7 gestures described above, plus 6 additional classes. It contains gestures from 50 different subjects and two sets of trials per user. All 13 gestures are depicted in Figure  2. More details about the dataset can be found in Reference  [2]. NinaPro DB5. C. The third dataset is a subset of NinaPro DB5 dataset, detailed in  [47]. The dataset is acquired using two Myo armbands, one positioned just below the elbow and the other one closer to the arm. For our experiments, we considered the subset C, which contains sEMG data associated to 24 gestures. NinaPro DB1. The forth dataset was introduced in Reference  [5] , and encompasses physiological data acquired from 27 able-bodied subjects, performing a total of 53 different gestures. The sEMG data is recorded using 10 electrodes, positioned as follows.
Proposed Architecture The raw 8/10 channels EMG signal is split using a 250 ms sliding window, with 50% overlap. A 250 ms window is long enough to cover the most common gesture durations, ensuring that the essential temporal aspects of each gesture are captured within this window. Overlap ensures that important signal characteristics, such as abrupt changes or transient patterns, are not missed due to window boundaries. By using overlapping windows, the feature extraction process also becomes more robust, as multiple windows contribute to representing the same temporal information from the EMG signal. From each window of each channel a series of 8 time descriptors are extracted. The information from all the channels is then concatenated, forming a 64 (80 for the forth dataset) dimensional vector.
The 7-gestures dataset contains around 200k vector samples, the 13-gestures dataset has around 59k vector samples, the 24-gestures dataset has around 20k vector samples, while the 53-gestures dataset has 250k vector samples. Those are split in training, validation, and test sets at user level according to the ratio: 70%, 20%, and 10%. These vectors are fed to the network in mini-batches of size 2048. For our experiments, we used as the loss function the categorical cross entropy, with a learning rate γ = 10 -3 and momentum parameter ζ = 0. 02. The considered architectures consists of a 6-hidden layer (m = 6) fully connected neural networks, with different parameters depending on the considered datasets, but the same core structure, as displayed in Figure  3. Let x = (x k ) 0≤k ≤K -1 be the vector of EMG samples acquired on a window from one channel.