The Central Deployed A Hack to Mount an Exploit by Android Debug Bridge from my Nowhere-Ever-User-Connected Huawei Y6 2019 (3)
(No. 0) No. 1 No. 2 No. 3 No. 4 No. 5
This page is for making things even clearer in some aspects. I'll also try and make the analysis understandable to anyone with enough desire and time to learn, anyone with the basic skills in Unix (or probably also users of Cygwin on Windows, but I have no time to test those).
I'll teach non-advanced readers how to extract the complete video that is only shown overlaid in the video of the first page, i.e. on that page the video that I originally "screen recorded" on Huawei Y6, and which I scaled down to fit overlayed in my computer's screencast, is completely contained in the network dump of the second page.
And I'll give all tips necessary to extract it from the dump.
You might want to first read the first page and the second page, and, if you then want to follow here, download that network dump into somewhere clean and (initially) empty where you have all the privs as $USER.
Now you can either get my tshark-streams program and run it on the downloaded network dump.
$ tshark-streams.sh -r dump_190628_0906_gdO.pcap -Y "tcp.stream==19"
or extract tcp.stream 19 with Wireshark, selecting "raw" and naming is as below. Either should get you
$ ls -ABgo dump_190628_0906_gdO_s019.bin -rw-r--r-- 1 18889943 2019-07-20 13:21 dump_190628_0906_gdO_s019.bin $ sha256sum dump_190628_0906_gdO_s019.bin c7a85d277a93f03c5c751f3e5431a994ae47bc4d346922e8f3285b90f722ba4d dump_190628_0906_gdO_s019.bin $
Go no further unless you get that exact file for yourself. I hope you do.
This is the next command to run:
$ tail -c+166 dump_190628_0906_gdO_s019.bin | head -c-16 > SVID_20190628_043533_1_re.mp4
I have the original Y6 "screen recorded" video and can show you where this step gets us:
$ ls -ABgotr SVID_20190628_043533_1.mp4 SVID_20190628_043533_1_re.mp4 -rw-r----- 1 18887458 2019-06-28 02:59 SVID_20190628_043533_1.mp4 -rw-r--r-- 1 18889762 2019-07-04 14:49 SVID_20190628_043533_1_re.mp4 $
We could, below, use "hexdump", but shorter "hd", a symlink to hexdump, is quicker.
You surely couldn't play what you got so far, even though you will soon extract the complete video from it. That has 2304 bytes too many (18889762-18887458), and those are not at start or end:
$ hd -n50 SVID_20190628_043533_1_re.mp4 00000000 00 00 00 18 66 74 79 70 6d 70 34 32 00 00 00 00 |....ftypmp42....| 00000010 69 73 6f 6d 6d 70 34 32 00 00 0c 77 66 72 65 65 |isommp42...wfree| 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000032 $ hd -n50 SVID_20190628_043533_1.mp4 00000000 00 00 00 18 66 74 79 70 6d 70 34 32 00 00 00 00 |....ftypmp42....| 00000010 69 73 6f 6d 6d 70 34 32 00 00 0c 77 66 72 65 65 |isommp42...wfree| 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000032 $ tail -c50 SVID_20190628_043533_1_re.mp4 | hd 00000000 dc ff 01 15 25 3e 01 15 66 83 01 18 97 bc 01 18 |....%>..f.......| 00000010 e7 c1 01 19 6d 08 01 19 b5 0a 01 19 f6 a3 01 1a |....m...........| 00000020 3e a5 01 1a 80 69 01 1a c1 bc 01 1e 3c 67 01 1e |>....i......<g..| 00000030 7f cd |..| 00000032 $ tail -c50 SVID_20190628_043533_1.mp4 | hd 00000000 dc ff 01 15 25 3e 01 15 66 83 01 18 97 bc 01 18 |....%>..f.......| 00000010 e7 c1 01 19 6d 08 01 19 b5 0a 01 19 f6 a3 01 1a |....m...........| 00000020 3e a5 01 1a 80 69 01 1a c1 bc 01 1e 3c 67 01 1e |>....i......<g..| 00000030 7f cd |..| 00000032 $
Of course you don't have SVID_20190628_043533_1.mp4 yet, but you could check the above commands once (soon) that you do have it.
Rather the differing pieces are sparsed, as I had found out analysing it, in snippets of 8 bytes each, in 288 different places all over the file. 287 of those are same and one, the last, is slightly different. I wrote a script to remove those, which we'll soon use.
Let us now find the first instance of 8 bytes that differ.
$ cmp SVID_20190628_043533_1_re.mp4 SVID_20190628_043533_1.mp4 SVID_20190628_043533_1_re.mp4 SVID_20190628_043533_1.mp4 differ: byte 65537, line 273
Feel free to hexdump, head -c, and tail -c, (and other), that file to see for yourself, but I know it's the first 8 bytes starting at the number cmp told us is the snippet. So let us stow those 8 bytes into a file:
$ tail -c+65537 SVID_20190628_043533_1_re.mp4 | head -c8 > str
View that file in the appropriate way:
$ hd str 00000000 44 41 54 41 00 00 01 00 |DATA....| 00000008
Now download (it's also in the bottom with other necessary downloads) and use my script str-rm.pl:
$ chmod 755 str-rm.pl $ ./str-rm.pl SVID_20190628_043533_1_re.mp4 str
I now have (and on first read/follow you're lacking just the original --with no '_re' in the name-- ):
$ ls -ABgotr SVID_20190628_043533_1* -rw-r----- 1 18887458 2019-06-28 02:59 SVID_20190628_043533_1.mp4 -rw-r--r-- 1 18889762 2019-07-04 15:36 SVID_20190628_043533_1_re.mp4 -rw-r--r-- 1 18889762 2019-07-04 15:38 SVID_20190628_043533_1_re.mp4_cp -rw-r--r-- 1 18887466 2019-07-04 15:38 SVID_20190628_043533_1_re.mp4_mod $
You've gotten very close. But try, you still can't play that video (the latest creation, the mod, "mod" for "modified")! However, it's now only 8 bytes too much, somewhere.
$ cmp SVID_20190628_043533_1.mp4 SVID_20190628_043533_1_re.mp4_mod SVID_20190628_043533_1.mp4 SVID_20190628_043533_1_re.mp4_mod differ: byte 18874369, line 61948
Yup! That's very close. Let's get those 8 bytes into str_2:
$ tail -c+18874369 SVID_20190628_043533_1_re.mp4_mod | head -c8 > str_2 $ hd str 00000000 44 41 54 41 22 33 00 00 |DATA"3..| 00000008
And let's run my script for one last time:
$ ./str-rm.pl SVID_20190628_043533_1_re.mp4_mod str_2
The listing now is:
$ ls -ABgotr SVID_20190628_043533_1* -rw-r----- 1 18887458 2019-06-28 02:59 SVID_20190628_043533_1.mp4 -rw-r--r-- 1 18889762 2019-07-04 15:36 SVID_20190628_043533_1_re.mp4 -rw-r--r-- 1 18889762 2019-07-04 15:38 SVID_20190628_043533_1_re.mp4_cp -rw-r--r-- 1 18887466 2019-07-04 15:38 SVID_20190628_043533_1_re.mp4_mod -rw-r--r-- 1 18887466 2019-07-04 15:48 SVID_20190628_043533_1_re.mp4_mod_cp -rw-r--r-- 1 18887458 2019-07-04 15:48 SVID_20190628_043533_1_re.mp4_mod_mod $
I'm sorry I haven't taught my program to clean up after itself, but, unless you haven't got the video that you can now play, meaning, while verifying my procedure and writing the above, I got:
$ sha256sum SVID_20190628_043533_1.mp4 SVID_20190628_043533_1_re.mp4_mod_mod 574906280379fe38584704ffa64e175bbcc410bfcf0e918a80e2f3201174c93e SVID_20190628_043533_1.mp4 574906280379fe38584704ffa64e175bbcc410bfcf0e918a80e2f3201174c93e SVID_20190628_043533_1_re.mp4_mod_mod $you can first:
$ mv -iv SVID_20190628_043533_1_re.mp4_mod_mod SVID_20190628_043533_1.mp4and then you can clean it like this:
$ rm -v SVID_20190628_043533_1_re*
The video that remains to you is bit-by-bit the original video that Y6's own "screen recorder" program created, and which I manipulated with FFmpeg to overlay it in the video of the first page.
You can play it with whichever movie player you use, and this is what ffprobe (of the FFmpeg suite) tells of it:
$ ffprobe SVID_20190628_043533_1.mp4
[...]
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'SVID_20190628_043533_1.mp4':
Metadata:
major_brand : mp42
minor_version : 0
compatible_brands: isommp42
creation_time : 2019-06-28T02:42:22.000000Z
com.android.version: 9
Duration: 00:06:48.88, start: 0.000000, bitrate: 369 kb/s
Stream #0:0(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, mono, fltp, 96 kb/s (default)
Metadata:
creation_time : 2019-06-28T02:42:22.000000Z
handler_name : SoundHandle
Stream #0:1(eng): Video: h264 (Baseline) (avc1 / 0x31637661), yuv420p(tv, unknown/bt470bg/unknown), 590x1280, 271 kb/s, SAR 1:1 DAR 59:128, 3.72 fps, 4 tbr, 90k tbn, 180k tbc (default)
Metadata:
creation_time : 2019-06-28T02:42:22.000000Z
handler_name : VideoHandle
$
(NOTE 2019-07-20: checked: works with sole downloads, made minor edits, on the date as one of the edits shows, shows date same as of this note: "2019-07-20")
---
WARNING: Familiarity with and use of some Unix-like OS such as GNU/Linux or BSD, (or being able to use Cygwin on Windows but I haven't tested that yet) is required to be able to follow.
Most of the original files of this section are produced with my (primitive) set of scripts:
Notice there are different scripts there, some I use for minimal anonymization of the dumps (dump_perl_repl.sh). Ah, and another could be useful for downloading, instead of of click-downloading each file in a list (dump_dLo.sh). If not downloading uncenz, you can get it directly: https://raw.githubusercontent.com/miroR/uncenz/master/dump_dLo.sh or later version if that looks too old.
It's also available here locally.
For analysis/stream extraction I often use my modest and lacking in good programming practices, but doing what I created them for, scripts:
and:
as well as:
workPCAPs which can run tshark-streams and tshark-hosts-conv
( and from May 2018 also stream-cont.pl from program
on (a lot) of PCAP(s) (usually) non-interactively.
NOTE: A better way than my stream-cont, since recently to my writing of it, is in tshark. Pls. see how to extract files taught by a Wireshark core dev.
Readers are advised to try and analyze the traffic dumps for themselves, with the above programs (I also try to offer some educational usefulness to them). There would anyway be too little point posting all the streams and the listings that those would produce. I usually post just the ones among that produce which are crucial for the discussion in question.
And just another one thing: I post lots of command lines and snippets of scripts. Be aware that some of those are in HTML, so before using them, check that they correspond to what the page shows, and of course, report (see the contact page) back to me the typoes and errors if you find any.
The files necessary for this study are some from the download section of the second page, as well as:
str-rm.pland verify to: ls-1pg3.sum signed by: ls-1pg3.sum.asc
( If you have issues downloading str-rm.pl, pls. try downloading str-rm.gz, but remember to gunzip it and rename the script str-rm.pl ... Apparently it was/is my hoster banning perl scripts... )
