Methodology

P1 Hex-Rays 36 m 5.3 gotostatements are confusing: jumping out of the loop and then back in it.

5.4 Dream⁺⁺’s output is easier to understand.

One can simply read the code sequentially without worrying about these jumps.

5.5 I cannot say how much this will influence the time I need to solve the task when analyzing Dream⁺⁺’s output.

Task 6: Domain Generation Algorithm

P1 Dream⁺⁺ 33 m 6.1 The control flow inside the function is easy

to understand

6.2 For the Hex-Rays code, I would need at least 60 minutes (probably 90 minutes). Maybe I would give up after that.

P2 Hex-Rays G# 36 m 6.3 Code looks very weird.

6.4 I gave up because I do not think I could un-derstand the code in the loop.

Task 7: Checking OS Version

P1 Hex-Rays 3 m No Comments

P2 Dream⁺⁺ 7 m No Comments

Task 8: Persistence

P1 Dream⁺⁺ 2 m No Comments

P2 Hex-Rays 2 m No Comments

Table 5.1: Test User Study. The third column denotes the result of performing the task: task is completely solved,G#= task is partially solved, and#= task is not solved. Tasks are ordered according to difficulty level as shown by the pre-study.

The main user study is almost unchanged from the pre-study. The methodology differs in the following points. The decompiler names were blinded so as not to bias the participants.

And the study was not conducted in the lab but via our online study platform. This decision was made for several reasons: Firstly, not all of the students who have completed the malware bootcamp were still living locally and we wanted to maximise our recruiting pool, since par-ticipants at this level are very scarce. We also wanted to conduct the study with professional malware analysts and it is unrealistic to expect them to come to the lab. We decided to conduct the entire study online, to keep the results comparable.

Variables and Conditions

In our experiment, we have two independent variables:

1. Decompiler Decompiler used to solve a given task and has three conditions: Dream⁺⁺, Dream, andHex-Rays. Hex-Rays is the leading industry decompiler that is widely used by malware analysts. Therefore, we compare Dream⁺⁺to Hex-Rays to examine whether our approach improves the current state of malware analysis. We tested the latest Hex-Rays version, which is 2.2.0.150413 as of this writing. Also, we compare Dream⁺⁺ to the original Dreamdecompiler to evaluate the usefulness of the extensions presented in Chapter 4.

2. Difficulty A within-subjects factor that represents the difficulty of the task. Based on the results from our pre-study (§5.1.2), we grouped the tasks according to their difficulty into two groups (mediumandhard), each containing three tasks.

Condition Assignment

We chose a within subjects design since personal skill is a strong factor in performance. To avoid learning and fatigue effects in our within-study design, the order in which participants used decompilers within each difficulty level, but also the difficulty levels were permutated using the counterbalanced measures design. Figure 5.1 shows the details of our counterbalance design: Within each difficulty level, there are 6 possibilities to order the three decompilers. The two difficulty levels are also permutated (red vs. black in the figure). We opted to balance on

H D D⁺⁺ H D D⁺⁺

D D⁺⁺ H D D⁺⁺ H D⁺⁺ H D D⁺⁺ H D H D⁺⁺ D H D⁺⁺ D D H D⁺⁺ D H D⁺⁺

D⁺⁺ D H D⁺⁺ D H

H D D⁺⁺ H D D⁺⁺

D⁺⁺ D H D⁺⁺ D H

... ...

counterbalancingdecompilerorder counterbalancingtaskdifficultylevel

Figure 5.1: Counterbalancing the order of decompiler and difficulty levels. Nodes in each horizontal sequence represent the tasks performed by one participant. Letters denote the used decompiler for the task and colors represent task difficulty level: medium (black) or hard (red).

difficulty level instead of task level since this gives us a counterbalance permutations of 12 (3!∗2!) instead of 4320 (3!∗6!). Since we could not hope to recruit 4320 participants we opted for the compromise of recruiting multiples of 12 participants using all rows of our counter.

Counterbalancing the order of difficulty level doubles the total numbers of possible orderings.

This design ensures that each decompiler and each difficulty level gets the same exposure across the study and minimizes the overall learning and fatigue effects. This also guarantees that each participant gets the same number of medium and hard questions for each decompiler.

This is important to control for individual differences between participants and avoid skewing the results by eliminating the possibility of a skilled and motivated participant performing all of her tasks using one decompiler, while a less skilled participant performs her tasks with another decompiler.

User Perception

After finishing each task, participants are shown a brief questionnaire, where they can score the quality of the code produced by the decompiler, and a text field for additional feedback. Here, the participants are able to see the code again. We asked a total of 8 questions, 6 on readability properties and 2 on trust issues. Similar to the System Usability Score (SUS) (SUS) [14], the questions are counterbalanced (positive/negative) to minimize the response bias, e.g., "This code was easily readable"and"It was strenuous to understand what this code did". The full question set can be found in Table 5.2.

Statement

Strongly

disagree Disagree Neutral Agree Strongly agree

This code was easily readable ◦ ◦ ◦ ◦ ◦

It was strenuous to understand what this

code did ◦ ◦ ◦ ◦ ◦

This code looks similar to the way I would

write code ◦ ◦ ◦ ◦ ◦

It was hard to understand what the variables

mean ◦ ◦ ◦ ◦ ◦

It was pleasant to work with this code ◦ ◦ ◦ ◦ ◦

I am sure that I correctly understood what

this code does ◦ ◦ ◦ ◦ ◦

I trust that the decompiled code is correct ◦ ◦ ◦ ◦ ◦

I would rather analyze the assembly code ◦ ◦ ◦ ◦ ◦

Table 5.2: Questions after each task.

Overall rating. In addition to the questionnaire after each task, at the end of the study, we asked the participants about an overall rating on a scale from 1 (worst) to 10 (best). During this step, participants were shown the code snippets for every task and every decompiler side by side to facilitate the direct comparison. To avoid biasing the participants the decompilers were named M, P and R.

Statistical Testing

For all statistical hypothesis testing, we opted for the common significance level of α = 0.05.

To account for multiple testing, all p-values are reported in the Holm-Bonferroni corrected version [50].

Continuous tests such as time intervals or user-ratings are tested with a Holm-Bonferroni corrected Mann–Whitney U test (two-tailed). Rather then testing all pairs for the pairwise comparison, we only perform tests with Dream⁺⁺ (Dream⁺⁺ vs. Dreamand Dream⁺⁺ vs.

Hex-Rays). The effect size is reported by mean comparisons and the usage of the common language effect sizemethod. Categorical contingency comparisons are tested with the two-tailed Holm-Bonferroni corrected Barnard’s Exact test.