Daniel E. Krutz

A dataset of open-source Android applications

Android has grown to be the worlds most popular mobile platform with apps that are capable of doing everything from checking sports scores to purchasing stocks. In order to assist researchers and developers in better understanding the development process as well as the current state of the apps themselves, we present a large dataset of analyzed open-source Android applications and provide a brief analysis of the data, demonstrating potential usefulness. This dataset contains 1,179 applications, including 4,416 different versions of these apps and 435,680 total commits. Furthermore, for each app we include the analytical results obtained from several static analysis tools including Androguard, Sonar, and Stowaway. In order to better support the community in conducting research on the security characteristics of the apps, our large analytical dataset comes with the detailed information including various versions of AndroidManifest.xml files and synthesized information such as permissions, intents, and minimum SDK. We collected 13,036 commits of the manifest files and recorded over 69,707 total permissions used. The results and a brief set of analytics are presented on our website: http://androsec.rit.edu.

CCCD: Concolic code clone detection

Code clones are multiple code fragments that produce similar results when provided the same input. Prior research has shown that clones can be harmful since they elevate maintenance costs, increase the number of bugs caused by inconsistent changes to cloned code and may decrease programmer compre-hensibility due to the increased size of the code base. To assist in the detection of code clones, we propose a new tool known as Concolic Code Clone Discovery (CCCD). CCCD is the first known clone detection tool that uses concolic analysis as its primary component and is one of only three known techniques which are able to reliably detect the most complicated kind of clones, type-4 clones.

Using a real world project in a software testing course

Although testing often accounts for 50% of the budget of a typical software project, the subject of software testing is often overlooked in computing curriculum. Students often view testing as a boring and unnecessary task, and education is usually focused on building software, not ensuring its quality. Previous works have focused on either making the subject of testing more exciting for students or on a more potent lecture-based learning process. At the Department of Software Engineering at the Rochester Institute of Technology, recent efforts have been focused on the project component of our Software Testing course as an area of innovation. Rather than previous methods such as a tightly controlled and repetitive testbed, our students are allowed to choose a real-world, open source project to test throughout the term. With the instructor as both counsel and client, students are expected to deliver a test plan, a final report, and several class-wide presentations. This project has achieved significant student praise; qualitative and quantitative feedback demonstrates both increased satisfaction and fulfilled curricular requirements. Students enjoy the real-world aspect of the project and the ability to work with relevant applications and technologies. This paper outlines the project details and educational goals.

A code clone oracle

Code clones are functionally equivalent code segments. De- tecting code clones is important for determining bugs, fixes and software reuse. Code clone detection is also essential for developing fast and precise code search algorithms. How- ever, the challenge of such research is to evaluate that the clones detected are indeed functionally equivalent, consider- ing the majority of clones are not textual or even syntacti- cally identical. The goal of this work is to generate a set of method level code clones with a high confidence to help to evaluate future code clone detection and code search tools to evaluate their techniques. We selected three open source programs, Apache, Python and PostgreSQL, and randomly sampled a total of 1536 function pairs. To confirm whether or not these function pairs indicate a clone and what types of clones they belong to, we recruited three experts who have experience in code clone research and four students who have experience in programming for manual inspection. For confi- dence of the data, the experts consulted multiple code clone detection tools to make the consensus. To assist manual inspection, we built a tool to automatically load function pairs of interest and record the manual inspection results. We found that none of the 66 pairs are textual identical type- 1 clones, and 9 pairs are type-4 clones. Our data is available at: http://phd.gccis.rit.edu/weile/data/cloneoracle/.

Instilling a software engineering mindset through freshman Seminar

Student retention is a challenge faced by all engineering programs. Our first year software engineering students have schedules filled with computer science, mathematics, science and humanities. The lack of any exposure to engineering meant some students, expressing a dislike for software engineering, left the program before they had any exposure to the discipline. To address this issue, we created a one credit Software Engineering Freshman Seminar, which all entering students take in their first term at RIT. This lets us insure student/faculty contact early in the program, as well as providing an opportunity to introduce engineering concepts and practices early in each students program of study. This paper discusses the seminars current incarnation. In particular, we focus on those aspects of the course which help students identify with software engineering as a profession. The challenge we face is achieving this goal with students whose technical knowledge and skills are modest. We have settled on an approach that provides experience with teamwork, requirements elicitation, and the effects of change, and addressing professional ethics. These in-class activities are complemented by an assignment to interview a practicing software engineer and to write an interview summary for discussion. This activity ensemble serves to disabuse students of the notion that software engineering is little more than programming, or that the discipline is identical to computer science. Should a student exit the program at this point, at least he or she knows a bit about what they are leaving behind.

Examining the effectiveness of using concolic analysis to detect code clones

During the initial construction and subsequent maintenance of an application, duplication of functionality is common, whether intentional or otherwise. This replicated functionality, known as a code clone, has a diverse set of causes and can have moderate to severe adverse effects on a software project in a variety of ways. A code clone is defined as multiple code fragments that produce similar results when provided the same input. While there is an array of powerful clone detection tools, most suffer from a variety of drawbacks including, most importantly, the inability to accurately and reliably detect the more difficult clone types. This paper presents a new technique for detecting code clones based on concolic analysis, which uses a mixture of concrete and symbolic values to traverse a large and diverse portion of the source code. By performing concolic analysis on the targeted source code and then examining the holistic output for similarities, code clone candidates can be consistently identified. We found that concolic analysis was able to accurately and reliably discover all four types of code clones with an average precision of .8, recall of .91, F-score of .85 and an accuracy of .99.

Experiencing disruptive behavior in a team using “moles”

The ability to work on a team is a paramount skill for every engineer. The capability to understand, identify and work through team problems will significantly enhance the engineers ability to deliver a high quality product on time and within budget. Far too often, however, the experience of working as a team, with its challenges, is overlooked in the students education. The Department of Software Engineering at Rochester Institute of Technology introduced an activity in their Freshman Seminar course to help students work in a team-based environment. The specific focus was interacting with problematic team members. This team activity involved student “moles” covertly being inserted to act in a disruptive fashion. At the end of the activity, the teams reassembled to discuss the task the team had been assigned to do. The instructor revealed the role of the “moles” at this point, and the teams discussed the effect their behaviors had on team effectiveness and the strategies used to deal with the disruptive behaviors. The students have praised the activity, finding it to be different, exciting and educational. This paper describes the “mole” activity, our observations of the results, and provides suggestions for future use in coursework.

CATE: concolic Android testing using Java pathfinder for Android applications

Like all software, Android applications are not immune to bugs, security vulnerabilities, and a wide range of other issues. Concolic analysis, a hybrid software verification technique which performs symbolic execution along with a concrete execution path, has been used for a variety of purposes including software testing, code clone detection, and security-related activities. We created a new publicly available concolic analysis tool for analyzing Android applications: Concolic Android TEster (CATE). Building on Java Path Finder (JPF-SPF), this tool performs concolic analysis on a raw Android application file (or source code) and provides output in a useful and easy to understand format.

Darwin: a static analysis dataset of malicious and benign Android apps

The Android platform comprises the vast majority of the mobile market. Unfortunately, Android apps are not immune to issues that plague conventional software including security vulnerabilities, bugs, and permission-based problems. In order to address these issues, we need a better understanding of the apps we use everyday. Over the course of more than a year, we collected and reverse engineered 64,868 Android apps from the Google Play store as well as 1,669 malware samples collected from several sources. Each app was analyzed using several static analysis tools to collect a variety of quality and security related information. The apps spanned 41 different categories, and constituted a total of 576,174 permissions, 39,780 unique signing keys and 125,159 over-permissions. We present the dataset of these apps, and a sample set of analytics, on our website---http://darwin.rit.edu---with the option of downloading the dataset for offline evaluation.

Enhancing the educational experience for deaf and hard of hearing students in software engineering

Software engineering is largely a communication-driven, team-oriented discipline. There are numerous hurdles for ensuring proper communication and interaction between all project stakeholders, including physical, technological, and cultural barriers. These obstructions not only affect software engineering in industry, but in academia as well. One possible issue that is often overlooked in software engineering education is how to best educate Deaf and hard-of-hearing (Deaf/HoH) students, and how to fully engage them in the classroom. In this paper, we present our experiences in teaching software engineering to Deaf/HoH students. In the classroom, these students work very closely in activities and on project teams with their hearing peers. We also present recommendations for creating a more robust software engineering educational experience for not only Deaf/HoH students, but for hearing students as well. We encourage instructors not only in software engineering programs, but in other computing disciplines to consider our recommendations and observations in order to enhance the educational experience for all students in the classroom, whether Deaf/HoH or hearing.