Weird, after reading
https://android.googlesource.com/platform/external/avb/+/master/README.md#Locked-and-Unlocked-mode
It seems to me that if the bootloader is unlocked, a corrupted or non-matching vbmeta shouldn’t matter as it is supposed to be ignored.
is there any error indication in fastboot? what does it say?
Is there a possibility that your device actually boots further than anyone elses by loading the kernel and only failing because it can’t find the root / /system partition?
Some news, since I flashed the vbmeta 1.0, I have a longer boot. Someone as a boot.img to try? (The tests won’t have too many parameters)
The sites lists several occurences for hidden serial pins in other ports. The headphone jack is only one of them.
Problem is they all are vendor specific hacks and need some kind of activation, for example sending +3.3V to the right speaker out in case of the nexus headphonejack circutry.
I’m a little afraid to damage my phone tbh xD.
If you want to build that nexus 4 adapter, check if your usb to uart adapter can read 1.8V, because all that cirutry does is to limit the voltage comming from the usb to uart adapter but does not upscale the voltage coming from the phone. Some 3.3V usb to uart have there cutof for low voltage beneath 1.8V they should work, but a lot of them have the cutofvoltage around 1.8V or even 2V, so you wont get output or random garbage.
Quickly reading over suzy-q cable https://wiki.postmarketos.org/wiki/Serial_debugging#Suzy-Q_debug_cable and android debug cable https://wiki.postmarketos.org/wiki/Serial_debugging#Android_Debug_Cable and the usb type-c plug https://www.allaboutcircuits.com/technical-articles/introduction-to-usb-type-c-which-pins-power-delivery-data-transfer/
the interesting pins are cc1, cc2, sbu1 and sbu2
sbu1 and sbu2 are not used in normal operation mode on the usb type-c plug
what google did for the pixel phones was to use these two pins as uart.
For the pixel 1 you had to put specific resistors on cc1 and cc2 to switch them on, on pixel 2 and pixel 3 they seem to be just permanently active.
since the fp3 has a usb type-c port i think it’s most likly that if tx and rx are accessible from the outside they are be accessible over the usb type-c port (short explanation behind this educated guess: somewhere i read the reason the nexus phones used the headphone jack in the first place instead of the usb port was that the micro usb port has only 5 pins and 4 of them are mandatory for adb, so for uart and adb debuging over micro usb you had to permanently switch cables. When the uart is in the headphone jack you can have uart output and an adb shell in parrallel. with the 2 unused pins on the usb type-c connector this isn’t a problem anymore)
Has someone a usb type-c breakout board at hand and can probe these two pins on bootup?
If that doesn’t help, next thing to try would be to put the resistory on cc1 and cc2 like with the suzy-q cable and then test again (the suzy-q cable is nothing more than a usb 2.0 hub + usb-to-uart + these 2 resistors in a small form factor, enabeling uart and adb with just one cable instead of 2 + a breakoutboard + a usb-to-uart adapter)
edit: all this is just wild speculation i haven’t tested anything yet
Another direction. We so far tried - with no luck - to get data out of incremental updates pushed to Fairphones.
The red flag in our faces should be update 39ce8 which coexists with update d1e8 to both get the version to A0096 but from different source versions.
Either of those got offered to users based on their existing system version. So the update process tries to find a matching version. I did some googling, and there are suggestions in other forums (unfortunately without further info) that this process is standardised and automatically selects a FULL UPDATE if no incremental patch is available for the combination. So its entirely possible that someone who never updated their fairphone might eventually get offered a full update.
But that takes too long. Can’t we just re-create this “check update handshake” and request a matching update from A.0000 to A.0105? and get offered free cake in form of a full update?
Which app does the checking? If its the “Settings” app, its part of AOSP:
https://android.googlesource.com/platform/packages/apps/Settings.git
When you earlier wrote
I already suspected that this could not be the case and that there should be some mechanism to check integrity, or at least current version, before patching, and maybe fail or maybe offer the full image in case the version was not compatible.
I have a brand new FP3, still on the box. I tried switching it on to check it works, but did not make any update. If you fail to recreate the “check update handshake”, I can by tomorrow check the version of my phone and try to get the full update. You must however explain me how to get a link to the update, or the whole update from the phone. I am an experienced Linux user, but I am not familiar at all with smartphone hacking (always had a feature phone till now).
it’s possible that you need to let the phone start downloading the update - then interrupt the download (for example by turning wifi off)
see https://www.droidviews.com/ota-update-file-download-link-android/ for info
Perfect, I try this evening when I’m back home and let you know. The possibility exists that the current version on my phone is one for which a diff update is available, in which case it would probably not help much. So going on with hacking the update handshake is probably a good idea anyhow 
.
@_tmp your skills could come in helpful. After a bit of searching, I found out that it is indeed the “google play services” that check for availability of updates - it looks like not just the updates themselves are delivered through google, but the process for checking update availability for a phone is also handled by google API and cloud on server side, and the com.google.android.gms app (Google Service Framework) on the client side.
The particular function is called the “Checkin Service” which periodically or when forced to do so through settings menu or through a particular “hack” using the “com.google.android.dialer” app (entering *#*#checkin#*# in the dial pad (no need to confirm that, it responds immediately to the last digit typed)
I think it sends the phones info to https://android.clients.google.com/checkin but what happens beyond that is beyond my expertise. Can we reverse engineer that to request an update URL?
Edit: In googling for info, I came across this automated malware analysis report. Someone uploaded the google service framework apk to an automated malware analysis site - the analysis is both accurate, and amusing
https://www.joesandbox.com/analysis/39495/0/html
spolier: it’s classified as spyware
You can try to set a system proxy to burp (add the burp certificate to the roots cetificates of the phone) to analyse the requests but the certificates are probably pinned to the app.
https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning#Android
Try any https website to check the proxy before.
edit :
It seems possible https://habr.com/en/post/446790/
edit:
If we re able to install the update app as user.
bypass certif pinning : https://blog.netspi.com/four-ways-bypass-android-ssl-verification-certificate-pinning/
That is one awesome report. A shame he didn’t get the google job, but well… Interview phone calls suck, they always get you on the wrong foot.
I have to say, this doesn’t look promising, if Google put up so much obfuscation in the way of the check-in, too, then to effectively fake the firmware version (short of spending a week or two coding custom bytecode interpreters in Java) you’d need to root the phone and make whatever app is querying it see a different version.
Intercepting doesn’t seem possible, as Android9 certainly DOES use certificate pinning.
Btw, right now when I check for upgrades, the upgrade check fails with an error/timeout! (the phone is currently unlocked, but not flagged as tampered) Although it could be my firewall being responsible, i haven’t turned it off yet.
A guy did it for HTC : GitHub - sabpprook/HTC_OTA_Downloader: A tool to fake HTC OTA request and get OTA package
Build OTA packages | Android Open Source Project
Caution: For the best user experience, you should offer a full update for every 3–4 incremental updates. This helps users catch up to the latest release and avoids a long install sequence of incremental updates.
Hopefully, the next one will be a full update.
I don’t know if we can have some information about the request with one of the 2 methods here (a bit changed): Build OTA packages | Android Open Source Project
I now have a brand new FP3 showing the build number 8901.2.A.0096.20191001. It is then September 2019, v. A.0096. It proposes me to update to FP3 A.0105, and the retrieved link with adb logcat is https://android.googleapis.com/packages/ota-api/fairphone_fp3_fp3/fa9bb735697684d6cc7ba0686f5a396df005de00.zip.
This file also contains a payload.bin and seems to be structured in the same way as the other updates, so I doubt that it is a full image. Anyway, hope this helps.
Google has already published the January update, but Fairphone is yet to do so. Have you updated yet? If not, I’d kindly ask you to wait until that update is also out, to see if you get offered a new one, if that is not too much trouble. 
My FP3 is back in the box and I have no intention of using it or making any update before it is rooted and I manage to make a full copy of its firmware and OS in the exact state it is now after a factory reset.
So yes, I’m definitely willing to offer any help I can, with the (limited) skills/ressources I have. Just let me know when FP January’s update is out.
Hi, very cool
Which pads did you check?
The ones labeled with K,L or the ones labeled S,T, ? (As seen in the pics from k65onyx)
I already soldered wires onto I,K and L but there is not much going on there.
awesome.
From the table on https://github.com/k65onyx/fp3-notes - R, S & T are the most likely candidates. An UART’s Rx has an internal PullUP, which would explain the High signal when not connected, then S could be the Tx, and R the matching GND line, - just guessing from the table. I haven’t measured or probed anything yet.
To actually interface you need an 1.8 V UART interface, all the ones I still have lying around are 3.6 V.
Hi, I also thought about R, S & T in the beginning. But then I’ve read the post from Matombo. I kind of overlooked that there are other signals with 1.78 Volt. So I wanted to ask for confirmation before I solder around in my phone again . I replied to a rather “old” post I hope he or she sees it.
Thanks for the hint with the 1.8 V UART I’m also not sure If I have hardware for that available. Maybe I can maybe try to record the waveform and then postprocess.
What you could do is power the phone while open. It won’t be able to actually boot, but the bootloader should give out some UART debug output even with most periphery disconnected. Enough to identify the correct pad with a probe (without actually soldering anything to the pads - yet)
Of course that only makes sense if you actually have an oscilloscope (or at least a software-oscilloscope on a USB stick) and a probe
The physical placement of the pads can be a hint (although no guarantee) about what is what. Pad’s A-F are next to the Wifi chip and the connectors to the side- buttons, (power, vol up+down) so it’s likely they debug that functionality
Pad’s G-Q are between CPU and the connector to fingerprint, backcamera, speaker, etc… - as such they could be anything, but some have already been identified to be connected to fingerprint sensor stuff
Pad’s R,S,T are between CPU and SD-card … there isn’t really anything debug-worthy on an SD-card, so the most likely thing would be something CPU related, like a debugging serial port (but could be something as stupid as power management, which is on the other side of the motherboard in the same area)
Pad’s U,V,W are nestled between sim cards, which are next to the RF modem, so they might be GSM debugging related stuff, or related to the display or NFC chips (which are on the other side of the board in the same location)
That’s why I think R-S-T are the most likely candidate, they tick all the boxes:
1: There’s three of them (which you need for UART)
2: One of which seems to be pulled up (which you’d expect from UART Rx)
3: One of which seems to be GND (which you need for UART)
4. They are next to the CPU
5. They are not next to an obvious alternate candidate
6. They are in a place from which you can relatively easily route a cable to the outside (at least with removed back-cover) using the opening for the sdcard
But I haven’t measured anything myself yet, so above is only an indication, no proof.
Signal for the T :
Signal for the L :
I wasn’t able to have the signal before in the boot process. This signal shall be when the phone is in the bootloader
If someone want to try the UART and has only a USB to UART 3.3V or a raspberry pi, here is a simple schema for an adaptater : https://electronics.stackexchange.com/questions/333229/1-8v-uart-with-3-3v-uart
