Posted by david b.
on December 5, 2013
In this section of the presentation, beist compares Smart TV and smartphones in terms of compromising and focuses on actual TV surveillance on the code level.
Before we move on to how I implemented surveillance programs, I want to mention the comparison of surveillance between smartphone and Smart TV. I did a quick test on a smartphone. I made a simple program on Android which takes a picture every minute (see middle image below). I went out with the phone and I used it as my real phone.
Surveillance on smartphone
Smartphone – problem 1
I got two problems from the test. The first one (see rightmost image above)
is most of the time your phone is on your desk or in your pocket, so that most of pictures you take are black or white or very noisy. Only 1% of photos were ok, but the other 99% of the photos were useless, I mean, for attackers.
The battery problem
The second problem (see right-hand image)
is that if you take a lot of photos on smartphone, the battery life is really going down so fast. People would say that surveillance on smartphones is really critical and really bad, and I realized these problems.
Smart TV surveillance
Unlike smartphone, Smart TV is almost always connected to the power and you could record via the camera and the mic 24 hours (see left-hand image)
. Of course, TV cannot move, but on the other hand, a TV is a really good photographer, so they can watch you very well. Of course, the photos from Smart TV are very nice. Basically, surveillance is not about me or you, but it is about your family. I mean, if you get hacked, if your desktop gets hacked, mostly it’s your problem. But if a Smart TV gets hacked, it is about your family or your girlfriend, so do not make the TV see your bed.
Threat to corporate environments
Also, I know some big companies like Google or Microsoft use Smart TV at their offices, so it’s not only about personal stuff or home private stuff, but it’s also about the companies, infiltrating some sensitive data (see right-hand image)
We’ll go to technical stuff now (see left-hand image)
. We have a shell, which means you could do dynamic analysis, I mean, reverse engineering
. But the problem is that most of the code is written in C and C++. If you do C++ reverse engineering, it’s really hard to know which function is called. You’ve got to do dynamic analysis to figure out how the Smart TV is working. I was going to make my own DBI program. But I found a really nice one – Collin Mulliner made a DBI program for Android. I slightly modified its code and tried to use it on Smart TV. It works pretty well.
Collin’s DBI for Android
The DBI (see right-hand image)
works like it ptrace-s a target process and changes PC register and puts some shell code and executes it. It is pretty much the same when you do hooking stuff. It’s pretty easy, but it works really great.
Sample hooking code
Like this (see left-hand image)
, you can put some hooking code and you can do hooking on runtime. Why I used the DBI program is to know, basically, ‘r’ register and ‘pc’ register (see leftmost image below)
. In ARM, the ‘r’ register has that return address. Once we know ‘r’ register we can know that this function is called from this function. It makes it much easier to understand the whole process. Of course, you can know the arguments, e.g. ‘r0’, ‘r1’, ‘r2’, ‘r3’. And also you see a free table.
Debugging to trace C++ stacks
Debug messages in binaries
Getting hints from developers
In binary they are attacking some global variables. If it’s a “debug” version, it prints some useful messages (see middle image above)
. So, if you see them, the reverse engineering will be easier. Basically, all binaries are “release” version, so you cannot see those useful messages, but you could do runtime patching, like this way (see rightmost image above)
, using PTRACE system call. After this you’ll see all the useful messages from Smart TV box.
I wanted to make my rootkit working 24 hours, which means it would work even if users turned off their Smart TV. This should be possible because there is software. After reversing a lot of code I figured out the TCTv::Power() function that does actual turning on and turning off (see middle image below). People reach power function, it turns off screen, and sound mute, and kills some process, but at that time the kernel is still working. After that, when they reach to TCTv::Power() function, it actually goes to turn off. That’s very simple.
Rootkit working 24/7
How? Reversing and hacking
Trick for 24/7
Using a hooking program, you just put “return” on the top of TCTv::Power(), so that the sound is mute and screen is black, but it’s still live. It looks like it’s turned off, except that LED blue one (see rightmost image above)
. To turn off the LED you’ve got to call SetLightEffect() (see leftmost image below)
. I figured out this function does the job, but it’s a lot of code and I can’t bring it all on this slide. If you call this function with argument at 0, that blue LED will be turned off. So it totally looks turned off, but our rootkit is still working inside.
Turning off the LED
What’s been done?
We’ve got to set second flag for when users turn on the TV (see middle image above)
. You’ll never notice if there is a rootkit program and if that program is even working 24 hours, even if you turn off your TV (see rightmost image above)
Read previous: Hacking, Surveilling, and Deceiving Victims on Smart TV 3: Exploitable Vulnerabilities
Read next: Hacking, Surveilling, and Deceiving Victims on Smart TV 5: Conclusion
Like This Article? Let Others Know!
Comment via Facebook: