(TP-Link Firmware Decryption C210 V2 cloud camera bootloaders) https://watchfulip.github.io/28-12-24/tp-link_c210_v2.html?u...
1,419 karma · joined January 23, 2023
(TP-Link Firmware Decryption C210 V2 cloud camera bootloaders) https://watchfulip.github.io/28-12-24/tp-link_c210_v2.html?u...
A lot of TOTP verifiers often check within ±1 time interval, so you can often just use the first code you see, no need e.g. to wait for it to roll over.
For example, the Pintos [0] projects.
0: https://web.stanford.edu/class/cs140/projects/pintos/pintos_...
Plus, the code gives information about the frame it's embedded into, so you still have more work to do.
And you mean the apdp partition, right? That's a weird ELF file, contains almost nothing obvious (test key sig? DEBUG mention) and doesn't seem to be any executable code which I guess makes sense, but I wonder why they made it an ELF. Is there any info on interpreting these profiles?
So that profile gives you the unauthenticated ramdump as well? Seems to be a common theme with OnePlus, messing up security features.
In the device tree I see (snippet):
qcom,msm-eud@1628000 {
compatible = "qcom,msm-eud";
interrupt-names = "eud_irq";
interrupts = <0x00 0xbd 0x04>;
reg = <0x1628000 0x2000 0x162a000 0x1000 0x3e5018 0x04>;
reg-names = "eud_base", "eud_mode_mgr2", "eud_tcsr_check_reg";
qcom,secure-eud-en;
qcom,eud-tcsr-check-enable;
status = "ok";
};
qusb@162b000 {
compatible = "qcom,qusb2phy-v2";
reg = <0x162b000 0x400 0x1b40268 0x04 0x162f014 0x04 0x162a000 0x04>;
reg-names = "qusb_phy_base", "efuse_addr", "refgen_north_bg_reg_addr", "eud_enable_reg";
qcom,efuse-bit-pos = <0x19>;
qcom,efuse-num-bits = <0x03>;
but `devmem 0x162A000 4 0x1` causes the system to lock up and I see the following in ramoops: [ 433.720232] msm_watchdog f410000.qcom,wdt: Causing a QCOM Apps Watchdog bite!
[ 433.727381] msm_watchdog f410000.qcom,wdt: Wdog - STS: 0xb01a6, CTL: 0x3, BARK TIME: 0x57fdf, BITE TIME: 0x6ffd6
I'm not at all sure on the interpretation of this, but the reading at the efuse_addr (so I guess certain ones can be read from EL0?) is 0x0e000000 which has bits 25-27 set and QFPROM fuses seem to have a blown value of 1 according to Qualcomm docs, so it might be fused out?Edit: How are they reading the eFuses on a production OnePlus 6? Do they have a Qualcomm-signed EL3 EDL loader?
It seems to exist as qcom,msm-eud in the device tree of a (unfortunately production) SM4350 device I have along with an eud_enable_reg. Time to recompile the kernel with `/dev/mem`.
Cuttlefish, while it may be a more effective reference device, just doesn't accomplish the same thing because Pixels were used for more than just as a reference target (e.g. GrapheneOS).
Plus, there's just something cooler about running your own build of Android on real hardware v.s. a VM.
I guess as a start the chroot provides glibc and all the other libraries that run natively, but how does any of this interact with hardware?
I wonder how much of this would come down to screen calibration / color accuracy? If everything's consistently off in 1 direction I guess not much, but I would imagine certain shades might appear effectively the same on some cheaper screens?