The magic of Gradle: create Windows installers, Debian packages, manage a PPA, and optional sub-projects
Gradle is great build tool. Compared to Ant or Maven, it’s so much easier to use and write proper code for it — it’s unbelievable at times. A little while ago, I switched from an ugly Ant/Maven installation to Gradle with my open source project Syncany. Ever since then, I am simply amazed about what Gradle can do. Granted, it’s not always easy to understand and the lack of proper documentation and IDE support makes things more like a trial-and-error-based packaging experience. However, the amount of time that it saves is worth it.
Since I really like Gradle and I myself often have a hard time finding proper answers for the questions I have, I’d like to demonstrate a few solutions that I have come up with. In particular, I’ll describe how to create a Windows installer using Inno Setup under Linux, create Debian packages and manage a PPA (debuild/dput) as well as how to add an optional Gradle sub-project.
If you have a little bit of cryptography know-how, you’ve heard of GCM, EAX and other Authenticated Encryption with Associated Data (AEAD) block cipher modes of operation. If you haven’t, AEAD modes not only encrypt data, but also authenticate it so that the ciphertext cannot be tampered without detection. In addition to that, AEAD modes can addionally authenticate additional (unencrypted) data — header data for example.
Java’s cryptography interface abstracts the underlying cipher very neatly. If you don’t have any associated data, using an AEAD mode is just like using a mode that doesn’t protect ciphertext integrity: Independent of the actual cipher and mode you are using, the Cipher class behaves identical once it has been initialized. For stream processing, the JDK additionally offers a CipherOutputStream and CipherInputStream. Input and output streams are very easy to nest so that one can compress, encrypt and sign data just by chaining different streams.
So far so good. So what’s the problem? The problem is that the CipherInputStream is terribly broken when used with an AEAD mode. In this post, I’d like to demonstrate how.
I recently published a blog post about my open source file sync project Syncany. I explained the main idea of the project and also went into some of the details about where the development is headed. The post was the first of a series I am planning to write — showing what the project is about from different angles.
While the first post had a few technical elements, it mostly discussed the project’s process and its high level goals and ideas. In this second article, I’d like to go beyond the high level concepts and go a lot deeper into the different packages and modules of the software. Why, you ask? Because I think it might be interesting of others and because I believe that supporters and other developers will benefit from it.
Many many moons ago, I started Syncany, a small open source file synchronization project that allows users to backup and share certain folders of their workstations using any kind of storage, e.g. FTP, Amazon S3 or Google Storage.
At the time of the initial annoucement of the project (May 2011), there was a big hype around it. I received many e-mails and lots of support from people around the world. People were excited because the features Syncany offers are great: File synchronization à la Dropbox, paired with storage flexibility (use-your-own), client-side encryption (sorry about that, NSA!), and intelligent versioning.
At the time, I didn’t actually release a runnable version of Syncany. The sole purpose of the announcement (on WebUpd8 and on the Ubuntu Podcast) was to get developers excited about the project in order to get help for the last steps of creating a somewhat stable release. Unfortunately, I was further away from this “stable release” than I could have imagined.
In this blog post, I’d like to recap the idea behind Syncany, what went wrong with the development, and how I brought the project back on track (or so I believe). I’ll also talk about what I plan to do with Syncany and how people can help (if they still want).
I recently demonstrated how to perform a man-in-the-middle attack on HTTP(S) connections using mitmproxy. While mitmproxy works just great for HTTP-based communication, it does not understand other TLS/SSL-based traffic such as FTPS, SMTP over SSL, IMAP over SSL or any other protocol wrapped in TLS/SSL.
SSLsplit is a generic transparent TLS/SSL proxy for performing man-in-the-middle attacks on all kinds of secure communication protocols. Using SSLsplit, one can intercept and save SSL-based traffic and thereby listen in on any secure connection.
The Domain Name System (DNS) is one of the fundamental services of the Internet. By resolving domain names to IP addresses, it makes routing of IP packets possible and thereby lets browsers and other clients connect to remote servers using all kinds of protocols. By blindly connecting to the IP address returned by the DNS server, however, users put a lot of trust into DNS, because by default, DNS responses are not validated or verified.
In this blog post, I’d like to demonstrate how to easily set up a DNS server that allows you to easily forge certain entries manually — thereby allowing you to either block certain domains from your network or to pretend that you are a certain website. This scenario is commonly referred to as DNS forgery or DNS spoofing.
I recently discovered that once you have acquired your WhatsApp account password, it’s relatively easy to send and receive WhatsApp messages via PHP. Using the PHP-based framework WhatsAPI, a simple WhatsApp notifier script only has a dozen lines of code.
This tiny tutorial shows how to use the two very basic functions of WhatsAPI, namely to send simple outgoing messages to any number and to listen for new incoming messages from your own WhatsApp account. This is the second part of a two-part tutorial. The first part demonstrated how to sniff the WhatsApp password from your Android phone or iPhone.
WhatsApp is a very popular SMS-like messenger for smartphones, but it’s unfortunately only available for smartphones right now. If you want to use other tools or write web applications that send or receive WhatsApp messages (e.g. WhatsAPI), you have to find a way to sniff the WhatsApp password from your smartphone. Until recently, this password was just an MD5 hash of your IMEI (or MAC address), but that has changed when that was uncovered. Since then, the WhatsApp server assigns a password to each device/account when it first registers.
This tutorial demonstrates how to capture the WhatsApp password of your WhatsApp account using the SSL/TLS proxy mitmproxy. Once you have this password, you can use it to communicate with the WhatsApp servers directly or via a framework. This is the first part of a two-part tutorial. The second part demonstrates how to send and receive WhatsApp messages via PHP.
Capturing HTTP and HTTPS traffic on your own machine is quite simple: Using tools like Wireshark or Firebug, sniffing the local connections is only a matter of seconds. Capturing and/or altering the HTTP/HTTPS traffic of other machines in your network (such as your smartphone or other laptops) on the other hand is not so easy. Especially sniffing into SSL-secured HTTPS-connections seems impossible at first. Using mitmproxy, however, makes this possible in a very easy and straight forward way.
This small tutorial shows how to use mitmproxy to transparently sniff into and alter (!) HTTPS connections of your phone or other devices in your network.