During the Hack in the Box Amsterdam 2015 conference (28,29 May 2015) we participated for the 3rd time in a row with team Hack.ERS in the CTF game. Once again the team included both me and GijsÂ from the Eindbazen team andÂ RileyÂ as the 3rd player. Multiple other Eindbazen members organized the CTF just as in the past years. This write-up contains some of the challenges we solved during the CTF, I only created write-ups of the challenges for which I had enough notes, but I did include the challenge descriptions and files for all the challenges where possible.
We ended on the 3rd place with the same amount of points as the second place (but just slightly later submitted the last solve). Which results in getting a top 3 position for 3 years in a row (2nd in 2013, 1st in 2014)
Continue reading “HitB 2015 CTF write ups”
During the Hack in the Box Amsterdam 2014 conference we participated with the Hack.ERS team of Deloitte in the CTF game. The team included both me and Gijs from the Eindbazen team, while multiple other Eindbazen members organized the CTF. While this might sounds weird it actually meant that the organizing Eindbazen really liked to see us squirm while working on the challenges they created.
This write-up contains some of the challenges we solved during the CTF, I only created write-ups of the challenges for which I had enough notes.
Continue reading “HitB 2014 CTF write ups”
With theÂ Eindbazen CTF team, weÂ hosted the CTF (ebCTF) during the hackers eventÂ OHM2013. To generate some awareness about the CTF and OHM2013 event we also held a Teaser round some time before it. Besides full-filling an organizers role I also created multiple challenges for both the teaser round and the CTF.Â For the teaser round I created the challenges BIN100 and FOR100, and for the main CTF I created the challenges BIN100 (together with asby), BIN200, BIN400 and NET400 (together with the NFI). This write-upÂ contains the solutions, background info and source codes of the challenges I have worked on. Feel free to use anything from this write-up including source codes, as long as it is for non-commercial usage and please provide credits were appropriate. For commercial usage, please contact me to discuss.
Continue reading “Eindbazen ebCTF write-ups”
More than two years ago I worked on meaningful MD5 collisions, especially creating executables files, but I never finished my write up about this until now (hurray for having a sabbatical 😉 ). The idea behind this project was to create multiple executables with the same MD5, but with different behavior. I ended up creating a Perl script which enables you to create a simple skeleton source code which you can use as a basis for your own code, after compilation you can use the same Perl script to create the multiple executables with different behavior. This project does not show a new way to create MD5 collisions, but makes it easy to exploit the weakness by creating executables with MD5 collisions.Â I based my project on existing research such as HashClash, and used fastcollÂ to create the collisions. For further information about MD5 collisions, I would like to refer to HashClash.
The MD5 collision executables can potentially be a security issue for MD5 whitelisting, which is still used by some security products. An attacker could potentially first send an executable which is considered safe and then its counterpart which is evil. Since the files will have the same MD5 hash value the first file will have the second file white-listed. The files could further have impact on products which use MD5 hash values to uniquely identify files, such as certain forensics software.
The whole project was inspired by my firstÂ MD5 collision experience while playing SmashTheStackÂ IOÂ and by forensicÂ products using MD5 hash values as unique identifiers for files.
Continue reading “Meaningful MD5 Collisions: Creating executables”
After posting information on my website about the Perl2Exe reversing article I published before, I got a comment with a question on how to perform the same “trick” on 64-bit Perl2Exe executables. Sadly enough at that time there was no free and easy to use 64-bit debugger available to create a similar approach for 64-bit Perl2Exe executables. However, that has changed with the release ofÂ x64_dbg. While I am still looking forward to theÂ 64-bit version of OllyDbg, this new debugger looks very promising and with it I was able to create a fairly simple way of recovering the Perl sourcecode of 64-bit Perl2Exe executables. I decided to create this fairly short write-up about how to do this, which can also be used as a first hands-on with x64_dbg.
For reference, the approach for 32-bit Perl2Exe executables (using OllyDbg) can be found here, which also describes how Perl2Exe works and what the idea is behind the approach that we also follow in this article. These details have been left out of this current article.
Update 15-02-2017: User Julian commented on this article below that the instructions did not work on binaries created with Perl2Exe version 24. Updated instructions for this version can be found at the end of the article.
Continue reading “Perl2Exe back to Perl – 64-bit (with x64_dbg)”
In the past 1,5 year I have been playing a bit with Home AutomationÂ (or Domotics / Domotica) systems. I initially bought the HomeWizard, but was pretty disappointed inÂ it. When the HomeWizard domotica system was introduced I expected a lot of it,Â sadly enough it has not been as great as I hoped and I am currently moving over to another system. Â One of the things that annoyed me of the HomeWizard is the inability to add other sensors to the setup which were not part of the supported hardware (which is pretty limited). I moved to the HomeWizard from a different (alarm) system which contained a lot of 433Mhz sensors which I could not hook up to the HomeWizard. Because I did not want to throw all these sensors away I built a middle-ware system with an Arduino and some code which can convert the non-supported codes in to HomeWizard supported codes (KaKu / CoCo style codes). The middle-ware receives a code and then translates that to a code which can be understood by the HomeWizard. Initially designed for usage with HomeWizard this same approach also worked with HomeSeer, Domotiga and Domoticz, which all did not support my sensors directly (most of them because of the usage of the RFXCOM).
Continue reading “Convert cheap 433Mhz sensors to KaKu/CoCo with an Arduino convertor”
Two years ago I published my Perl2Exe back to Perl article in Digital Forensics Magazine, more information can be found in my post here. Since I published this article in a magazine I was not allowed to post it on my own website as well, but since enough time has passed I am now allowed to publish the fullÂ article which can be found below.
Reverse engineering Perl2Exe back to Perl
Perl2Exe is a program which converts Perl source code to standalone Windows executable files which hide the Perl code. When a forensic investigator encounters a Perl2Exe program (for example malware) it can take a lot of effort to analyse these files. This article describes a new and easy to follow approach to recover the full Perl source code from these Perl2Exe executable files, making the analysis of these files much easier.
Continue reading “Perl2Exe back to Perl – 2014”
In the August issue of the Digital Forensics Magazine (DFM) my article on reverse engineering Perl2Exe can be found. The article describes a way to recover the source code of the Perl program back from the executable created with Perl2Exe program.
Reverse Engineering PERL2EXE Back to Perl
Perl2Exe is a program which converts Perl source code to standalone Windows executable files which hide the Perl code. When a forensic investigator encounters a Perl2Exe program (for example malware) it can take a lot of effort to analyse these files. This article describes a new and easy to follow approach to recover the full Perl source code from these Perl2Exe executable files, making the analysis of these files much easier..
Perl2Exe converts the source code of the Perl script by packing it inside a single executable together with a Perl interpreter. The Perl source code is included inside the executable in encrypted form and thus it cannot easily be recovered from the executable.
In the past there have been a couple of other projects to retrieve the Perl source code from Perl2Exe executable files (see boxout 1). However, none of these projects work with the current versions of Perl and Perl2Exe. In the past couple of years there have been a number of Perl2Exe versions released (see boxout 2) and each new version seems to break the previously found solutions to recover the Perl source code.
Continue reading “Reverse Engineering Perl2Exe back to Perl”
I recently ran into the issue that my new photo-camera (Samsung WB650) somehow decided to erase all the data of my SD card. Since the SD card was filled with a lot of photos and video files I decided to image the SD card and to try to recover my files. The photo files all were JPEGs, so it was pretty easy to recover them by using Scalpel. However the Video format this camera uses was not included in Scalpel so they weren’t recovered. To be able to recover the video files as well I created a Scalpel rule for them myself.
Continue reading “Samsung WB650 Video file Scalpel rule”
During the recent Defcon 19 CTF pre-qualifications, one of the challenges included to connect ‘quicker’ to a web server. While figuring out what the solution was for this challenge one of the things I tried was to send the HTTP GET request already in the TCP handshake stage. Sadly enough this had nothing to do with the real solution of this case, the real solution was making use of SPDY to connect to the server, this is also explained by one of the other teams in a write up here. However it was a nice exercise to create packets with scapy again and since I could not find a lot of information on the topic I decided to create this short write up on the topic.
Continue reading “Creating ACK-GET packets with scapy”