Category Archives: Security

Are your devices secure? Firmware hacking

Filed under Arduino, Security

How to hack your firmware – this might seem like a complex topic. In some cases it is, but nowadays, this is not always the case.
Some unix skills and just a bit of social engineering might be enough to make your company or home insecure.
There are several ways through which a company or a person might have received a compromised device:

  • A company receives a demo hardware from the company in the mail, why not trying it?
  • The guy in the shop decided he wants to monitor his customers, how about quickly removing the seal and compromise the firmware?
  • The website sending firmware updates has been compromised (either from your side, for example through dns poisoning) or on their page
  • The firmware was downloaded from a strange internet source

There might be a few reasons more, but let’s get hands on and see how easy firmware hacking could be!I am trying this on my Arduino Yun, as it is using OpenWRT + squashfs. Squashfs is nowadays very used (see for example dd-wrt compatible devices).What we need is:

  • The firmware (in our case the Yun firmware is openwrt-ar71xx-generic-yun-16M-squashfs-sysupgrade.bin)
  • A Linux box. For this blog entry I will use Debian, but I guess the same will work under ubuntu and other debian based distros

It is worth noting at this point that I fully support Arduino’s choice of using an open solution such as OpenWRT, and squashfs is not the problem. Hacking firmwares is still possible even using proprietary formats, as long as the source of the firmware (or person handling the device before you) is not trusted.

Let’s first install the right tools. As root, run:
aptitude install squashfs-tools

The tools we need: unsquashfs and mksquashfs.Now, let’s get some information on the file:
unsquashfs -s openwrt-ar71xx-generic-yun-16M-squashfs-sysupgrade.bin

This should give an output such as below:
Found a valid SQUASHFS 4:0 superblock on openwrt-ar71xx-generic-yun-16M-squashfs-sysupgrade.bin.
Creation or last append time Sun Nov  9 01:25:00 2014
Filesystem size 7799.69 Kbytes (7.62 Mbytes)
Compression xz
Block size 131072
Filesystem is exportable via NFS
Inodes are compressed
Data is compressed
Fragments are compressed
Always_use_fragments option is not specified
Xattrs are compressed
Duplicates are removed
Number of fragments 130
Number of inodes 2083
Number of ids 1

In particular “Compression xz” will be useful to us when rebuilding the package.
Let’s now decompress the filesystem in a working directory:
unsquashfs openwrt-ar71xx-generic-yun-16M-squashfs-sysupgrade.bin

A new directory should now be present: squashfs-root. It will contain all the files of the router. The purpose of this article is of course only to demonstrate how we could compromise a firmware so will only create a simple example. Let’s create something that, at boot, will write under /tmp a file

First we go in /etc/init.d and create the script, which we will call “hackTest”.
The file will contain:
echo “This might be a virus :)” > /tmp/virusTest

Let’s make it executable now
chmod +x hackTest

…And link it to the correct start sequence in /etc/rc.d. In my case, I decided to set it to S94:
ln -s ../init.d/hackTest S94hackTest

Now all is good to go – let’s pack our squashfs. Go back to the folder containing squashfs-root and create the new firmware:
mksquashfs squashfs-root openwrt-ar71xx-generic-yun-16M-squashfs-sysupgrade.bin -comp xz

Note “-comp xz”, this is the compression that was specified on the file info above.
All is now ready. Update the Arduino, wait for the reboot.

Now, I understand that someone might think: isn’t it easier to just modify the system once booted up?
Well, this is true but on a factory reset things will go back to normal. Also, most of those devices provide a limited set of  read/write directories, so searching for issues if someone gets suspicious is a lot easier.

So what is the solution?
Well, make sure once the firmware is downloaded that the MD5 is correct using a different source to get the md5 strings (for example, your desktop). If your firmware was however modified, chances are it will not upload the firmware or might automatically modify the firmware during the install. This is quite a difficult matter to resolve, and if we are ever going to go back to a mainframe architecture in the future (i.e. Chromebook) this will become an ever bigger issue, and making the firmware proprietary is not the solution (see the various iOS hacks).

Google XSS game

Filed under Security

Well, this has been covered widely but can’t stop from writing about it in my blog, as I just had some time to play with it:
Google XSS game
It actually brought me back to the time when I had fun with text only games (good old MUDs!) :)

Now, if you haven’t tried it, I strongly suggest to give it a go – the aim is to make an alert() pop up in different scenarios.
I have to admit, I seriously struggled with #4 (like, hours), but it was well worth it. And reading the tips on the site is not cheating, they are just useful enough.

For #6, feel free to use mine ( – won’t spoil with details, just make sure certificate is ok on your machine before you use it) :)
And yes, it is safe I just put alert() in it!


Protonmail security review

Filed under Security

Note: Protonmail is still in beta, so things might change

Protonmail promises to deliver security to the mail world, accessible without any kind of monitoring from their side. As I write, their project on has 27 days to go and already reached 128% of the goal.
So, after all the media coverage received by Protonmail, is it really going to be the next alternative to gmail?
But most importantly, is it as secure as it is advertised?
Let’s look into some of its features…



The interface is very simple, no fuss. Gladly, no advertising so far based on “anonymous data” collected from our mail context. That is a good start I think.
As promised, the javascript side is not compressed, leaving a bit of transparency to the user, but I’ll get to it in a bit…

The interface to compose mails is also very simple; would be comparable to any standard webmail client, if it wasn’t for the encryption features on the right:

We can encrypt the mail and give it an expiration. I am not quite sure why would an email expire when saving the contents for offline reading would be very easy, but let’s move on…

Debugging a little bit, seems clear that we use our public key client side to encrypt our mail:

So, the base encryption is AES256.

I believe arguments are then built within #totalpackage and sent (where the pgp part is added for * emails):

Then the draft is created:

This is good news – they are using the openpgp.js library to encrypt the messages, so it really happens all on the client side. Ok, but actually, this can be done using thunderbird too or most mail clients. That said, having it javascript based will give me the opportunity to have my pgp data always with me, even on someone else’s device.

Anyway, I clicked in the beginning to send the document encrypted externally. It seems to me that this part:

is responsible for encrypting outbound messages. It looks to me this will encrypt only the message with an hashed AES256 pass (see encryptMessage function in the code above). Keep this in mind, we will get into it in a bit.

We then receive the email from protonmail. Obviously no receiver PK is checked since we don’t know it (and I can’t find a way to add them)


The question at this point is…

Are external mails kept just encrypted using a sha256 of our password using AES256?
It might seem like an OK solution now, but I bet in 5 years time hacking a sha256 won’t take so long. Even now with supercomputers won’t take long to break this SHA256. I personally don’t think at this stage protonmail offers an adequately secure external email.

In addition to that, answering to external emails now is impossible, but this might change.

Now, let’s forget about the AES256 scenario for a while. What are the other issues?
Well, there are no signature and no certificate authorities here, so anybody with access to the mail and the password (let’s assume someone is sniffing chats + mails) can actually get the data.
Ultimately, not using public keys, will lead to an additional exchange of keys, which in turn leads to a less secure solution.

All in all, this is a well thought system, though I think little privacy is offered with externally encrypted emails (which – in theory – can be decrypted by the server owners), and even our local emails might not stand the test of times (also, how scalable is it? Will we be able in the future to change algorithms without rebuilding the whole inbox?)

Never the less, my support goes to the guys, it is a great step forward to what we had before and even though there is room for improvement (and well, it is always possible my analysis has some flaws so welcome to comment) this I think is one way to make cryptography really accessible to anyone.

…Just one last heads-up. There are some pretty heavy limitations (in particular if you are used to Gmail space):
Screenshot - 21.06.2014 - 02:10:25

Plaid CTF

Filed under Generic, Security

Plaid hack catch the flag game – wanted to play a little bit before the weekend but seems that people would rather DDOS it.. I wonder why there must always be someone spoiling the game…Or is it a way to gain some time?

Updated source and binaries

Filed under Forensics, Security

New code and binaries out there!
It is now possible to set thresholds within the tool and there have been some stability improvements (though, still not exactly stable…)

I’ll publish the training videos on how to train new files in the next few days and start advertising the tool a bit more!

Youtube video uploaded!

Filed under Forensics, Security
Tagged as

added a youtube video on how to detect files – available in the “Projects” Section.