The summer is coming to the end as well as my GSoC17 happy days. So, now it’s time to sum up the results and say goodbye to the GSoC until the next year.
Working on the Heralding project was awesome experience for me. I feel I did something helpful, fun and challenging at the same time. I hadn’t wanted anything else before the summer!
Hi, I’m Matthew Shao from China. This year, I got the honor to be selected as a Google Summer of Code student for the mitmproxy project. With the help of my kindly mentors Maximilian Hils and Clemens Brunner, I managed to improve the source code of mitmweb, which is a web interface for mitmproxy, and added some exciting new features for it. Here I’m going to present you the work I’ve done during this fulfilling summer.
At the end of February we were very happy to announce that The Honeynet Project had once again been selected to be a mentoring organization for Google Summer of Code (GSoC) 2017. Since then, there has a been a flurry of activity: We received more than 50 project proposals during the application phase, selected 14 fantastic students, set them up to work with us during the community bonding period, and now completed the first month of actual work! Now that the first tangible results are tickling in, it’s time to take a closer look at our students and see what they have achieved so far.
With Google Summer of Code (GSoC) 2017 being around the corner, we’d like to do a short flashback to 2016, our most successful GSoC year for mitmproxy so far! GSoC 2016 was mitmproxy’s fourth time participating in the program under the umbrella of the Honeynet Project. For the first time, we were able to mentor three students over the summer to work on both our Python core and the brand new web interface. As a major milestone, mitmproxy is now a Python 3 project and has a fantastic user interface that even works on Windows. With these improvements in, we finally decided to pull the trigger and called it the mitmproxy 1.0 release!
After successfully participating in GSoC between 2009 and 2016, and having created or extended many honeynet technologies that have since gone on to become industry standard tools, we are very happy to annouce that The Honeynet Project has applied to be a mentoring organization once again in GSoC 2017.
This year sees significant changes in the GSoC program with a new payment model and an added third evaluation! We are excited about those changes and very curious to see how they play out. In addition to the program changes at Google, we are also trying out some ways to improve our students’ experience. Most notably, all our potential mentors have already joined the new GSoC Slack channel and we are excited to talk to you there!
Thug is a client honeypot that emulates a real web browser, fetches and executes any internal or external JavaScript, follows all redirects, downloadable files just like any browser would do, and collects the results in a mongodb collection. The purpose of this tool is to study, analyse and locate exploit kits and malicious websites. Thug’s analysis can be difficult to navigate or understand and this is where Rumal comes in. Rumal’s function is to be Thug’s GUI, providing users with trees, graphs, maps, tables and intuitive representations of Thug’s data.
CuckooML is a GSOC 2016 project by Kacper Sokol that aims to deliver the possibility to find similarities between malware samples based on static and dynamic analysis features of binaries submitted to Cuckoo Sandbox. By using anomaly detection techniques, such mechanism is able to cluster and identify new types of malware and can constitute an invaluable tool for security researchers.
Malware datasets tend to be relatively large and sparse. They are mostly made of categorical and string data, hence there is a strong need for good feature extraction approaches to obtain numerical vectors that can be feed into machine learning algorithms [e.g. Back to the Future: Malware Detection with Temporally Consistent Labels; Miller B., et al.]. Another common problem is concept drift, the continuous variation of malware statistical properties caused by never ending arms race between malware and antivirus developers. Unfortunately, this makes fitting the clusters even harder and requires the chosen approach to be either easy to re-train or be adaptable to the drift, with the latter option being more desirable.
At the end of February we were very happy to announce that The Honeynet Project had once again been selected to be a mentoring organization in Google Summer of Code (GSoC) 2016.
Since then, there as been a flurry of activity: GSoC 2016 student applications opened on March 14th at 19:00 UTC and closed on March 25th at 19:00 UTC. We received 54 student project applications, and our 24 mentors and org admins were hard at work in the following weeks assessing them and the students who applied. This is always the busiest part of GSoC for us, and with some significant changes to the GSoC program and supporting systems we suspected it might be one of the busiest times ever. But in fact, this year actually went pretty smoothly for us. We actually faced fewer difficult selection decisions than normal, which was a bit of a surprise.
As I blogged two weeks ago, after some great student projects between 2009 and 2015, The Honeynet Project had applied again this year to be a mentoring organization in Google Summer of Code (GSoC) 2016.
After a few anxious days of waiting, Google today published the official list of accepted GSoC 2016 mentoring orgizations. The great news if that we have been accepted once again. Hurrah!
GSoC 2016 student applications open on March 14th at 19:00 UTC and close on March 25th at 19:00 UTC.
Hi there, my name is Li Yuanchun and I’m glad to introduce DroidBot, a tool to improve the coverage of dynamic analysis.
As it is the case for malware targeting the desktop, static and dynamic analysis are also used for detection of Android malware. However, existing static analysis tools such as FlowDroid or DroidSafe lack accuracy because of specific characteristics of the Android framework like ICC (Inter-Component Communication), dynamic loading, alias, etc. While dynamic analysis is more reliable because it executes the target app in a real Android environment and monitors the behaviors during runtime, its effectiveness relays on the amount of code it is able to execute, this is, its *coverage*. Because some malicious behaviors only appear at certain states, the more states covered, the more malicious behaviors detected. The goal of DroidBot is to help achieving a higher coverage in automated dynamic analysis. In particular, DroidBox works like a robot interacting with the target app and tries to trigger as many malicious behaviors as possible.
The Android official tool for this kind of analysis used to be Monkey, which behaves similarly by generating pseudo-random streams of user events like clicks,touches, or gestures, as well as a number of system-level events. However, Monkey interacts with an Android app pretty much like its name indicates and lacks any context or semantics of the views (icons, buttons, etc.) in each app.