search

TheCrypt0 / yi-hack-v4

New Custom Firmware for Xiaomi Cameras based on Hi3518e Chipset. It features RTSP, SSH, FTP and more!
GNU General Public License v3.0
1.56k stars 219 forks source link

RTS3903N reset pin #348

Open hinxx opened 3 years ago

hinxx commented 3 years ago

Do you guys know which pin on the RTS3903N IC is the main reset pin? I'm trying to dump the SPI flash and the RTS3903N keep interfering with the SPI bus to the on board W25Q128 flash. The plan is to keep the RTS3903N in reset while providing the external power to the flash and reading out its contents.

LuckyBenski commented 3 years ago

Honestly you could just try grounding each pin one by one while observing the system. However I've come back to my RTS3903N project after a year and it seems a few people have made progress with this CPU in similar cameras. This method especially seems to be promising for dumping the flash to an SD card:

https://drmnsamoliu.github.io/flashdump.html

Do let me know if you make any progress! I'll probably start to try hacking this camera again soon.

hinxx commented 3 years ago

Grounding the pins sounds like a risky task. I might be creating a short circuit if +3.3V pin gets grounded. Also the tiny pins on the SoC do not help.

Anyways, I managed to to desolder couple of flash chip pins and dumped the contents with buspirate.

I was also looking for uart pins to skip this way of getting the firmware out. I did identify the pads on the PCB but when probed with the scope they were showing activity motor movement; every time up/down and left/right motor would be active the tx or rx pad signal would show activity. Somehow this behavior does not resemble an uart rx/tx AFAICT. Probing with ohm meter I found out that both rx/tx labeled signals were routed to the motor driver IC. I was also probing some other resistors and unpopulated locatiins trying to figure out if some 0ohm resistors could be missing but did not get far.

At the moment I have the rootfs and can see how the upgrade payload gets onto device. I still need to dig into the binary that does the payload sanity checks, verification et.al. in order to feed it my custom rootfs via update. I was trying to run the binary in the qemu but so far not mich success on that front. Seems like I will need to statically decompile and dive into the binary.

Good luck with your haxx!

cjj25 commented 3 years ago

@hinx,

SD pins: 18-22 UART: 38-39 (often disabled in UBOOT) and/or then mapped to GPIO for motor output 78-67: GPIO (ish, never finished mapping) 73: possible reset 40-44: SPI

I never completely finished reverse engineering the pin layout. I have managed to compile a completely new firmware using the turnkey SDK.

hinxx commented 3 years ago

Thanks @cjj25 !

I partially gave up on reset pin hunt, and stopped looking into the UART because it is behaving similar to what you described; I see motor signals on Rx/Tx lines (on pads I found on the PCB). Not sure if there's any UART data on them very early i.e. in u-boot, though.

I might test out the possible reset pin next time I'm tinkering with the hw at that level!