Transcriber’s note: this is copied mostly verbatim from the UFSC channel Discord chat on 2016-12-06. The commentary is mostly by Discord user Festercluck. I have trimmed away most intervening chat, but where another user’s question or comment seemed relevant for clarity I have maintained it < in angle brackets >.

I’ll lead with the exploit’s academic breakdown


On that page you will find a thorough explanation of the exploit. You will also find something called the drammer test app.

For those of you new here, I’m a software developer by trade. I will not send you dangerous shit. The worst thing that will happen in this process is that your browser will crash for a moment, and you may have to restart your phone.

Nothing permenant

The TL;DR version goes like this:

There are a series of exploits on Android devices that have to do with: the way Android parses MPEG-4 video (aka stagefright bug), and another that involves memory spraying (rowhammer).

Surprisingly, accomplishing the attack does NOT require you to play the video.

You can have it loaded on pause and it would be just as effective

You may have noted in previous conversations, or in your research, that UFSC videos contain an abundance of encoding errors.

Specifically, what we’re looking for are frames which change properties set earlier in the video. Things like setting the video size to 50x50, then later setting those values both to 0. The same can be done with the video length, and many other metadata type properties

A video containing these sort of strange changes are typically ignored by most players. Unfortunately Android’s implementation causes them to potentionally allow a buffer underrun attack.

By setting a previously large value to something small or 0 later in the video, then causing the parsing player to crash, a small window is opened where the underlying player can have the data that it loads swapped out from under it.

Or simply removed

When the player re-launches it has cached memory pointers which load whatever is in memory, giving the player access to memory it wasn’t intended to read.

The final step of the exploit we won’t be performing here, but that involves using something like javascript to read out these exploited bits and test for elevated access or secure data

This attack has already been proven and well documented.

Here is more in depth history


So, the videos are not an attempt to hack your phones

If you read through the history, you’ll realize that this attack keeps creeping up over and over again

Much of this is because there are so many different types of MPEG-4 frames which can allow for this sort of exploit

In the penetration testing world these hacks are quite valuable.

Now, I don’t mean on the black market.

< so still? >

More like competition

With prize money

There’s also the possibility that someone is running this as simply an early warning system

They’re trying to flesh out these attacks as early as possible in a benign way

Here’s what you’ll need to do to see the results yourself.


Nah, this isn’t dangerous.

Set the sliding bar to somewhere between 20-30%.

Your phone’s optimal setting may vary.

The sliding bar basically changes how hard the software will work your phone’s memory at attempting to produce the bug

If you install the app, you’ll understand. There’s not a lot to it.

Please spend the time to read the article and do a little vetting of the group offering the download if you’re worried about it. I didn’t write this thing, but a very reputable academic security testing group did.

Anyway, run it for a while. The indication that it has been successful is if you see a line that starts with the word “FLIP”

So, run drammer, and pay attention to the number of flips you get.

Don’t need to count exactly, just be aware.

Next, stop drammer.

After stopping drammer, load up on of the videos in chrome

Youtube RETIO, CRIMP, and the CLEAN series have all be especially effective.

Remember, you don’t even have to play the video. However, I’ve found that playing the video does increase the effect.

You will need to get the player to load the video though. For some phones this means you’ll at least need to start and pause it.

Now, switch back to drammer and start it again

You will notice a significant increase in the number of FLIP lines

on my HTC m8, they came almost non-stop

On certain videos he has accomplished causing the crash.

You can witness this by switching immediately back over to the video after starting drammer.

The browser will crash, sometimes reloading.

Some other videos will suddenly become unplayable after being perfectly playable before.

Generally completely shutting down the browser or restarting the phone will fix that

Some of these exploits have been fixed, so what you are seeing is libstagefright and the Android kernel stepping in to prevent you from reading memory you’re not supposed to

Rather, that process from doing so

So, MPEG-4 is not just .mp4

Hell, the exploit isn’t necessarily just mpeg.

It’s a problem with the video parsing library in android.

the idea of metadata frames exists in just about every codec out there

MPEG-4 just seems to have the most ways for it to be exploited

Codecs like vp* use a very similar system

< to be fair there is still a lot of unexplained pieces >


For instance, the account got banned once

Came back

But it’s obvious it’s not employees

My guess goes back to an academic institution being allowed to continue with it’s research

And see, the series, I’m very curious about the series

Are they variations on the attack, or are they meant to crash and load the next video in the series?

The greater the change in the values, the more memory which could be exploited

But also, the greater the change in the values, the more likely you’d cause the player to crash, possibly too early.

Anyone know where I can grab the old videos in their native format?

Note: UFSC’s videos are typically offered on youtube in 2 formats

mp4 and 3gp



There’s the article that I dissected this whole thing with

It’s explains why android as well

But tl;dr is that Android is the only one that wrote a poorly implemented parser

That and video is just so damn ubiquitous on phones

< I see, I suppose this may be what UFSC is doing but I don’t think that is the only thing. The whole presentation seems multi-layered. >

And this is where we all get to feel like dirty whores

Who the hell would continue to run these things if they knew that merely loading them was part one to an exploit?

part 2 can come from anywhere

I’m betting that there are some google analytics experiments out there running in the background checking for signs of the exploited videos

< stagefright targets android. and i’m not sure how audio plays into that

trying to read through it now… >

The primary target is video frames, not audio

Though if libstagefright parses it, and it has metadata which can be changed in a later frame, it’s a candidate

< By the way, do you still need a volunteer with an Android? >


I’m going to do it and video as well., I’ve already done it multiple times. But independent verification and all

I think the composites served 2 purposes

First, understand that fuzzing is, well, fuzzy.

You need to introduce logical but randomized patterns so you can look for discrepancies

Sending through a warped picture of yourself? Serves both the security purpose & the promotional purpose.

The more people trying to solve the puzzle, the better



Looks like we’ll see plenty of new stuff for a while

Another large batch found & fixed


Fixed and found

In that order

<Alright so what do I do?>


Go install that app

The links says “available”. It’s called Drammer