LG G4 internals: My messy jots
Introduction
These are my really messy jots as I tried out things with my LG G4 H815 phone (Android 5.1, kernel 3.10.49, software version V10e-ISR-COM from Aug 17, 2015, not locked to any specific network). I usually try to get the post tidy so it becomes some kind of how-to post, but this time I just left it as is.
The only important takeaway from all this is that there’s no need to root the phone in order to get the key file that is necessary to decrypt all WhatsApp messages in the phone’s history: The file can be fetched in Download Mode without rooting.
My original idea was to upgrade Android from Lollipop to Nougat, mainly because there are a few Apps out there that won’t run on my outdated OS. So the point was to make the phone work better, or else I just go and buy a new one. As little hassle as possible.
The fact that I have a G4 for six years implies that I’m not fond of these things, and I’m anything but an Android expert. This was really the first time I sat down and tried to see what’s under the hood. It’s more hassle than just buying a new phone (or is it?) but I thought maybe I’ll learn something interesting.
As it turns out, each Android phone has its own story and toolset for the low-level stuff, so it’s really a lot of ugly company-specific things to deal with. In short, not very interesting.
Understanding that upgrading will probably come with a headache, and that rooting the phone will also probably mess up things considerably, I decided to leave all this. The only benefit was the full image backup, which at the very least gives me the WhatsApp secret key.
The original plan
- Make screenshots of applications, both main and secondary.
- Try LG Bridge and see what it can do (in particular regarding backup of WhatsApp)
- Save all WhatsApp chats to cloud (Google Drive).
- Root the phone for backing up all files. In particular, get the WhatsApp key, without which the backups are worthless (in hindsight, no need to root the phone for this purpose).
- Upgrade to Nougat, possibly with LG Bridge, and if not with LG UP.
- Restore with LG’s own backup tool and fetch WhatsApp chats from cloud.
Backups
Before upgrading, make a backup? Here’s my maximalistic checklist.
- LG’s own backup tool, backing up everything except media (got 760 MB, would have reached 6 GB with media)
- Back up all in DCIM/Camera (all taken photos and videos).
- Ran a backup to cloud within WhatsApp. Also copy the files from /storage/sdcard0/WhatsApp/Databases/
- Then a full filesystem tar backup, as shown below (before rooting, so it’s partial).
- Full image copies with SALT. Well, no, it didn’t work, see below.
- A full backup of /data with the phone in Download Mode (including files accessible by root only, but without rooting the phone).
Reading WhatsApp messages
The maybe most important goal of all this was to harvest my WhatsApp history in a sustainable way. That is, so the messages can be read like 20 years from now. Because the grim fact is that as soon as a little key file that is buried inside the phone is lost, all message history goes down the drain forever.
The WhatsApp database files are described on this page with focus on the message files on this page. To make a long story short, the messages are stored in an Sqlite file (or is it? Probably, and it’s a .db file).
These are accessible but encrypted, and so are the backup files (e.g. msgstore.db.crypt14). The encryption key is accessible with root only, and is created specifically for a user when creating a new WhatsApp account as /data/data/com.whatsapp/files/key.
So the files to grab are
- The encrypted database file: /data/media/0/WhatsApp/Databases/msgstore.db.crypt14
- The file containing contact information (optional): /data/data/com.whatsapp/databases/wa.db
- The key: /data/data/com.whatsapp/files/key
With these at hand, WhatsApp viewer (see github repo) can be used to decrypt the db file (it supports crypt14) and then view the messages. It’s a Windows program, and I guess some openssl command for the crypt14 command will be available sooner or later.
SSH session with simpleSSHD
This is a no-cost app, which is essentially the Dropbear server.
Note: It’s also possible to connect with “adb shell” through a plain USB cable, and there’s “adb push” and “adb pull” to transfer files. And there’s shell as root in Download Mode.
Having SimpleSSHD running and started on the phone, I connected with the address provided on the screen
$ ssh -p 2222 user@10.11.12.13
the password appears on the phone’s screen. To use automatic login, go
cat > ~/authorized_keys
and copy-paste the content of ~/.ssh/id_rsa.pub there. Note that the file on the phone is not under a .ssh/ directory, which is probably why the ssh-copy-id utility doesn’t cut. However that once this file is found, a password login is not attempted if the host’s public key doesn’t match, so this can get a bit messy.
In principle, the available executables are in /system/bin. The path contains more directories, but this is the only effective one.
Who am I?
$ id uid=10141(u0_a141) gid=10141(u0_a141) groups=1015(sdcard_rw),1028(sdcard_r),3003(inet),9997(everybody),50141(all_a141) context=u:r:untrusted_app:s0
Backing up directly from phone (command run on receiving host):
$ ssh -p 2222 user@10.11.12.13 tar -cvz /storage/emulated/0/Pictures/Screenshots/ > ~/Desktop/pics.tar.gz
Data speeds
Because there’s going to be a lot of data copying, I checked the data speeds with scp. So one gets about
- 2.7 MB/s when the phone is a Wifi client
- 6.7 MB/s when the phone acts as a hotspot.
- 20 MB/s when sharing Internet through the USB cable
The winner is clear.
Mounts
The files, as exposed when connecting to the phone with a USB cable, are at /storage/emulated/0/, or /storage/emulated/legacy/. The latter is symlinked to by /storage/sdcard0. Both are mounts of /data/media (as well as /mnt/shell/emulated/). So /media/data/0/ is essentially the root of the filesystem that is visible over USB.
$ mount rootfs / rootfs ro,relatime 0 0 tmpfs /dev tmpfs rw,seclabel,nosuid,relatime,size=1437392k,nr_inodes=359348,mode=755 0 0 devpts /dev/pts devpts rw,seclabel,relatime,mode=600 0 0 none /dev/cpuctl cgroup rw,relatime,cpu 0 0 adb /dev/usb-ffs/adb functionfs rw,relatime 0 0 proc /proc proc rw,relatime 0 0 sysfs /sys sysfs rw,seclabel,relatime 0 0 selinuxfs /sys/fs/selinux selinuxfs rw,relatime 0 0 debugfs /sys/kernel/debug debugfs rw,relatime 0 0 none /sys/fs/cgroup tmpfs rw,seclabel,relatime,size=1437392k,nr_inodes=359348,mode=750,gid=1000 0 0 pstore /sys/fs/pstore pstore rw,relatime 0 0 none /acct cgroup rw,relatime,cpuacct 0 0 tmpfs /mnt/asec tmpfs rw,seclabel,relatime,size=1437392k,nr_inodes=359348,mode=755,gid=1000 0 0 tmpfs /mnt/obb tmpfs rw,seclabel,relatime,size=1437392k,nr_inodes=359348,mode=755,gid=1000 0 0 /mnt/pstore /mnt/pstore pstore rw,relatime 0 0 /dev/block/bootdevice/by-name/system /system ext4 ro,seclabel,noatime,data=ordered 0 0 /dev/block/bootdevice/by-name/cache /cache ext4 rw,seclabel,nosuid,nodev,noatime,noauto_da_alloc,errors=continue,data=ordered 0 0 /dev/block/bootdevice/by-name/userdata /data ext4 rw,seclabel,nosuid,nodev,noatime,noauto_da_alloc,resuid=1000,errors=continue,data=ordered 0 0 /dev/block/bootdevice/by-name/persist /persist ext4 rw,seclabel,nosuid,nodev,noatime,noauto_da_alloc,errors=continue,data=ordered 0 0 /dev/block/bootdevice/by-name/modem /firmware vfat ro,context=u:object_r:firmware_file:s0,relatime,uid=1000,gid=1000,fmask=0337,dmask=0227,codepage=437,iocharset=iso8859-1,shortname=lower,errors=remount-ro 0 0 /dev/block/bootdevice/by-name/sns /sns ext4 rw,seclabel,nosuid,nodev,noatime,noauto_da_alloc,errors=continue,data=ordered 0 0 /dev/block/bootdevice/by-name/drm /persist-lg ext4 rw,seclabel,nosuid,nodev,noatime,noauto_da_alloc,errors=continue,data=ordered 0 0 /dev/block/bootdevice/by-name/mpt /mpt ext4 rw,seclabel,nosuid,nodev,noatime,noauto_da_alloc,errors=continue,data=ordered 0 0 /dev/block/platform/f9824900.sdhci/by-name/cust /cust ext4 ro,seclabel,nosuid,nodev,relatime,noauto_da_alloc 0 0 /data/media /mnt/shell/emulated sdcardfs rw,nosuid,relatime,uid=1023,gid=1023,derive=legacy 0 0 /data/media /storage/emulated/legacy sdcardfs rw,nosuid,relatime,uid=1023,gid=1023,derive=legacy 0 0 tmpfs /storage/emulated tmpfs rw,seclabel,nosuid,nodev,relatime,size=1443536k,nr_inodes=360884,mode=751,gid=1028 0 0 /data/media /storage/emulated/0 sdcardfs rw,nosuid,relatime,uid=1023,gid=1023,derive=legacy 0 0 /data/media /storage/emulated/legacy sdcardfs rw,nosuid,relatime,uid=1023,gid=1023,derive=legacy 0 0 $ df Filesystem Size Used Free Blksize /dev 1.37G 100.00K 1.37G 4096 /dev/usb-ffs/adb: Permission denied /sys/fs/cgroup 1.37G 12.00K 1.37G 4096 /mnt/asec 1.37G 0.00K 1.37G 4096 /mnt/obb 1.37G 0.00K 1.37G 4096 /system 3.92G 3.15G 785.26M 4096 /cache 1.17G 2.11M 1.16G 4096 /data 22.70G 14.51G 8.19G 4096 /persist 27.48M 64.00K 27.42M 4096 /firmware 85.95M 74.77M 11.19M 16384 /sns 3.86M 60.00K 3.80M 4096 /persist-lg 3.86M 604.00K 3.27M 4096 /mpt 27.48M 11.14M 16.35M 4096 /cust 5.81M 753.00K 5.07M 1024 /mnt/shell/emulated: Permission denied /storage/emulated/legacy 22.70G 14.51G 8.19G 4096 /storage/emulated 1.38G 0.00K 1.38G 4096 /storage/emulated/0 22.70G 14.51G 8.19G 4096 /storage/emulated/legacy 22.70G 14.51G 8.19G 4096
Note the mount duplicity of /data/media as sdcardfs. This appears to be some kind of bind mount. /data is the actual userdata mount, and /data/media is what is shown to us users.
Also note that many of the mounts have the nosuid flag set, for good reasons.
Accordingly, backing up everything is done with
ssh -p 2222 user@10.10.0.226 tar -czv --one-file-system / /system /data /persist /firmware /sns /persist-lg /mpt /cust /storage/emulated/0 > ~/Desktop/phone-all.tar.gz
Almost needless to say, if this isn’t done as root, a whole lot of files will not be backed up as permission is denied.
For a non-root (hence partial) backup (5.6 GB), it takes 24 minutes with a Internet-over-USB connection with the phone.
Trying out LG Bridge Setup
Downloaded from the official site and installed version 1.2.68 on a Win10 machine, selecting Israel as my country and with plain installation on C:\. Went smooth.
Running the application, it went “No mobile device connected”. I fiddled around a bit with the phone to enable MTP on the phone, and it was detected properly by the software.
As for backup, it appears to be pretty much like the backup utility on the phone itself. As for software upgrade, that requires network access, so I didn’t go into this further (because enabling network access causes Windows to start upgrading itself).
Some general insights on rooting
In Android, unlike a common Linux system, uids are allocated to apps, and not real users. This is how the system makes sure each app gets access to its own stuff, and to resources they should access, by virtue of groups.
But exactly like any Linux, user 0, root, has access to everything. Android is designed to prevent this state from anything but the operating system itself, among others because many devices are sold for use with a specific cellular network, and rooting the device sets it free.
The idea behind rooting is to replace a component in the boot loading process, so that the root user can be given to plain applications. I didn’t reach this point, so I’m not sure exactly how this works out.
But in principle the procedure is to make some plain tap-on-screen setups to make the phone more permissive towards changes, then load a software image (e.g. TWRP) that is used when the phone wakes up in Recovery Mode (more on this next), which then allows injecting software that allows root access.
Because the phone is designed to prevent users from doing this, it will have to be “bootloader unlocked” somewhere through the process. It’s quite interesting that my phone needs that too, even though it was bought standalone, so who cares what I do with it.
TWRP is basically a utility that allows fiddling with the phone. One way to run it is with fastboot, in which case it runs from memory. To root the phone, its copied into the /recovery partition, so when the phone is powered up in Recovery Mode, TWRP runs.
The bootloader unlock thing
The procedure for rooting a phone always involves “unlocking the bootloader”. This appears to mean to allow writing raw image files (sometimes mistakenly called “ROMs”) into the phone’s flash partitions. This is often referred to as “flashing” and is crucial, because one of the steps for rooting the device is to replace the partition that is loaded in Recovery Mode.
Since flashing is typically made when the phone talks in the fastboot protocol (i.e. it’s in Fastboot Mode), and this protocol is commonly implemented in the bootloader, I guess that’s why they call it to unlock the bootloader.
See my failed attempt to write an image file in Fastboot Mode below.
Until the end of 2021, LG had a web interface for submitting the phones identification and obtain an unlock.bin file, which could be written to the device, and that would unlock the phone. Maybe the idea was to void warranty and allow this to phones that were sold with no strings attached. But I was too late for this.
But here’s the twist. LG (and probably other vendors) added a “Download Mode” that allows writing to partitions even if the phone is locked. My speculation is that they needed a way to update the software on any phone, without any hassle. So they created their own secret protocol (LG LAF) that works in Download Mode and allows full access, for use only by their own software. But then this protocol was reverse engineered.
By doing this, they created a huge backdoor which bypasses the limitations on fastboot mode completely. Security by obscurity. It always fails.
Boot modes
- Regular Android mode (MTP) — when the phone works normally. adb talks with the phone in this mode. USB ID 0x1004/0x633e.
- Recovery mode — the phone loads the recovery image, whatever happens to be there. Not sure if there’s any USB communication, I guess it depends on the image.
- Fastboot mode — apparently this is the pre-Linux bootloader. The device presents itself with a different USB Vendor / Product ID, intended for tweaking and flashing the device. The fastboot utility talks with the phone in this mode. USB ID 0x18d1/0xd00d.
- Download mode — the most permissive mode it seems. Allows some file related commands directly to the phone as root, as well as shell commands. For this mode, use SALT, or the LG LAF utilities directly. USB ID 0x1004/0x633e (same as MTP).
“adb devices” and “fastboot devices” will never detect the phone at the same time. The former expects it to be functioning normally, and the latter in Fastboot Mode, as in after “adb reboot bootloader”. The phone appears on the USB bus with a completely different ID.
There’s also “adb shell” which opens a plain shell on the phone, with uid 2000. The “su” command doesn’t exist, and neither would it work on a non-rooted phone. It’s also possible to copy files to and from the phone from adb. See this page.
On the boot process
The boot process is a bit in the mist, but apparently there’s a vendor-proprietary bootloader that chooses to boot one of the partitions on the flash, depending on button presses and whatnot. It’s probably aboot.img, being an ELF 32-bit executable, so it’s fair to guess that it’s the initial bootloader. Apparently this executable implements the fastboot protocol. In other words, fastboot mode is probably the most initial boot level.
The important part is that each of the other boot images contain the kernel plus a ramdisk image. So each is standalone.
To get a closer look on a boot image, follow the suggestion on this page,
# apt install abootimg
So this allows looking into what’s inside an Android boot image:
$ abootimg -i laf.bin Android Boot Image Info: * file name = laf.bin * image size = 50331648 bytes (48.00 MB) page size = 4096 bytes * Boot Name = "" * kernel size = 26700384 bytes (25.46 MB) ramdisk size = 10118136 bytes (9.65 MB) * load addresses: kernel: 0x00008000 ramdisk: 0x02200000 tags: 0x02000000 * cmdline = console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 user_debug=31 ehci-hcd.park=3 lpm_levels.sleep_disabled=1 androidboot.hardware=p1 * id = 0x3fc917e5 0xb1c78118 0x83d0740e 0x1a124148 0x836687d1 0x00000000 0x00000000 0x00000000
and extract the kernel and ramdisk:
$ abootimg -x laf.bin writing boot image config in bootimg.cfg extracting kernel in zImage
And extract the RAM image in a new directory:
$ zcat ../initrd.img | cpio -vid
Preparations for rooting
Annoying abbreviations: LP = Lollipop, MM = Marshmallow, N = Nougat (all codenames for Android versions).
I went for the instructions on this page as well as those specific to H815, even though it’s probably the same with all G4′s. So:
- Went to Settings > About Phone > Software Information (מידע תוכנה) and tap 7 times on build number (מספר יסוד in Hebrew, an awful translation). And it told me that I’m a software developer now.
- Now under General (כללי) I had a new entry, Developer Options (אפשרויות פיתוח, another horrible translation), confirmed the warning, and enabled USB Debugging (ניפוי באגים). And confirm the warning.
- Also checked “Allow disable OEM lock” (or something like that, this is a translation from Hebrew). Otherwise “adb reboot bootloader” fails (boots normally).
Getting the tools up
I went for Windows as the platform for the tools, mainly because most flashing tools are for Windows.
- Downloaded ADB and fastboot (platform tools) from here (following suggestion on this site). Note that there’s platform tools for Linux (unlike other utils), and it’s probably a better idea.
- Extracted the zip file into c:\platfrom-tools and ran
adb devices
from DOS window. The phone requested permission to allow access from the computer, and once granted, the phone was listed as “unauthorized”. But that was just because I granted a one-time access when the phone asked me about it. Giving it permanent access made the phone listed as “device”, as it should:
C:\>adb devices List of devices attached LGH81530828bea device
- Ah, if “adb devices” lists it as “offline”, just move to another USB port. Don’t know why it matters, but it works.
- I went “adb reboot bootloader” to invoke Fastboot Mode, and indeed I got some very tiny text on the phone, above the LG logo. The phone identified as USB 0x18d1/0xd00d, and Windows classified it as “Other Device” named “Android”, and claimed having no driver for it. So I reinstalled adb with adb-setup-1.4.3 downloaded from here. This made adb installed system-wide, albeit the device was still undetected. Going further, I downloaded the driver package from here, even though I could see that the device ID wasn’t listed in the .inf file, and indeed that didn’t help. The version of the Mobile Drivers was the latest at the time (4.8.0). I found the solution ultimately here, downloading the file called CT_HsPhone_General_Drivers.rar, and the driver for the device, in fastboot mode was there, and I installed it from the Device Manager. This would probably be much easier on Linux.
- I tried “adb reboot recovery” but the phone woke up with a dark screen and it said “Žádný příkaz” which apparently means “No command” in Polish. So clearly, no proper recovery image on my phone.
Money time (not)
- Download TWRP 3.6.1_(-0 for H815 from this page. There’s a different (?) TWRP for virtually every model, but apparently there’s one covering all G4′s.
- I intended to install TWRP in the recovery partition as suggested on this page, but never got to that.
- I also downloaded SuperSU, but likewise didn’t get to use it.
And why did I stop here? Well, in Fastboot Mode, this session says it all:
C:\>fastboot devices 30828bea fastboot C:\>fastboot flash recovery S:\android-upgrade-stuff\twrp-3.6.1_9-0-g4.img target reported max download size of 536870912 bytes sending 'recovery' (21976 KB)... OKAY [ 0.510s] writing 'recovery'... FAILED (remote: device is locked. Cannot flash images) finished. total time: 0.541s C:\>fastboot boot S:\android-upgrade-stuff\twrp-3.6.1_9-0-g4.img Sending 'boot.img' (21976 KB) OKAY [ 0.488s] Booting FAILED (remote: 'unlock device to use this command') fastboot: error: Command failed
so the device is locked.
I wonder what would happen if I wrote the image to the partition in Download Mode, with a shell command, as described below. I guess the TWRP would run, and I guess SuperSU would get installed, but would that root the device? Given that the trick in Download Mode got me what I wanted (a full backup of /data), it was pointless to risk messing up a working phone for this purpose.
SALT and FWUL
SALT is the superior tool for accessing the device (explanations here), and is probably the only way to fully backup the phone, including things that are inaccessible without rooting the phone. It’s a GUI tool written in Bash shell script (!) with yad, and is to a great extent based upon the lglaf utility set.
Its main advantage is that the phone is in Download Mode, running a simple protocol (LG LAF) that allows simple commands to be made as root. So it’s possible to read and write into any file, including the block devices that represent flash partitions in /dev.
Another interesting feature of SALT is the ability to open a shell as root (under the advanced menu). However even as root, certain operations are not permitted, apparently because of SELinux. And it’s a fake shell window — each command is sent individually, so e.g. changing directory has no effect, and it’s not possible to invoke background processes.
Since all partitions can be read from, any information on the phone is available. It’s also possible to replace to bootloader completely, along with other images, which is how the UsU unlock is made possible.
To use SALT, I went for FWUL (Forget Windows, Use Linux), downloaded from this page. Then ran the ISO image inside a VMPlayer virtual machine.
FWUL is Manjaro Linux, based upon Arch Linux (hello pacman) without ability to install an NFS mount by default (or else how am I supposed to store a 30 GB image?). And once I did install mount utilities with pacman, and overcame some Glibc conflicts, it turned out that I had to add the “insecure” option in the /etc/exports file of the NFS host, because it connects from an port < 1024.
In short, it’s not FWUL, but AWFUL. If it’s intended for Linux newbies, it can’t be based upon an unfriendly distribution. It has no netcat, there’s only leafpad for a GUI text editor (first time I heard about it) or go for vim (even the command “vi” didn’t work).
The password for both “android” user and root is “linux”.
“adb devices” failed to detect the phone, on the virtual machine as well as on bare metal, even though the phone’s internal storage was available through the USB interface, so it was clearly properly detected by the system.
However SALT did detect the phone in download mode, so it was good enough.
To invoke download mode: Turn the phone off, disconnect whatever was in its USB / power input, press the volume up button, and insert a USB cable connected to a computer (not just a power source).
I attempted a full partition backup into an NFS mount, and it got stuck, so wrote the ISO image on a USB stick (plain cat xxx.iso > /dev/sda) and ran it on a computer directly. But that wan’t the problem. The whole partition backup into images doesn’t really work for large images, even not on bare metal: Somewhere after 400-600 MB, the data transfer got stuck (the image file written to stopped growing). Sometimes even earlier. Which can explain why the “Basic” backup offered by the SALT grabs images of up to 260 MB.
Unlocking the UsU way
The official LG way was not supported when I got to this, so I went for the scary option.
The description for how to unlock the phone is on this page. It can’t be too emphasized that getting this wrong will hard brick the phone. The basic idea is to overwrite three crucial partitions with alternative images, and good luck.
SALT identified the ARB (AntiRollBack) version as 0, as expected from this page, so this was a green light to proceed.
However at this point I realized that UsU pretty much messes up the phone’s internals (there’s a warning about reducing video frame rate…!), so I just left it. Given that the reason for doing this is to make a full backup as root, the chance for bricking the phone made all this pretty much pointless.
Backing up all data as root
Since Download mode allows sending shell commands as root, and there’s the tar utility available, why not make one big tarball, and bypass the access restriction of a regular user? It turns out it’s not that simple. This is what happens in Download Mode (and not otherwise):
# gzip -: gzip: Permission denied # tar -: tar: Permission denied
So probably by virtue of SELinux or something, these two functions can be run as a regular user, but not in Download Mode. How clever is that? Not at all. Security by obscurity at its worst.
The basic rule is that if you have shell access, you can do everything. I might as well have compiled my own utilities and put them on the filesystem. But why bother? Both utilities are there, so just copy their content:
# cat /system/bin/tar > /mytar # cat /system/bin/gzip > /mygzip # chmod 0777 mygzip mytar
And all that is left to do is
# ./mytar -c --exclude=data/a.tgz data | ./mygzip -c > data/a.tgz
A few notes:
- All commands are given from the root directory. So I use with and without trailing slash interchangeably.
- The -v flag caused the shell window to crash right away. Too much output, I guess.
- The -z flag caused tar to use the regular gzip executable, so it failed. Hence the pipe to my own gzip.
So this ran for a while, and then I got:
/home/android/programs/lglafng/lglaf.py:564: DeprecationWarning: The 'warn' method is deprecated, use 'warning' instead _logger.warn(e) LGLAF.py: WARNING: [Errno 110] Operation timed out
Like, really? No kidding. This takes time. And after this message, any attempt to do something with the phone failed until it was repowered with the battery. So maybe the command kept running, and therefore? I don’t know.
To make a long story short, adding an ampersand at the end of the command doesn’t make the command go into background. So that doesn’t solve anything. So I tried with a little shell script that makes the call go into background, maybe?
Using echo commands, I set up this little file as together.sh:
#!/system/bin/sh
./mytar -c --exclude=data/a.tgz data | ./mygzip -c > data/a.tgz &
and then I went
# chmod 0777 together.sh
and then I ran together.sh. That didn’t run in the background either, and soon enough I got the timeout message again. Sigh.
But this time I decided to just let the phone be and not touch anything for a few hours. Maybe it still runs.
After a while I got back to the shell window, tried some random command, and it emitted the following:
./mytar: data/misc/camera/cam_socket1: socket ignored ./mytar: data/misc/camera/cam_socket2: socket ignored ./mytar: data/misc/location/mq/alarm_svc: socket ignored ./mytar: data/misc/location/quipc/gsiff_socket: socket ignored ./mytar: data/misc/perfd/mpctl: socket ignored ./mytar: data/data/com.zhiliaoapp.musically/files/socket_pipe: socket ignored ./mytar: data/property/.temp.oflBVX: Cannot open: Permission denied ./mytar: data/property/persist.sys.multi-cust: Cannot open: Permission denied ./mytar: data/property/persist.sys.cupss.default: Cannot open: Permission denied ./mytar: data/property/persist.sys.ntcode-changed: Cannot open: Permission denied ./mytar: data/property/persist.sys.ntcode: Cannot open: Permission denied ./mytar: data/property/persist.sys.mccmnc-list: Cannot open: Permission denied ./mytar: data/property/persist.sys.subset-list: Cannot open: Permission denied ./mytar: data/property/persist.sys.cupss.integration: Cannot open: Permission denied ./mytar: data/property/persist.sys.cupss.subca-prev: Cannot open: Permission denied ./mytar: data/property/persist.sys.cupss.subca-prop: Cannot open: Permission denied ./mytar: data/property/persist.sys.cupss.next-root: Cannot open: Permission denied ./mytar: data/property/persist.sys.cupss.prev-rootdir: Cannot open: Permission denied ./mytar: data/property/persist.sys.cupss.changed: Cannot open: Permission denied ./mytar: data/property/persist.service.bdroid.a2dp_con: Cannot open: Permission denied ./mytar: data/property/persist.service.bdroid.scms_t: Cannot open: Permission denied ./mytar: data/property/persist.sys.emmc_size: Cannot open: Permission denied ./mytar: data/property/persist.profiled.build.version: Cannot open: Permission denied ./mytar: data/property/persist.lge.appman.installstart: Cannot open: Permission denied ./mytar: data/property/persist.sys.thermald_miti_off: Cannot open: Permission denied ./mytar: data/property/persist.lge.appman.errc_done: Cannot open: Permission denied ./mytar: data/property/persist.radio.adb_log_on: Cannot open: Permission denied ./mytar: data/property/persist.radio.ril_payload_on: Cannot open: Permission denied ./mytar: data/property/persist.sys.first-mcc: Cannot open: Permission denied ./mytar: data/property/persist.sys.first-boot: Cannot open: Permission denied ./mytar: data/property/persist.sys.mcc-list: Cannot open: Permission denied ./mytar: data/property/persist.sys.sim-changed: Cannot open: Permission denied ./mytar: data/property/persist.sys.clientid-changed: Cannot open: Permission denied ./mytar: data/property/persist.sys.first-mccmnc: Cannot open: Permission denied ./mytar: data/property/persist.lge.appbox.ntcode: Cannot open: Permission denied ./mytar: data/property/persist.sys.iccid: Cannot open: Permission denied ./mytar: data/property/persist.sys.iccid-mcc: Cannot open: Permission denied ./mytar: data/property/persist.radio.add_power_save: Cannot open: Permission denied ./mytar: data/property/persist.radio.eons.enabled: Cannot open: Permission denied ./mytar: data/property/persist.sys.dalvik.vm.lib.2: Cannot open: Permission denied ./mytar: data/property/persist.sys.language: Cannot open: Permission denied ./mytar: data/property/persist.sys.country: Cannot open: Permission denied ./mytar: data/property/persist.sys.localevar: Cannot open: Permission denied ./mytar: data/property/persist.radio.first-set: Cannot open: Permission denied ./mytar: data/property/persist.lg.data.dsqn: Cannot open: Permission denied ./mytar: data/property/persist.sys.profiler_ms: Cannot open: Permission denied ./mytar: data/property/persist.sys.theme0: Cannot open: Permission denied ./mytar: data/property/persist.sys.theme: Cannot open: Permission denied ./mytar: data/property/persist.sys.cnd.iwlan: Cannot open: Permission denied ./mytar: data/property/persist.service.bdroid.bdaddr: Cannot open: Permission denied ./mytar: data/property/persist.radio.sms_ims: Cannot open: Permission denied ./mytar: data/property/persist.security.sdmediacrypto: Cannot open: Permission denied ./mytar: data/property/persist.radio.flex.orgVals: Cannot open: Permission denied ./mytar: data/property/persist.radio.flex.orgSBPs: Cannot open: Permission denied ./mytar: data/property/persist.data.sbp.update: Cannot open: Permission denied ./mytar: data/property/persist.radio.first-mccmnc: Cannot open: Permission denied ./mytar: data/property/persist.sys.factory.status: Cannot open: Permission denied ./mytar: data/property/persist.audio.nsenabled: Cannot open: Permission denied ./mytar: data/property/persist.audio.voice.clarity: Cannot open: Permission denied ./mytar: data/property/persist.camera.ais.hal: Cannot open: Permission denied ./mytar: data/property/persist.data.rear.minfps: Cannot open: Permission denied ./mytar: data/property/persist.data.front.minfps: Cannot open: Permission denied ./mytar: data/property/persist.mms.pre-install: Cannot open: Permission denied ./mytar: data/property/persist.gsm.sms.forcegsm7: Cannot open: Permission denied ./mytar: data/property/persist.gsm.mms.enabled: Cannot open: Permission denied ./mytar: data/property/persist.gsm.mms.roaming.enabled: Cannot open: Permission denied ./mytar: data/property/persist.sys.wificountrymcc: Cannot open: Permission denied ./mytar: data/property/persist.sys.cust.latamspanish: Cannot open: Permission denied ./mytar: data/property/persist.sys.timezone: Cannot open: Permission denied ./mytar: data/property/persist.sys.usb.config: Cannot open: Permission denied ./mytar: data/property/persist.sys.security: Cannot open: Permission denied ./mytar: data/property/persist.radio.iccid-changed: Cannot open: Permission denied ./mytar: data/property/persist.radio.sim_mccmnc: Cannot open: Permission denied ./mytar: data/property/persist.radio.sim-spn: Cannot open: Permission denied ./mytar: data/property/persist.data_netmgrd_mtu: Cannot open: Permission denied ./mytar: data/property/persist.radio.clir: Cannot open: Permission denied ./mytar: data/property/persist.radio.nitz_lons_0_0: Cannot open: Permission denied ./mytar: data/property/persist.radio.nitz_lons_1_0: Cannot open: Permission denied ./mytar: data/property/persist.radio.nitz_lons_2_0: Cannot open: Permission denied ./mytar: data/property/persist.radio.nitz_lons_3_0: Cannot open: Permission denied ./mytar: data/property/persist.radio.nitz_sons_0_0: Cannot open: Permission denied ./mytar: data/property/persist.radio.nitz_sons_1_0: Cannot open: Permission denied ./mytar: data/property/persist.radio.nitz_sons_2_0: Cannot open: Permission denied ./mytar: data/property/persist.radio.nitz_sons_3_0: Cannot open: Permission denied ./mytar: data/property/persist.radio.nitz_plmn_0: Cannot open: Permission denied ./mytar: data/property/persist.radio.keyBlockByCall: Cannot open: Permission denied ./mytar: data/property/persist.radio.airplane_mode_on: Cannot open: Permission denied ./mytar: data/property/persist.sys.webview.vmsize: Cannot open: Permission denied ./mytar: data/property/persist.sys.theme10: Cannot open: Permission denied ./mytar: data/property/.temp.gaiLAw: Cannot open: Permission denied ./mytar: data/property/.temp.E6U7qM: Cannot open: Permission denied ./mytar: data/system/ndebugsocket: socket ignored ./mytar: Error exit delayed from previous errors
and then I restarted the shell window because apparently the responses to commands I got didn’t make sense.
I don’t know if this is all output that the tar operation generated, and neither do I know if it made any difference that I ran the command from this special script file as opposed to the original attempt — both ended with a timeout, after all.
But the fact that I got tar’s exit message, and it wasn’t that it ran out of disk space: The command finished successfully (with some 200 MB disk space left).
So that left me with moving the file where it will be visible as a regular user:
# mv data/a.tgz data/media/0/ # chmod 666 data/media/0/a.tgz
And that’s it. I got a full backup, minus the files listed above (I think, maybe there were more). The backup includes WhatsApp’s private files, and the key, which is the really important part.
I fetched the file with scp using Dropbear, with that app’s regular credentials.
To remove the file, I had to get into Download Mode again.
The phone was never rooted.
Jots while trying to find resources on the web
Incomplete, sometimes duplicates of things said above.
- There’s Terminal Emulator (running on the machine itself).
- There’s an Dropbear, and 4SSH server (go for former).
- How to root G4, or more specifically a H815: Here and here (probably the same). In essence, the process consists of unlocking the bootloader and install TWRP recovery. This allows running SuperSU root tool (or something else). But this is the most accurate page to relate to.
- LG Bridge is the tool for upgrading and backing up an LG phone. Available only for Windows and Mac. There are indications that is supports G4.
- Upgrading to Nougat: Unofficial guide
- There are two unoffical, yet popular tools for flashing an LG: LGUP and LG Flash Tool, and it seems like LGUP is generally preferred, Not clear why use them and not LG Bridge. There’s also Uppercut, which is a utility allowing LGUP to detect virtually any LG device.
- There’s a tool for extracting LBF (backup files), however written in Python. But it worked with no issue on ruhe. That said, the backup content was pretty opaque and minimal, so it’s not all that useful.
What updating to Nougat would have meant
Even though I didn’t eventually update my phone to Nougat, I did fetch the official LG-H815_Official_v29A.zip file. Opening this zip file, it’s a whole lot of .bin files, each to be written to a different flash partition.
Some are ext4 filesystems, some are Android boot files, and some are well, who knows. The easy way to tell is to use the “file” utility, e.g.
$ file system.bin system.bin: Linux rev 1.0 ext4 filesystem data, UUID=da594c53-9beb-f85c-85c5-cedf76546f7a, volume name "system" (extents) (large files)
So it’s ext4? Great, let’s mount it (create /mnt/tmp first, right?):
# mount -o loop system.bin /mnt/tmp
What’s really unpleasant is that aboot.bin and boot.bin are also updated. That’s bootloaders. And laf.bin, which I guess is the image for Download Mode. In short, if this fails, your phone is really bricked.
The procedure is outlined in META-INF/com/google/android/updater-script inside the said ZIP file, which is apparently executed by the “update-binary” program in the same directory. Anyhow, the updater-script file is as follows:
ui_print("");
ui_print("*****************************************");
ui_print("* *");
ui_print("* Nougat *");
ui_print("* *");
ui_print("* for LG G4 H815 *");
ui_print("* *");
ui_print("*****************************************");
ui_print("");
ui_print(" ..please wait.. ");
ui_print("");
ui_print("Un-Mounting partitions...");
ifelse(is_mounted("/system") == "/system", unmount("/system"));
ifelse(is_mounted("/data") == "/data", unmount("/data"));
ifelse(is_mounted("/modem") == "/modem", unmount("/modem"));
ifelse(is_mounted("/recovery") == "/recovery", unmount("/recovery"));
ui_print("Flashing Nougat...");
ui_print(" ");
package_extract_file("aboot.bin", "/dev/block/bootdevice/by-name/aboot");
package_extract_file("factory.bin", "/dev/block/bootdevice/by-name/factory");
package_extract_file("hyp.bin", "/dev/block/bootdevice/by-name/hyp");
package_extract_file("laf.bin", "/dev/block/bootdevice/by-name/laf");
package_extract_file("pmic.bin", "/dev/block/bootdevice/by-name/pmic");
package_extract_file("raw_resources.bin", "/dev/block/bootdevice/by-name/raw_resources");
package_extract_file("rpm.bin", "/dev/block/bootdevice/by-name/rpm");
package_extract_file("sbl1.bin", "/dev/block/bootdevice/by-name/sbl1");
package_extract_file("sdi.bin", "/dev/block/bootdevice/by-name/sdi");
package_extract_file("sec.bin", "/dev/block/bootdevice/by-name/sec");
package_extract_file("tz.bin", "/dev/block/bootdevice/by-name/tz");
package_extract_file("boot.bin", "/dev/block/bootdevice/by-name/boot");
package_extract_file("modem.bin", "/dev/block/bootdevice/by-name/modem");
package_extract_file("system.bin", "/dev/block/bootdevice/by-name/system");
package_extract_file("recovery.bin", "/dev/block/bootdevice/by-name/recovery");
ui_print("Finished!");
Unrelated: Prevent Windows from messing around
This is a little private note on how to prevent the computer that runs Windows from accessing the real Internet. Because if it does, it starts an update frenzy.
I run this on the computer that is the gateway to the internet on the LAN, of course.
# iptables -I FORWARD -s 10.1.1.11 -j droplog