Table of Contents
~~META: status = suspend &relation firstimage = :project:freebsd.jpg ~~
* A Lab for everyone to participate in
* Kernel to every family
* Provide more insight about the architecture of kernels, operating systems, network layers, and porting
* Porting or running kernels on android phones, tablets and other various embedded systems
* Developing our own Kernel, new operating systems, Reverse Engineering, Security, ACPI, EFI,
Core Team to table → interested
* Why BSD ? THe BSD kernel has many interesting features for hacking and tuning, as well as optimization
Project - Making a new FreshPorts - ITS DONE
Goals and ideas of this project
* More information about packages for FreeBSD and for users other operation system.
* Record is on page talknight and slide is here: https://brmlab.cz/_media/event/maxfx-freebsd_ports.pdf
* Freebsd-how-to-make-a-new-package: https://mirror.vpsfree.cz/videohrach/video/brm/lightning_talks/lt-2018-08/2018-08-02-freebsd-how-to-make-a-new-package.mp4
Project - Goodbye android! - ITS DONE
Goals and ideas of this project
* In this project we attempt to boot and install BSD on the Medion P10356 tablet, which houses a Intel® Atom™ Z3735F CPU (Bay Trail) and comes with Android installed by default
* Altough the tablet houses an x86_64 architecture CPU, it does not expose its UEFI menu and hence does not allow anyone to boot from an external drive.
How we hacked the device
After countless odd attempts to enter the UEFI menu (such as attaching an external keyboard and pressing a bunch of F- keys), we believed that we had to replace the Android bootloader ( Intel Boot Stub) with a standard UEFI Linux bootloader, such as Grub, or a universal bootloader, such as U-Boot. This would be a very difficult and risky process, since tampering with the bootloader can easily result in a hard-brick. At around this point we also popped open the device and searched for a UART header, which we found, yet never ended up being able to obtain data from. After some research we have quickly realised that the “easiest” way to port U-Boot onto an android device is to flash it as a boot image, so that it is chainloaded by the android bootloader. For this to be possible, we also had to root the device in order to obtain valuable information. Fast forwards and we found a somewhat working version of TWRP which booted on our device, but refused to expose the ADB shell and failed to mount certain partitions.
Our plan was to fix the semi-working TWRP recovery by unpacking it, and substituting the kernel image with that of the stock recovery. Typically, whenever flashing a recovery or kernel to the tablet, we would reboot the device into bootloader mode, either by holding down the volume down button at start, or simply executing:
adb reboot recovery
via adb. This would typically put the tablet into “fastboot” mode where it would display a Android lying on its back, however this time it simply displayed:
Entering DnX mode. Awaiting fastboot command...
Meaning the device entered “Intel DnX mode” which is a mode that exposes a minimal fastboot interface and allows the Intel® Platform Flash Tool to perform a full factory reset.
Since we simply wanted to flash our patched recovery, we attempted to execute:
fastboot flash recovery patched-recovery.img
However, as already mentioned, the fastboot interface exposed by the Intel DnX mode is limited, and thus the command failed.
Here is where the fun begins…
If flashing recovery from the DnX mode was not an option, perhaps booting into it might work, and so we tried:
fatboot boot patched-recovery.img
And suprise suprise, while we did not boot into TWRP, we booted into something much nicer, and that is, the devices UEFI menu :)
From here it was a simple piece of cake. The first thing we did was to disable quick boot and quiet boot. Now the device would no longer display the MEDION logo upon boot, but rather a boot screen that allows you to enter the UEFI settings by pressing ESC at boot. Then we flashed a FreeBSD, Linux distribution onto our SD card and attempted to boot into it. Oddly, that did not work (perhaps we didn't use the correct partition table?), however we never found out since we accidentally broke the sdcard slot after that (Good job CTXz…). Desperate to continue we searched for a USB hub (the only USB 2.0 port was already reserved by our keyboard as the touchscreen doesn't work) or micro USB to USB converter. Thankfully we found an old keyboard that has a USB hub embedded. After flashing BSD onto a USB stick we inserted it into the keyboard, and voila, an entry for the USB was shown in the UEFI boot options. After a few minutes of waiting, likely due to the speed of the USB hub, BSD successfully booted :).
We accidentally discovered that you can boot into the hidden UEFI settings by attempting to boot into a boot- or recovery image in the DnX fastboot mode.
Steps to enter the UEFI settings on your MEDION P10356
- Reboot into fastboot mode
- Flash the following TWRP image: https://drive.google.com/open?id=1-GK9W-l42V035VrPbPEhUm4ypoYzC8Bw
- Boot into TWRP
- Reboot into fastboot mode once again, this time the tablet will boot into Intel DNX fastbot mode
- Attempt to boot into the TWRP image (altough any other image will do too) via 'fastboot boot <YOUR IMAGE>'
- The tablet should now enter the UEFI settings
- Optionally, from the settings you may disable “UEFI fast boot”, which will allow you to enter the BIOS by pressing ESC during boot
Restoring the UEFI Firmware
While we attempted to install FreeBSD, OpenBSD and Linux onto the tablet we had accidentally disabled the internal graphics card within the UEFI settings (this comes from the fact that users should not even be able to access the UEFI settings). Unfortunately, after that we were no longer able to change UEFI settings back, as the display was now simply blank. Out of desperate hope, we dumped the UEFI ROM from SPI chip, and attempted to re-enable the internal GPU by altering the UEFI binary. Thankfully, this was not necessary after we found a stock UEFI binary in the MEDION P10356 recovery package that can be obtained from here (look for ifwi.bin). After flashing the UEFI binary from the recovery package via SPI using a RPi, the UEFI settings were reset and the display worked again.