Yesterday I gave a talk for an Italian workshop on CTFs. The audience was ~200 Italian students at the beginning of their journey into CTFs / infosec / tech careers (~18-24 years old). These are very busy times, but I don't have the chance to reach many young students so often. And so, I took it :-)
Instead of a classic tech talk, I used this occasion to annoy them with "wisdom" accumulated over the last 10 years (!
The news is out: I left France, I'm no longer a professor at EURECOM, I joined the Malware Research Team at CISCO Talos, and I moved to beautiful Vienna. Big change :-)
I have been a professor for a bit more than three years, but I have had conflicted feelings about the "prof job" for a long time (even before finishing my PhD), it took me a couple of years to realize that I would eventually have needed to move on, and it took even more (mental) effort to actually make the call and leave.
Last week, an article by @campuscodi ZDNet caught my eye. The headline is: "Google could have fixed 2FA code-stealing flaw in Authenticator app years ago". The article refers to a blog post by NightWatch Cybersecurity.
This caught my eyes for two reasons: to the best of my knowledge, 1) protecting from a11y is not that easy (it's definitively not just a matter of adding one flag); 2) the article mentions that FLAG_SECURE could be used for this purpose.
This is a quick blog post discussing aoool, a challenge/service I wrote for DEFCON CTF Finals 2019 (co-hosted with the OOO team).
In short, aoool is a C++ web server with support for a custom nginx-like config and support for OSL, the OOO Scripting Language, a (simple) JITted language written from scratch.
Depending on the configuration, the server would interpret a given file as raw text or as osl. When interpreted as raw text, the server would just return the file to the user as-is.
This is a quick blog post discussing two of the challenges I wrote for DEFCON CTF Quals 2019 (co-hosted with the OOO team): Vitor and Tania.
Vitor Vitor is a multi-stage Android reversing chall, Matryoshka-style.
This app is a classic crackme: it gets a key from the user, and it prints VALID in case it's correct.
There were five stages, each of which would somehow decrypt and load the next one:
In the last couple of days, many reports (see XDA developers, The Hacker News) appeared about Google emailing apps developers about new restriction affecting the Android accessibility service (a11y, in short). The gist: in 30 days, apps should use a11y only to implement features to assist users with disabilities; Apps misusing a11y (even for benign purposes) will get kicked out from the store.
I am one of the many researchers that showed how a11y poses severe issues for Android security.
This is a write-up for the 0ctf 2016 quals "State of the ART" mobile/Android challenge worth 5 points. We (Shellphish) were one of the only three teams that solved it, and since I haven't seen any write-up on this, here is mine! Major props to @_antonio_bc_ and @subwire who heavily worked on this with me :)
Alright, here is the challenge. We were given one tar containing three files:
mmaps of a process running an Android app output of dex2oat command run over the Android app's Dalvik bytecode boot.
This is the write-up for solving "pcapin", a challenge from CSAW CTF 2015. It was in the "forensic" category, and it was worth it 150 points....may I say, 150 points my ass!?! This felt like a 1337 points challenge...at least :D
So, we have a pcap (links to all files at the end of the post), and we know that it contains the dump of some sort of file transfer protocol, and that a "not so sophisticated" encryption was used.
This write-up will describe the "behind the scene" of DexWare, a service I wrote for the iCTF 2013. To the best of my knowledge, this is the first service in the history of CTFs to be based on Dalvik-bytecode!! I hope this write-up will be a useful starting point for those who will attempt something similar!
You can find the source code and the compiled binaries on github (link). Also, feel free to ping me on twitter (@reyammer) for any questions.
ShellNoob 2.0 is out!! You might now ask with a mix of suspicion and astonishment:
what whaaat??
Yep, you got it right! A new version is out!
For those who haven't read the first blog post, ShellNoob is a shellcode writing toolkit that helps you dealing with the boring, error-prone, and painful steps, leaving only the fun part to you! At least that's the goal :)
From when I published the first version (exactly three months ago!
This is my write-up for the Defcon CTF Quals 2013 - \xff\xe4\xcc 5 (lena). I partecipated to the quals with the Shellphish team (we ended up in 7th place!), and I needed to spend an entire night with the great @cavedon (one of the Shellphish's secret weapon) to solve this challenge. Also, we probably wouldn't have made it without @adamdoupe, that monitored our health conditions when we were trying to finalize our exploit, during the following morning.
What if an unprivileged Android app could lock, instantaneously, any Android device out there? What if such an app exists and is also really simple to implement?
A few months ago, Antonio and I stumbled upon a paper titled Would You Mind Forking This Process? A Denial of Service attack on Android. In this paper, the authors describe a vulnerability they discovered related to Android's Zygote that could be exploited by mounting a DoS (Denial-of-Service) attack: this resulted in the target device becoming completely unresponsive after a minute or so.
Today I'm really happy to publicly release ShellNoob (and to publish my first blog post :-))
During the many CTFs I played, there always has been the need to manually write some shellcode (yep, most of time Metasploit is not enough, even if you are lucky and you get a working shellcode...)
Now, writing shellcode is always super fun, but some parts are extremely boring and error prone. And after googling for the n-th time "how to ", I just got tired and I wrote shellnoob.