[017] IT9919 Hacking - part 2 - Hunting for Checksums

[Music] I am welcome back to the open tech lab so this video is the second part of a series where I've been experimenting with the media processor inside a lkv 373 which is a media extended device for sending HDMI video across a network and in my previous video I use this for capturing HDMI imagery and sending it into my PC and I'm interested in finding out if we can hack on this device because it's not perfect one of the main issues it has is that it spans the network with multicast packets which causes all the phone's attached to the Wi-Fi to run out of battery power rather quickly so it'd be interesting if we can change it and find out if it's got any hidden features so I'm interested in finding out more about the device to find out how the existing firmware works and maybe even it will provide an opportunity to write a firmware of our own so let's have a quick recap about what's going on on this board so there are two processors on the board u 2 and mu 1 and u 2 is a media encoder processor it is an ite 99 19 or something from that family it's hard to tell because the labels have been removed then non-standard labels on both chips but this chips job appears to be to capture the HDMI signal through the input port and encode it into h.264 which is then sent through to the other processor and it appears to have the job of bundling these up in Ethernet packets which sent out on the network now we've got complete control over the firmware that's loaded into this processor or we should do anyway because if we change the contents the flash chip that was in this little position here it gets reloaded from a backup somewhere on this board and the only place where a backup at the firmware image could be stored is on this other little flash chip attach to the other processor on this side so one thing that would be interesting to try is just to modify the rig so that we can control this flash chip also so that when the backup is loaded we've also rewritten the backup in addition so that we're reloading a modified backup over the top of the modified firmware and in fact we get the firmware loaded onto this chip that we want now why am I so interested in this media processor out of the two well it's because on this little pin header here there is this serial pin attached to it so we can attach a serial port and see the spew coming out of this chip and presumably there's something similar on this other media processor over on this side but for whatever reason I can't find a pin that's attached to it on this board as anywhere I look so I don't know how we can see the spew off this one otherwise I would be happy to switch focus onto this chip instead so we can try modifying the contents this flash chip the other thing we can try to do is look at the spi bus that links these two chips together so the command-and-control between the two media processor seems to be done through an SPI bus through which messages are sent between the two chips and the question is could we read out those messages and get an indication of what's going on so that would be another route but to begin with I think we're going to need a bigger rig which has a pad board attached to both sides now I don't mind saying it is a little bit frustrating that the first rig didn't yield the results I was hoping for it's not the end of the world building a second one I just got a bit more soldiering to do now as I mentioned for this project I'm using heat stakes to attach the boards to the frames instead of nuts and bolts and I'm finding they're working out really well all you have to do is 3d print a little column that goes through the holes and protrudes through the top and then you use a heated piece of metal to press down on them and melt the plastic over and rivet it in place then if you want to remove the boards you can just clip them away with side cutters and very gently move them over to the new rig so I'm glad that bits out of the way that was the really delicate part I'm I managed to move the two boards into the new rig without breaking anything so the next step is to get the other flash ship moved off onto the other pad board so I'm assembling this using my favorite prototyping technique which involves pad board mod wire and surface mount resistors I find it pretty easy to assemble boards this way using tweezers it's not quite as slick as having custom boards prepared which is very quick and easy to do but it is a bit better in terms of making ad hoc modifications to the design as you go so looking at the assembled result I'm reasonably happy with how the wiring is turned out looking at the high level I'm pretty pleased with it but close up it would be nicer if I could get the wire lengths a little bit more even but the density is quite good which is good to have when doing things at high speed right so here you can see I've got the assembled rig everything's in place up and running I've got the two flash chips off on the pad boards I've got two blue pills for reprogramming these things once again I've got the serial port over here and I've also added this logic analyzer a DS logic logic analyzer which is wired up to this pin header which I've wired through to the SPI link so with the logic analyzer we can spy on communication between the two chips then in addition I've also added this wire here which connects through to this blue pill and this wire goes through to the reset line it triggers the reset switch so I've got a modified version of the firmware in this blue pill board and there's a command I consent to it that will trigger a hardware reset then finally I've added a little USB power meter so I can keep an eye on the current being drawn by all the devices on my USB hub so the end result of all this is that my device is now basically under complete remote control of my PC and I can run any kind of test I want to do with it remotely I don't have to do anything or touch anything on the physical device instead I've written a whole suite of Python modules and command-line tools that I can use to make it do whatever I need it to do so a few weeks have passed since my last update and I've been doing a whole bunch of tests and experiments with it and as you might imagine things didn't exactly pan out the way I was expecting but nonetheless I discovered one or two rather interesting things so the first thing I wanted to test was whether I could u2's firmware again and as you remember I tried to change some of the strings in it see if I could get them to come out the serial port and it didn't work because mu1 came along with a backup of the firmware and rewrote it before the replace firmware could execute and I managed to find the backup in mu ones flash chip and so I tried rewriting both the main flash chip for you two and the backup attached to MU one to keep them both in sync and then as it turns out if you do that it simply ends up in a reboot loop where mu 1 is perpetually trying to correct the firmware in u2's flash memory with a version that is corrupted and so it just doesn't start up it just gets stuck trying to repair itself forever so at this point it was becoming pretty clear that the firmware in these flash tips was being protected by some kind of checksum so next up I wanted to know a bit more about which bytes were really important for the device to start up successfully and which ones could be changed with no effect and in so doing I was hoping to reveal which bytes were covered by the checksum so I wrote a little test script that takes my backup firmware image of u2's flash chip and it goes through and inverts just the single bytes loads it into the flash chip and the device and then starts the device up by resetting it and captures the output on the serial port and as the test ran it would start the device up repeatedly with just a single byte modified every time and in so doing it would go through slowly revealing a picture of which bytes could be modified freely and which ones seemed to have some impact on the devices behavior so I left it running for about 24 hours until the test run was complete and then I wrote some Python code to tabulate the results in HTML which is what you see here so every single cell in this table represents one byte of the firmware and what it's showing is the outputs on the serial port when that byte was inverted by the Python script now all the white cells ourselves where there was no output from the device when the device was started up and then as we go down through here the different colors represent different forms of output so what it's done is it's captured the first 32 lines that the serial port outputs and then it computed a hash to produce the color and what I found is that even though these are a few different colors they are basically only two different categories the gray ones and these green ones and so on are all basically the device starting up as normal then there are a couple of examples outliers where the device crashed during startup and decided to dump out the register state which itself is also very interesting so with all this we can see different examples of the different bytes some of them seem to be relevant for whatever reason and some of them do not and now as we scroll down we go all the way through the header which has a mixture of important and unimportant bytes until we get to the s mass section down the bottom here at which point every single bytes in the body of the ass mass section seems to be important so looking at the results in this table it's kind of interesting to see which byte seemed to be important but the problem with this test run is that it hasn't really gone very far towards dispelling any of the mystery because although it shows us which bytes were important for the device to run properly it doesn't really tell us anything about why they're important it doesn't tell us what the role of each of these bytes is so maybe this will come in handy when some more information is known but for now I'd say the test wasn't especially fruitful but on the other hand it was very easy to set up it didn't take long to write the Python script and it's nice to be able to get the rig to do something automatic and leave it running for a while and see what it comes back with and that's the thing about hacking around with these things you've just got to try things and you never really know what's gonna come out of doing one experiment or another now I had a real breakthrough when I started doing some analysis of some of the upgrade files for the Lancang device so link Tom Dan man's blog is a link to a Google Drive folder run by someone called Daniel cachoeira and he has managed to collect together a bunch of upgrade files for the Lancang device I don't know where he got them from but I started comparing them to see how they compared to each other and I managed to find two files which were very very closely related to each other they were released within a few months the top one came from 2016 February and the bottom one was released in November 2016 so very very close together and these two files are very very closely matching they have very few differences so the first couple of megabytes of this file these two files is exactly the same and it's only when we get to this point a couple of megabytes in we get to the s media tag which of course is what we get written this is would be the first bytes that go into our flash and thereafter and there's a little bit of difference you can see the copyright the release dates slightly different between the two but everything else in the header before the SMS section is exactly the same until we get down to the as Mars and then you can see the two words before it are slightly different so these this word here between here and here is very slightly different and I think this is a strong indication that this number is the uncompressed length of the data very very close these two numbers together because of course there's very little difference between these two firmware files and then this here I think is our checksum it looks too much like a checksum to not be one as far as I'm concerned 32-bit value now I've been trying to figure out what this is a checksum of how it was calculated doing a bunch of different things and even brute forcing it and I haven't been able to figure out how this thing's been calculated just yet but you can see that these two firmwares are very similar and it's as we scroll down there are only one or two tiny little differences in the early part of the SMS data it continues to be the same the same the same until we get beyond a certain point and then the two seems to radically diverge from each other so now I'm getting quite excited about this I think we might be beginning to get somewhere and I definitely think we should keep on digging but that's about it for this video so I'm Joel holdsworth if you enjoyed the content give it a like and subscribe or if you want to support the channel I've moved my donations over to subscribe star and you'll find links for that down below along with the show notes containing lots of background information for this video so thanks for watching and I'll see you next time on the open tech lab you

Channel: OpenTechLab

Views: 17,776

Keywords: software, electronics, hacking, open source, programming, reverse engineering, 3d printing, cad

Id: YMI6hiksRxE

Length: 13min 7sec (787 seconds)

Published: Fri Aug 23 2019