[ot][personal][spam] trying to make my unihertz titan boot
There's normative open source android firmware, I have a gift phone that doesn't work yet, and I have a little experience debugging firmware now from coreboot. Just a little bit. I'm thinking if it doesn't work, I can in the worst case copy some assembly from the working firmware, to maybe provide a usb device or light an led, and possibly bisect problems to troubleshoot. If I can keep it up. We'll see. The unihertz thread shows ValdikSS got treble_experimentations to work from a release on January 18th, 2021. There's a strange inconsistency, unfortunately: the instructions say twrp can be used, but the twrp post is later that year. Still, it makes sense to try the last release prior to Jan 18, 2021.
My host system is in windows right now, so this is a good time to first try anything that might need a factory reflash to repair. - the phone presently appears to have factory firmware enough to show the logo when charging. the battery is dead. Maybe I can prepare to install TWRP. Looks like unihertz's flashing tool was updated on apr 27. Oh no it wasn't , just the surrounding folder. 1010a ET . Ok, reading the instructions I think I noted the phone needs to be at 50% . Better check which needs that since it's now at 5% . That's for the vendor flashing tool, so I'll see if it can do fastboot. Back to linux. 1012a . Windows wants to install updates so it will be a bit, rebooting, and I might forget the task. Maybe in the interim I can look for -- oh it finished at 30% . 1014a and linux is booting. 1016a and i'm switching linux to graphical mode so as to download github releases in a familiar way i'll send this so as to look at the release date of interest
it's 1018 my touchpad is broken. this happened on its own for some reason while I wasn't using the system over the past 3-4 months. so maybe i'll download the release from the terminal. 1020 https://github.com/phhusson/treble_experimentations/releases january 18, 2021 1022 it looks like the last tag before that date was v300.l 4a95e7a81499a39bc58844edfa54d94e5c5f42d9 (hand-copied) so it makes sense it didn't work, as treble_experimentations is past v400 now. 1025 ok, the v300 releases are for roar, and the instructions say to download quack :(
i'm guessing the post date is the time of last edit, not the real date so some earlier system-quack-arm64-ab-vanilla . I should probably get all of them. 1028 the last quack was v222 additional quacks: v221, v220, v219, v218, v217, v216, v215, v214, v213, v212, v211, v210, v209, v208, v207 . it would make sense to see if any of those are prior to the release of the phone, in which case I could skip testing them. url format appears to be https://github.com/phhusson/treble_experimentations/releases/download/TAG/sy... 1033
the phone came out dec 2019, which is also the month of the first tag, so they all could be relevent. I had fastboot installed to an external drive which had powered down. thankfully, it powered back up. I was downloading the latest tag with links, but links seems to have mostly frozen up, responding to only intermittent keystrokes. it makes sense to just use curl (aside from that severe concern)
the whole system has now frozen 0_o gotta keep dmesg open next time I power that drive up.
oh whoops, I was just using a broken keyboard. system not frozen, just links. I make errors like that a lot. 1045 v207-v222 fastboot flash system FILENAME https://github.com/phhusson/treble_experimentations/releases/download/TAG/sy... 1047 i've got them all downloading with wget! each one is about 500M and I'm downloading at 1MB/s or so. eventually the free fast data will run out for this month on my phone, and it will slow down significantly.
1056 one of the firmwares downloaded if I let them all download on their own I should move the download to a folder with more space. when I flash it says "not allowed in locked state" which means doing something else first, or flashing a different way. 1058a 1101a On the qualcomm phone, holding power up and down at the same time while plugging the usb cable boots into download mode. I tried that on this phone and it gave me a menu in chinese. One of the items was apparently a button test. I'd like to flash the phone from windows, using the factory flasher. Maybe I can run it in a virtual environment, to facilitate logging possible serial traffic. 1103
1107 booting into graphical mode, I again encountered that my touchpad is broken. these things broke shortly after the warranty expired. it turns out my wifi card disappears when I go into graphical mode, which has halted the download. I found this trying to websearch on the system for gnome mousekeys. 1108 restarting networkmanager got wifi going 1109 ctrl-alt-tab can be used to switch to the gnome task bar like an application. I can get from there to settings but haven't found how to change settings tabs yet. ctrl-alt-tab again brings me to the menu where there is an option for keyboard shortcuts: ctrl-S for search. mouse keys is under universal access. I can hilight the switch for it but neither space nor enter actually toggle it. once hilighted, tab moves inward to the toggle button. it's set! 1113. the mouse is very very slow. modifiers don't seem to speed it up. I guess that's workable. 1115 my virtual machine setup is kinda cool, I have virt-manager using the root partition as a raw image, so I can boot windows and linux from the same disk simultaneously without conflict. this took some websearching and is a little confusing a buggy. 1116 windows is still doing all its updates. maybe come back to this later, unsure
here are some quack b2sums as I have them:
aa80d380ac31502dfc548da57414cd6e56ccd12e21be647f82508bec59ae3f36e4d3eee6d3047c73c03075b5d54c15f7bd6bba90a1bf5f73c26bbd33056e3c1e v207-system-quack-arm64-ab-vanilla.img 919e506e77dd310a76c148211c41727a8fffb282794898cbccac2690f943d41a2646eba57984cdd91206726c2ed32637f87d65316bc74fb7c35f95442ac587d3 v208-system-quack-arm64-ab-vanilla.img 72744ae1014c570b94977023d2c5d5ec76b2cdecd74c5e87b7cffcf87838d3319a8a3130c4e79f59186500e1e8aab0f92428a5bcd08e2e9b767595c4abc287c4 v211-system-quack-arm64-ab-vanilla.img b4e689db62f10fc165abd04d02bf68e5a0280dd5d5c1580ddc9801aff561bcfe9ec94e2768d20ff2eebb6d1e0dd5d05e981ca2c660a55114d1429c2553de3cf1 v212-system-quack-arm64-ab-vanilla.img 3791f1bc635309c439e06e5e3e2774c828cc95d728bbd5eaaa5a0f2d82e08decc648da2cfb30d38c28f45b542cf749c9a6944303dee612003f1963ef6904dc30 v216-system-quack-arm64-ab-vanilla.img 503324691350107f945a1e81c89438eb6d4dde120167eede2d35aee20fb20429949a94da50c457304c009a46ad1ff7d1691158dd19368b1ab44546e8ffea102e v218-system-quack-arm64-ab-vanilla.img 2ef83bd1911c9e4107d28f911ae1566821f5c3fb05f4dbed63be816f64266d60ba2b9b83033099176bff3c1fa64b5c1830561619617ca40053d0f9c0303c73cc v221-system-quack-arm64-ab-vanilla.img 486e3ec3184b203bf87b5a2211d33edd07b0667df57660eca42e386e6f6e0201aba49ec0c25fb30fa22dfada6435d9eda618eadfe276bba62f5bde9dfae7a129 v222-system-quack-arm64-ab-vanilla.img
- the factory flash tool needs the device to be plugged in _after_ it scans or starts - the scatter file it uses is basically just a list of mappings between filenames and partitions: or at least, it performs uploads if I treat it that way - using that approach I flashed the twrp but the phone does not boot when this is flashed. it could be because it's still locked. - the flashing baud rate is 921600 . this may be used to engage the ttyACM serial device the phone briefly exposes before boot. 1328 - I put the system images on a new partition but windows isn't recognising it. I ended up rebooting since kvm didnt seem to be working. noting the size of this partition would let me reformat it under windows. - in the twrp instructions it says "fastboot flashing unlock" , sounds important
when I tried 'fastboot flashing unlock' it said I needed to enable oem bootloader unlocking. I booted into a factory rom and did this under developer settings, doing the dance of repeatedly tapping the build number. maybe this was why it wouldn't boot with partition changes? it's 1414 and it just flashed a v207 with fastboot. when I boot it it successfully shows the unihertz logo, better than when I change the recovery partition which just gives me a black screen. it's 1415 and now I have an android logo which goes to desktop !!!!!! I don't know what I was going wrong before. maybe v222 doesn't work. 1416 1419 I used fastboot to also flash the recovery partition with twrp. it appears to still be failing to boot under this condition. actually it has a black screen and won't seem to shut down or power up at all. 1421 I guess the thing to do is to wait for the battery to die and then reflash it with the factory recovery partition using the official tool. it looks like the device it offers the official tool is likely an MT65xx Preloader, 0e8d:2000
eventually I found from https://www.rigacci.org/wiki/doku.php/doc/appunti/android/sp_flash_tool that the flasher is available for linux (binary only). if it works with my glibc, this could make it much easier to work with. I also took a usb log of the windows flasher using usbpcap. unfortunate since the flasher speaks in com ports. the links from that website jump to various shady binaries, there's something called "miracle box" that can flash most devices, and is closed source. my phone is no longer providing usable tethered internet (~5KB/s when lucky), but works fine nontethered. maybe some business agreement. 2022-05-03 0928 ET so i'm downloading things to the phone and transferring them off adb, which for some reason does not always work, but has been recently. 0936 the linux flash tool launched fine on my ancient glibc, great. unfortunately it says my scatter file is invalid. on the web links they talk about generating scatter files. 0937 the provided sp flasher has "custom" after it. could be related. this flasher has more options, like readback and memory test. 0939 0945 there are some example scatter files at http://www.mediafire.com/file/md5xj1n8mdm0rf9 my vendor scatter file is name MT6771_Android_scatter.txt 0946 1029 so it turns out the partition map ("scatter file") format is forward compatible for _minor_ version numbers. so my scatter file for v3.2128 does not work on v6.1520 but finally _does_ work on linux sp flash v5.2208 . v6 also has the issue of changing the format to xml. I just downloaded all the partitions from linux for the first time! 1031
1035 I used the linux tool to read back some bytes and it looks like the device has a normal dos/mbr partition table, which is cool given all the scatter file weirdness i'm going to struggle and try to strace the serial calls ;p 1035 1048 - scan: checks device tree that pid and vid are correct 1048 1055 it does a bunch of things prep involving "boot rom" and "scert" . each module has its own separate logfile, with source line numbers even. the strace would have been much easier to review if i'd prevent ellision of long strings. then the logs would all be interleaved when written in one doc. fd13 = open("/dev/ttyACM0", O_RDWR|O_NOCTTY|O_NONBLOCK); fcntl(fd13, F_SETFD, FD_CLOEXEC); ioctl(fd13, TCGETS, {B115200 -opost -isig -icanon -echo ...}); I guess I should prevent ellision or put a breakpoint there to get the rest of the serial port config. I can also check with stty. ... ioctl(fd13, TCFLSH, TCIOFLUSH); ioctl(fd13, TIOCMBIS, [TIOCM_DTR|TIOCM_RTS]); that looks important, it could be raising serial lines // log reports open complete, initating connection 1101 write(fd13, "\240" , 1); holy frack the GLB logfile logs raw serial reads and writes! I barely need to use strace. I could start writing a hand flasher from the proprietary flasher's logfile as soon as I had the serial parameters right. maybe I'll make an strace without ellision. 1103
1114 i'm looking at the disassembly around the ioctl calls using gdb. the object actually has debugging symbols, so functions are named. it looks like ioctl is called by passing arguments on registers (fastcall?) here. the first argument is in edi, fd 13. esi, edx, and eax are also set. i'll look up the value for TCGETS in my include files to deduce which register is the second argument for sure. 1116 it turns out esi is the second parameter. here it's TIOCCBRK, so i've actually missed the section of code I wanted to inspect, this run. 1118 1128 looping and catching ioctls with gdb, i'm seeing it differently from the strace. I see TIOCCBRK, then TCFLSH, then TIOCMBIS , but no TCGETS nor TCSETS . when I straced I had to pass -f, maybe I have to get gdb to follow forks too. additionally, I could try restarting the process, it's kind of deep in loops. 1130 set follow-fork-mode parent|child|ask break ioctl commands 1 p/x $edi p/x $esi 1133 it seems strange to me that more ioctls do not show in gdb. I wonder where they are hiding. anyway, I can use strace. 1135 1138 the unabbreviated unellided strace seems nice to me. reviewing the complete ioctls I don't actually see any changes made to the serial. the data set is the same as the data retrieved. I could find where it is set from the strace and figure out what it's ensuring but it probably makes sense to dive into the communication bytes for now. 1140 1157 I manually started handshaking with the flashing protocol in python :) import os # wait for device connection, only provides serial port briefly while True: try: fd = os.open('/dev/ttyACM0', os.O_RDWR|os.O_NOCTTY) break except FileNotFoundError: continue # connected, handshake os.write(fd, b'\xa0') print(os.read(fd, 5)) # prints b'READY'
2022-05-03 I came back to this project and it wasn't working any more. The phone was just echoing the handshake byte. I thought I'd run the mediatek flasher and use stty to capture the serial settings, in case they had changed, but it wouldn't flash either. It said I needed to remove the battery from the phone and press a key sequence to reflash. The battery is behind a number of small hex screws. I reviewed its kind rxtx data log and saw it was experiencing the same behavior as my code, so I added a similar message to my code. What I ended up doing was piping /dev/urandom into the serial port. After some time, this got the serial port to close and the phone rebooted. Doing that doesn't seem to have trashed any partitions yet. Next time I should log the pipe, see if I can figure a bailout sequence. 1900 1916 i'm logging a complete reflash. the tty params are roughly: 1804:0:10b2:a20:3:1c:7f:15:1:1:0:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0 which appears to roughly mean 115200 baud cs8 cread ignpar ixoff ixany nl0 echok echoctl echoke (and nothing else) 1919 the reflash log finished. i'm sending mostly the same stuff as the binary but getting a different reply, so some detailed examination pends. 2022-05-04 0905 I just did the first four bytes handshake successfully. also set the dtr and rts flags. I think some of my successfuly handshakes were reporting as failures simply because I hadn't told my code to stop retrying. this caused both my code and the vendor code to report failure handshaking because it had already happened. might be more than those four bytes though. I have a number of appointments today. 1032 appt time. there is very detailed info. it looks like the flasher uploads device bootloader code to do the flashing. I guess that's normal but it's slightly frustrating. there are chunks of code, the first is about 8k*29 bytes long. lots of embedded flashing code. I think the normal approach is to start by just interfacing with the binary blob. it has an rpc command protocol and the logfile lists the procedure call names, parameters, and results.
On 5/4/22, Undiscussed Horrific Abuse, One Victim of Many <gmkarl@gmail.com> wrote:
What I ended up doing was piping /dev/urandom into the serial port. After some time, this got the serial port to close and the phone rebooted.
When all else fails... ;)
Doing that doesn't seem to have trashed any partitions yet.
Excepting burned in enforcement of SecureBoot style sig checking schemes, don't many phones now have known ways to import completely custom or original disk image, or buildup filesystem from scratch, after total erasure... dd if=/dev/random of=/dev/<phones_flash_media> bs=1m dd if=/dev/zero of=/dev/<phones_flash_media> bs=1m
On Wed, May 4, 2022, 5:23 PM grarpamp <grarpamp@gmail.com> wrote:
On 5/4/22, Undiscussed Horrific Abuse, One Victim of Many <gmkarl@gmail.com> wrote:
What I ended up doing was piping /dev/urandom into the serial port. After some time, this got the serial port to close and the phone rebooted.
When all else fails... ;)
Doing that doesn't seem to have trashed any partitions yet.
Excepting burned in enforcement of SecureBoot style sig checking schemes, don't many phones now have known ways to import completely custom or original disk image, or buildup filesystem from scratch, after total erasure... dd if=/dev/random of=/dev/<phones_flash_media> bs=1m dd if=/dev/zero of=/dev/<phones_flash_media> bs=1m
That's new to me, and is what I'm looking for. Where do I learn more?
My work on this is paused and is at https://github.com/xloem/backyard_mediatek_flasher , where the relevent commands are noted as comments in test.py as I reviewed strace logs. The next step is probably to figure out how to extract the download agent firmware from its binary file, and optionally to extract the index mapping chip indices to their download agent firmwares from the vendor flash tool.
2022-05-05 1902 ET I've written code to parse the download agent firmware for the different mediatek phones and dumped the chip id -> platform table used to index the firmware. It was difficult to do the table dumping. If I've ever written a patcher before, it was a very very long time ago. It uses gdb to load a .so into the binary to output the boost::container::map that the table is constructed into. This seemed easier for me than decompiling all the inlined hardcoded item insertions. Here's the mediatek chipid map, also in git, my big accomplishment today. The gdb code for extracting it is in the git too. chip2platform = { 0x0279: 6797, 0x0326: 6755, 0x0551: 6757, 0x0562: 6799, 0x0601: 6750, 0x0633: 6570, 0x0688: 6758, 0x0690: 6763, 0x0699: 6739, 0x0707: 6768, 0x0717: 6761, 0x0725: 6779, 0x0766: 6765, 0x0788: 6771, # this id is my unihertz titan 0x0813: 6785, 0x0816: 6885, 0x0886: 6873, 0x0908: 8696, 0x0930: 8195, 0x0950: 6893, 0x0959: 6877, 0x0989: 6833, 0x0996: 6853, 0x1066: 6781, }
Turns out there's another one of these at https://github.com/MTK-bypass/bypass_utility/blob/master/src/device.py .
It has a different focus, around using an exploit with phones that are locked to prevent flashing.
Here's another one: https://github.com/bkerler/mtkclient Dev is presently active on that one.
I never figured out mtkclient, unfortunately. I never even got in communication with one of the devs or users. However, I've got all the v2xx phhusson treble builds booting on the device using fastboot, which is great stability on that front. Even running a rooted phone at all would be a step up for me. I'm spending some time trying to build the treble releases from source. This likely means finding a system with more storage space to do the build on.
I made a python package for interface with https://vast.ai to quickly and briefly rent powerful shell servers. `pip3 install libvastai` may function, not certain. I don't know if my local version has import fixes. I've used it to create 3 instances with code like: import vast, logging logging.basicConfig(level=logging.INFO) instance = vast.Instance(GiB = 128) instance.create() instance.wait() the prices range from 9 to 13 cents an hour. if the build is slow, this may be expensive. the plan is to just use whichever one finishes setting itself up first, and destroy the others.
i'm on a machine and have cloned the repo the build-dakkar script is raising command not found around "virtualenv2" not familiar with this command, although i assume it's part of python venv.
`virtualenv2` is supposed to be `python2 -m virtualenv` i patched the build script to do the latter. installing repo.
it looks like the build script is outdated. repo appears to now need python3, but the build script sets up a venv with python 2.
this system is ubuntu 18; it looks like newer version of repo than the one from apt have more tolerance for quirks. found https://storage.googleapis.com/git-repo-downloads/repo-1 from stackoverflow, replaces /usr/bin/repo
repo needs git configure with user and email i'll start a draft to the other thread to put these things in
i've drafted a build script for the other thread. the repo init is going much faster on the remote system. it's cloned 6.8 gigabytes so far, which is more than my free space locally.
the window in which i was editing the build instructions draft was logged out of gmail when i tried to save it. "we're sorry, but your account is temporarily unavailable."
build-dakkar is almost done with repo init i've drafted manual building instructions i'm having a lot of dyskinesia, hard to continue. i'd like next to make build-rom.sh work, it wasn't for me before: https://github.com/phhusson/treble_experimentations/issues/2129
the repo sync has been stalled for some time because one of the gitlab repositories has apparently been renamed since whatever repository list it is using was made
total size of the build folder is presently 68GB gmexpress mentions: .repo/local_manifests/gmsexpress.xml:<project path="vendor/google" name="gmsexpress" revision="master" remote="gms-mirror" /> https://github.com/phhusson/treble_manifest i'm imagining that gmsexpress has moved and phhusson's xml file could use an update
the sync is resuming if i manually change that file to reference that user i'll submit a pull request
i made a github repo with the same name and branch name as phhusson's and modified the build script to check my user before checking his it now proceeds past the repo sync
here's the next issue: out/soong/.bootstrap/bin/soong_build -t -l out/.module_paths/Android.bp.list -b out/soong -n out -d out/soong/build.ninja.d -globFile out/soong/.bootstrap/build-globs.ninja -o out/soong/build.ninja Android.bp error: vendor/foss/SeedvaultOverlay/Android.bp:1:1: unrecognized module type "runtime_resource_overlay" 14:23:47 soong bootstrap failed with: exit status 1
it seems like it would make sense to build the tip release since i have little experience building android roms then of course i could bisect backward to see what changes are associated with what issues the builds are generic, not for a specific phone
so, i tried android 11, v301, and it actually booted !! maybe when i tried last time i just hadn't done the 'flashing unlock' command i can totally use newer git trees than i am. back to bisecting release versions ...
v310 worked fine v313 is just showing me a picture from a donald duck comic on boot ...
the latest release boots. i can switch to the tip sources, and look into other phones.
found finally the building instructions at https://github.com/phhusson/treble_experimentations/wiki/How-to-build-a-GSI%...
the build instructions from the wiki are very simple. it's just one command. meanwhile, the phone i actually use is a free government phone, and i'd like to see what the barrier is around using it with an open source OS. the factory OS has more advertisement apps than normal apps, and it takes a few minutes to respond to a touch. additionally it has some issue going on where when i touch it it may register the touch in a different spot than where i touched, making typing and swiping very hard, and i'm not sure how i would diagnose this on a closed phone. this free government phone has a unisoc chipset. it looks like there's a factory flash tool at https://spdflashtool.com/download/spd-flash-tool-r26-21-2801 . i downloaded the 'treble info' app on it, and it is treble-based, so an open source OS would run. i've heard these phones are locked, and that trying this fruitless. i'd like to learn the detail myself.
building the phh treble git tip failed with this error: [100% 250/250] out/soong/.bootstrap/bin/soong_build out/soong/build.ninja FAILED: out/soong/build.ninja cd "$(dirname "out/soong/.bootstrap/bin/soong_build")" && BUILDER="$PWD/$(basename "out/soong/.bootstrap/bin/soong_build")" && cd / && env -i "$BUILDER" --top "$TOP" --out "out/soong " -n "out" -d "out/soong/build.ninja.d" -t -l out/.module_paths/Android.bp.list -globFile out/soong/.bootstrap/build-globs.ninja -o out/soong/build.ninja --available_env out/soon g/soong.environment.available --used_env out/soong/soong.environment.used Android.bp Killed 17:22:32 soong bootstrap failed with: exit status 1 ninja: build stopped: subcommand failed. often when i see "Killed" it means the system ran out of RAM. the build system has 16G of ram. when you rent them you can specify how much ram to filter by.
reminding myself that the build instructions page links to a telegram community to find the most up-to-date steps
my build host has gone offline theoretically it is still running the build vast.ai says i won't be charged while it is offline i'm worried, however, that if i just let it do it's thing, i will forget it is there, and then when it comes back online i will be charged a lot.
participants (3)
-
grarpamp -
Karl Semich -
Undiscussed Horrific Abuse, One Victim of Many