Basically this second part is all about how to enable adb on the Z28. First I need to say few words about my initial setup. When I bought the box I just did jump into the subject without even powering one the device one time.
In retrospective I have to admin that was kinf of a very stupid move. My initial assumption was that there will be no official way to activate ADB, which was the main reason to search for the UART interface. I do no comment this any further you will see why 😀
Using the Root Shell to activate ADB via WiFi/Ethernet:
To enable ADB manually we have to modify a file on the /system partition. Obviously for security reasons this partition is normally mapped RO, so we first need to remount the partition RW.
mount system partition RW
If the command was executed successfully you can modify the /system partition as you want. Now we need to activate ADB which we can do by adding some lines to /system/build.prop
Now, after the changes are persisted you just need to reboot and ADB will be active. You either can now access adb via USB ( you will need to install the windows drivers – you can get them on the rockchip page, search for DriverAssistant) or if you configure WiFi/Ethernet you can connect directly via network:
Once you established connection and adb shell is running you can elevate by just using the “su” command.
Well, actually all of this is a big waste of time, because there is a much easier way….:-D
2-Minute ADB activation the smart way…:
Because my ethernet connection didn’t work out of the box I fired up the box to activate WiFi…While I was search for hte settings I realized that the settings I saw are basically just normal Android settings. I got curious and tired to activate ADB (Developer mode) the default way, not expecting it work. I felt kind of stupid when I saw it did work too ;D
Next time I will start the device before I dive deep, that is for sure, haha!
The next part of this write-up series will cover installing linux on the box and what you need to know to restore the original state afterwards.
Recently I was doing a lot of ARM debugging on a large variety of devices. Some of them are extremely expensive and so I decided to have a look at much cheaper devices which might be useful for such a purpose too!
In this initial blog entry I will give you an overview of the Dacooler Z28 Android TV Box and show how you can relatively quickly obtain a root shell on it. Here is a picture of the box which is very cheap (I bought is for around 35 USD):
Let’s have a look at the technical specs of the device:
Storage Extension: Support MicroSD(TF) Up to 64GB
WIFI: 2.4G WiFi
HDMI Out: 1*HDMI,HDMI2.0 3840x2160Pixels
USB Port: 1*USB 2.0,1*USB 3.0
Card Reader: 1*Micro SD card (TF card) reader
Network: 1*RJ45 LAN Port
Power Supply: 1*5V2A DC
In my opinion a pretty decent hardware! You have an ARM64 Quad CPU + 1GB of RAM. Something we definitively can work with, right ?
This was not the first box I’ve opened so I was in a state between excitement and desperation. Some of the models I have ordered turned out to be more or less unusuable for too many reasons to explain here…
Opening the box is very easy. First you need to remove 4 rubber feets at the backside of the device. Among them you will see 4 screws which need to be removed. After you have removed all of them you can open the case. The PCB board is also secured with two screws which need to be removed as well. Once that is done you can fully remove the PCB board from the case.
Here a picture of the board:
We can see the Rockchip RK3328 in the middle.
Finding the UART interface:
When you start searching for the UART interface on a proprietary system you usually search for 4-PIN connector which seems not to be in use. Sometimes you can find it on the board sometimes the PINs are not soldered or you don’t see anything like that at all. It can happen that you see 3-PIN instead of four but that happend really rarely to me I have to admit. Nevertheless you only need three PINs for the connection:
As the picture shows you need RX, TX and GND. Spending only a view seconds searching the board revealed this here:
Wow, that was easy right !? At the bottom left corner you see a 4-PINed socket which most likely will be our UART-Iface. UPDATE: The pin socket you see on the bottom left corner wasn’t originally there. I soldered it onto the board. Now what you need to establish the connection is a so called Serial-To-USB converter. I have several of them and sometimes one is working and another one is magically not working. Best is you have several of these at hand so you can try what is working with the hardware you want to connect to. I also had to try 3 differenty converters until it worked and I used this one here:
Establishing the UART connection:
Let’s try and see if the interface is working or whether it might be a dead end. You simply have to connect RX -> TX, TX -> RX and GND -> GND and you are good to go like this:
After everthing was connected I fired up PuTTY and check the the serial connection settings. Usually when I try these things I use the following setting which works in most cases without issues:
As I said in most cases….For some reason this is different for Rockchip R3328! You need to specify 1500000 baud. If you don’t, your output will look like this and you cannot read anything:
Loading Device Tree to0000000005600000,end000000000561d6ab...OK
WARNING:could notset reg FDT_ERR_BADOFFSET.
<hit enter toactivate fiq debugger>
Booting approx. consumes 45 seconds, which is ok I would say. When everthing is loaded you can hit enter in PuTTY and will get a Root Shell for free. Checking the root file system does reveal the following:
At this point you already can start modifying the system as you want. You can activate adb via wifi (which I will show in the second part of the write-up series), install any kind of system application, remove system application or just start reverse engineering the system to find some nice vulnerabilities!
I hope you could see that “hardware hacking” isn’t always complicated as hell. There are a lot of shades and if you just keep trying you will be successful. For me this was fun and it won’t be my last box ;-D
due to recent macOS research I had to setup kernel debugging again. I have already done a lot of research in that area so I was quite familiar with the procedure. Nevertheless every time when you have to deal with a new version of an operating system you’ve been playing around before, there are some unexpected problems which will make this kind of setup a pain in the ass!
Personally I prefer to jump directly into new research and solve problems step by step but sometimes that can be very frustrating, especially when preperation tasks and setup is tricky.
Physical vs. VMware
Usually I try to solve most of my task using virtual machines. I use VMware Workstation Pro a lot and so far I was happy with it. On macOS of course I use VMware Fusion which is the nicer VMware product in my opinion. It is faster, doesn’t hang a lot and I love the quick VM switching via pseudo “swipping” using the keyboard.
Installing macOS inside VMware Fusion is simple. Installing inside VMware Workstation is already a bit more complicated. Most likely you know that you will have to patch VMware Workstation with the latest version of “VMware Unlocker“. Here I really want to thank the author of the tool – you helped a lot of people with it AND I never had a single problem using the unlocker.
Beside the fact that this is prohibted by VMware the unlocker introduces an updating issue in VMware Workstation. Whenever a new update was applied the unlocker needs to run again. A small issue I have to admit, but if you forget that you might experience trouble. Keep that in mind.
Additionally and limited to macOS VMs you will have to manually patch you .vmx file. There is an issue related to SMC which can be solved as follows:
*.vmx file patch to support macOS images
Adding the both lines to your .vmx file will allow you either run a fresh macOS installation from an .iso file or a preinstalled macOS VM created by VMware Fusion.
All of the mentioned issues are annoying but not difficult to deal with. So far so good. When you want to debug a kernel, then you want control the system like this:
My eyes still start glowing when I see this little window. I miss the old days when SoftICE was still running (have to admit that SoftICE architecture was not the best, what at the end was one reason why development was stopped…). And one of the reason why reversers did love it was that you could press CTRL+D at any time to fireup the debugger. The system did freeze completely and you would eventually become a debugging god with full control in your operating system universe ….;-)
Well these days are over but I still love take over the control completely when I debug. Especially I’m missing CTRL+D feature.
The good news here is that you can have that feeling again when you debug the macOS kernel. And this basically is why you cannot do that the vm2vm way.
Let me quickly wrap-up how this works:
Disable rootless/SIP protection. At the time of writing this article you can do it by booting into the recovery mode (Control-Key+R), then opening a terminal to issue the following command:
Set the nvram boot-args accordingly to your needs (for initial testing I highly recommend to use debug=0x5). Remember, if you did skip step 1 you won’t be able to correctly modify the nvram. A sample for setting the nvram boot-args would look like that:
sudo nvram boot-args="debug=0x5 -v"
The machine will freeze at a point and tell you that it is waiting for a kernel remote debugger to attach. Additionally it will print the Debuggee-System’s IP and MAC address. Save both in your notes, you will need it later.
Install XCode + XCode commandline tools if not yet done.
Install Kernel Debugging Kit matching the exact OS version on the Debuggee-System (this is highly recommended if you want to have kernel symbols available during your debugging session)
Set a static ARP entry to ensure proper network communication. The command to add an entry is:
It might happen that after the command was executed you will see a message that will tell you that a previous entry was deleted or maybe not even existing. Just ignore that.
Open a terminal and start the debugger:
Once you are in the lldb shell you are ready to debug. Now you need the IP address and MAC address of the debuggee. Using the following command you will be able to connect/attach:
Connecting to Debuggee
There you go! Hopefully there was no problem and you have now a working remote connection and thus being able to debug debuggee system’s kernel.
This scenario obviously applies on when you are in the comfortable situation of having two physical macOS machines at hand. Lets assume you type c+enter to let the debuggee system continue running for a second.
How do you gonna add a breakpoint or examine a memory location ?
That is very NMI enters the stage. WikiPedia offers the following brief description of what NMI is:
In computing, a non-maskable interrupt (NMI) is a hardware interrupt that standard interrupt-masking techniques in the system cannot ignore. It typically occurs to signal attention for non-recoverable hardware errors. (Some NMIs may be masked, but only by using proprietary methods specific to the particular NMI.)
An NMI is often used when response time is critical or when an interrupt should never be disabled during normal system operation. Such uses include reporting non-recoverable hardware errors, system debugging and profiling, and handling of special cases like system resets.
Modern computer architectures typically use NMIs to handle non-recoverable errors which need immediate attention. Therefore, such interrupts should not be masked in the normal operation of the system. These errors include non-recoverable internal system chipset errors, corruption in system memory such as parity and ECC errors, and data corruption detected on system and peripheral buses.
If you are interested in more info please have a look here: https://en.wikipedia.org/wiki/Non-maskable_interrupt
Lovely right !? Doesn’t some too good but here it is crucial to have working NMIs on a system so you can trigger the debugger to break at any time. Think of it like:
You press a specific combination of keys
That will force the debuggee system to trigger an NMI
And therefore the debugger will be notified to reactivate the debugging session right away
As you will understand without the capability to issue an NMI there will be no CTRL+D SoftICE like feature (basically that is not completely true as I am ignoring debugStub implementation in VMware Fusion and Workstation, but that is a different story).
Practically in my case running the latest version of macOS 10.12.3 at this time the magic key combination will be Left CommandKey + Right CommandKey + PowerButton. In the moment you press the those buttons together your debugger will jump in and you are in control again.
Virtually no NMI available !?
Basically that is the reason why it doesn’t seem to work in VMware Workstation/Pro. It seems that there is no mechanism that is capable of sending an NMI which will recognized by the debugger system.
How did I test that ?
I tried more or less the above depicted method to setup kernel debugging. The first significant difference was that even with boot-args=”debug=0x1 -v” or boot-args=”debug=0x5 -v” set the debuggee system did not stop at boot time to wait for the kernel debugger.
From what I can say this is connected to the NMI issue. Interestingly I remember a former setup where this was working but for VMware Fusion. Fusion and Workstation are for sure not completely equal but they share a lot of common code.
Knowing that I guess there is a way to trigger such a NMI but as of yet nobody has found the way to do so. Unfortunately VMware is not gonna helpful here 🙂 If I can spend some more time I will definitively look deeper here. Having the same setup with two virtual system would be awesome.
My recommendation here is whenever you want to start immediately debugging then go for the physical setup. It will save you a lot of time!
Another reason to choose the physical setup is that there might be bugs which you cannot replicate inside a virtual machine because they are hardware dependent. Just recently I had exactly that.
I hope this little article helped to better understand issue with kernel debugging on macOS on virtual system as well as how a quick’n’dirty-setup could look like. If there are any questions related to the topic feel free to drop an email. firstname.lastname@example.org
After a long period of idle, I finally decided to build-up my broken blog from scratch again. This time I will try to approach from a more minimalistic perspective and hope to provide decent content for you as my limited time will allow me.
The most important reason why I want to contribute something to our scene is that I really miss the old days when reverse engineers shared most of their knowledge. Sadly, I have to say that this seems no longer be the case. A pretty obvious reason in my opinion is that nowadays our jobs became kind of an elitist thingy and the involed money makes some of us feel to guard and protect their knowledge from being stolen.
Personally, I doubt that this is a good and healthy philosophy. Quite the contrary is the case I think: The more we shield knowledge from others the less we will generate innovation.
The one and only thing I can say for sure is that I wouldn’t be where I am today if not a bunch of very talented and friendly individuals would have taught me how to do the things right. Thank you very much!
There is a lot stuff I want to talk/write about so please stay tuned 😉
Nuff said, I hope you will find some of the contributions interesting and even if the opposite is the case, something was learned too!
mitp0sh of PDX
### In memory of Francesco Vianello aka +Fravia ###