better readme organization and some clarifications

Readme.md

@@ -24,10 +24,10 @@ Other models might be running ProlinOS too but their specification is not detail
 
 For this research, I have bought a S900 from eBay and was lucky enough to find a used model targeted at developers. I will specify when something applies only to the developer model and not the production ones, although very little differs in terms of vulnerabilities.
 
-## Pictures
+### Pictures
 ![PAX S900 from eBay](https://git.lsd.cat/g/pax-pwn/raw/master/images/s900.jpg)
 
-## Resources
+### Resources
 Before starting the analysis, I found the following resources very useful:
 
 PDF:
@@ -48,13 +48,13 @@ FCC Documents:
 
 It's possible to see clearly from the `Internal Photos` PDF that the device has an additional battery and multiple anti-tampering contacts; there's also a warranty sticker on the side. Hardware attacks are probably possible, but out of scope here as I lack both skills and equipment to work in that direction. Furthermore, a hardware attack would be more difficult to execute in real-life scenarios because of the circumstances in which a POS is used.
 
-## Hardware Info
+### Hardware Info
 The device has a color display, WiFi, GSM, Bluetooth, an AC charging port, and two mini USB ports. From the specifications, one is used for serial communication and the other one for USB communication. It has a Broadcom BCM5892, 128MB of flash and 64MB of RAM.
 
-## ProlinOS
+### ProlinOS
 ProlinOS is a minimal Linux distribution, probably derived from Android.
 
-## Communication
+### Communication
 The device needs to be rebooted into the management interface (called `TM`). To do so on the S900 press the number `2` repeatedly during boot (even after the `SELF-TEST` screen). On the D200 do the same but with the key `F2`. Other devices have probably similar keys, and they can be guessed in a few attempts.
 
 From there go to `System Config`. enter the default pin which is `123456` and enable the XCB service. The XCB service can run both via the serial interface and network, depending on the model and the version of ProlinOS. For the serial interface, use the driver provided in the links in the Intro section, for the network interface, first connect the device to a WiFi network and the service will be on `<ip>:5555`.
@@ -70,16 +70,17 @@ Supposedly, `xcb` is intended only for adding applications to the device (which
 
 There's also a `telnet` command which will port forward to the local machine a telnet daemon. This command will only work on development devices because the whole `telnet` binary is removed from busybox on production devices.
 
-## Debug Level
+### Debug Level
 Devices have three debug levels:
  * 0 -> Production devices, busybox has no `sh` nor telnet, `xcb` works
  * 1 -> Application development devices, `busybox` has both `sh` and `telnet`. There's also a handy `gdbserver` in place. Root access is disabled, kernel, kernel modules, and some PAX configuration and binaries are not readable
  * 2 -> Prolin development devices, `root` should be available with a hardcoded password
 
- We'll see that from debug level `0` it is possible to escalate to root privileges.
+We'll see that from debug level `0` it is possible to escalate to root privileges.
+The pos used for this article is in `debug` level `1`. A production device won't have a working telnet/shell by default. However that functionality can be restored by overwriting a shared library using the arbitrary read/write in XCB or by porting the already signed binaries from a debug device.
 
 
-## Basic Linux info
+### Basic Linux info
 From the development S900:
 
 ```
@@ -172,15 +173,18 @@ devices_base           26185  7 pcd_base,msr,sci_bcm5892_tda8026,tty_host,tty_de
 bcm5892_rtc             4938  0
 ```
 
+## Vulnerabilities
+### Arbitrary Read/Write
+As described in the "Communication" section, it is possible to list, read and write file and folders with `MAINAPP` permissions via XCB.
 
-## Signature Bypass and Code Execution
+### Signature Bypass and Code Execution
 Although ELF files need to be signed in order to be executed (later we'll see how), libraries apparently do not. This means that it is possible to run custom executables without issues, given that we have a working shell and `LD_PRELOAD` is working or that, even without a shell, we can overwrite a library in use by some application.
 
 `installer`, which is the executable being called by `xcbd` (the `xcb` daemon server, like `adbd`) is responsible for verifying binary files before adding them. This does not mean that the kernel doesn't check again (it does) but means that ELF signature verification is available via userspace and is provided by a kernel module.
 
 It simply opens the device `/dev/verify`, uses some `ioctl` calls and send the executable file. Depending on the `ioctl` results it is possible to determine if a binary file has been correctly signed. As per the signature format, it's possible to guess that it is simply made by an RSA 2048 signature appended at the end of the file plus the string `SIGNED_VER:00001`.
 
-## Privilege Escalation
+### Privilege Escalation
 
 By looking into the device, there are mainly two possible vectors of privilege escalation which are:
  * The outdated kernel is vulnerable to [dirtycow](https://dirtycow.ninja/) and many other kernel exploits