I used hopper disassembler to see if there was any strange activity on this particular mov file. What was bizarre and unexpected was This .mov file is particularly strange such as it seems to lower the audio quality on people's computers who play the video.

I found processes in the middle of the file which I thought would just be data. Is this normal? enter image description here

  • 4
    Am I right that you simply use some non-code binary data (like a video file but it can also be the random data) and try to interpret these as code? If it will never be used as code then it makes no sense to look at it like it would be code. This would be similar to treating an exe file as audio data and then asking what kind of strange messages you hear. Jan 7, 2017 at 6:06
  • Right, but you can actually see these are devoloped processes and not just pure randomness. The codes connect to each other and you can actually make out what is happening (to an extent) if I I click on some of the other modes. Is it possible I can upload more pictures than just one? It is kind of cool because the code is way too organized to just be random data. I noticed in audio files there will be header related processes in the beggining and the rest will be just data. Jan 7, 2017 at 6:16
  • Although I have an unfortunate habit of being blinded by preconcieved notions when searching for things, so I am not saying I am correct. Jan 7, 2017 at 6:19

1 Answer 1


It is kind of cool because the code is way too organized to just be random data.

The only thing that makes this credible is the large amount of x86 jump-like 'opcodes' in the video (7a-7f). What makes it less likely is the memory addresses: the pointers in that piece of disassembly reference edi + > 0x75000000 and - > 0x50000000. This is not entirely impossible, but is highly unusual. If you look at the top instruction, AAD, this is entirely out of place:

The AAD instruction is only useful when it precedes a DIV instruction that divides (binary division) the adjusted value in the AX register by an unpacked BCD value. http://x86.renejeschke.de/html/file_module_x86_id_2.html

So my impression is that you simply have a very forgiving disassembler that will try to make sense of anything you feed it. If you're still unconvinced, give us the file so we can look at it.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .