I came across CVE-2019-2107 that says

".... With CVE-2019-2107 the decoder/codec runs under mediacodec user and with properly "crafted" video (with tiles enabled - ps_pps->i1_tiles_enabled_flag) you can possibly do RCE."

Now after googling for a whole night, I still don't know HOW a malicious guy can "craft" this video file.

I tried to open the POC mp4 from the github repository of the researcher with OllyDbg, but it's a bad idea because the file is in mp4 format.

My questions are:

  1. How he could "craft" such file, with what IDE or language?
  2. How can I reproduce the POC based on the published one from github?
  3. How can I reverse engineer the MP4 POC?

I am looking for answers that give me an entry point to conduct research. I think this will help me in my university project, because it's a new and unique thesis.

closed as too broad by Steffen Ullrich, Xander, Graham Hill, A. Hersean, Rory Alsop Aug 15 at 13:50

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • In order to understand how to trigger the bug in the decoder and where to place your code you need to understand the specific file format (HVEC) first and you need to understand how the specific decoder handles this format. There is likely no IDE which will help you with understanding HVEC. – Steffen Ullrich Aug 11 at 8:59
  • I read about HVEC last night on their wikipedia page it's very rich with resources and information, but i knew the technology and it's features, i can make an HVEC video using Adobe After Effects or by an encoder for example BUT this guy created a 6kb video file with payload .. the main question is how he did it .. ! Not asking the code he wrote but how he compiled the mp4 ! – R00t_R3z Aug 11 at 9:55
  • My guess is that he wrote some custom HVEC writer or modified an existing one in order to create the malformed HVEC. And he found the right place to modify likely either by fuzzing and/or by reading the source code of the attacked program. If you want to know the exact details you probably need to ask the author of the exploit. – Steffen Ullrich Aug 11 at 10:09
  • contacted him with no response, then came to stackexchange – R00t_R3z Aug 11 at 12:08
  • 1
    I may be wrong, but it sort of sounds like you may not have much experience with exploit development. Have you tried the Corelan tutorials (link)? I hear good things about them if you're on windows. – Silver Aug 11 at 20:20

All files are just a string of bytes. An MP4 file means, depending on who you ask, a string of bytes that conforms to the MP4 standard, or that an MP4 player can do something with, or that has '00 00 00 18 66 74 79 70 6D 70 34 32' as the first twelve bytes (many file format standards always start with some fixed string of bytes so a program can look at just them to tell what kind of file it is. This is called a Magic Number). In principle you could craft a valid MP4 file with a hex editor, just typing in the bytes one by one, but since the MP4 standard is pretty complex it would be a lot of effort.

In the context of crafted exploit files, an MP4 file is one that the target MP4 player will read and say 'this is an MP4 file', before trying to process it. That might mean it has the magic number, or possibly just the extension '.mp4'. It can be crafted in any way you might create an arbitrary file, but probably by either modifying a program that creates mp4 files or taking a valid mp4 file and modifying it manually in a hex editor. Most crafted exploit files aren't actually truly valid but rather just pretending to be MP4 files (or whatever).

so, 1) He could craft it using any method of writing bytes to a file, but in practice probably did it by modifying something that produced or was a valid MP4 file already.

2) You can reproduce the bug by trying to play the poc file on a vulnerable android version (Android-7.0 Android-7.1.1 Android-7.1.2 Android-8.0 Android-8.1 Android-9. Android ID: A-130024844 apparently), or otherwise in an environment where it will be processed using a vulnerable version of Android Video Player.

3) You could put the vulnerable software in a debugger and see exactly what happens when you feed it hvec-crash-poc.mp4. Note that OllyDbg won't help you here, you need a debugger that works in an Android environment while OllyDbg is Windows-specific. From the screenshots on the GitHub page it looks like he's using GDB. I don't work with Android much so don't quote me on this, but I think the vulnerable software in question (Android Video Player) is a system service that you'd have to attach the debugger to, this will require a rooted Android (or Android emulator).

Not the answer you're looking for? Browse other questions tagged or ask your own question.