guino / Merkury1080P

Merkury1080P (CW017) Rooting and Customization
85 stars 17 forks source link

Mini 19S - Exploration documentation #60

Open thomasloven opened 1 month ago

thomasloven commented 1 month ago

Hi!

I found a cheap indoor camera sold under the label "Bright" in Sweden. The board says MINI19S, and firmware is somewhere in the 6.X.X range according to the Tuya app (I just checked quickly and then got that abomination off my phone ASAP).

I've gotten serial output from U-boot but have not been able to interrupt it. It says "Press any key to interrupt auto boot", but doesn't respond to anything I send.

It does not respond to PpsFactoryTool, and nmap only finds port 6668

The kernel is booted from 0x80008000, but fatload reads the env file to 0x82008000. With that I've been able to read and change the environment variables.

The ipaddr variable seems unused, but by overwriting boot_normal I've managed to get serial output from the kernel after boot and also change the cmdline (as verified through the serial output).

The kernel echoes serial input, but doesn't seem to otherwise respond. There's no login prompt.

So far I've tried the following env changes:

hack=setenv bootargs ${bootargs} '- ip=30;/mnt/mmc01/initrun.sh)&:::::;date>/tmp/hack;(sleep
boot_normal=env set bootargs ${mtdparts} ${mem} ${memsize} init=/sbin/init; run hack; run read_kernel; bootm ${loadaddr} - ${fdtcontroladdr}

But initrun.sh does not seem to run. I've modified that to only write the hack file, but still nothing.

That said, I don't know why the old one worked. Was the whole ip=30;... some kind of injection to a boot script and an entirely new backdoor will be required for this one? (Edit: I just saw this. Probably the same thing with S80Network then...)

I guess the next step will be to try to extract the flash, and then I guess I'll have to learn Ghidra again...

Pictures: image image image

Boot console output:

U-Boot 2013.10.0-V3.1.28_bchV1.0.00 (Aug 01 2023 - 15:44:53)

DRAM:  64 MiB
efuse_read:0x00000002
8 MiB
sd detect gpio mode:8!
mmc_sd: 0

total partitions: 6
In:    serial
Out:   serial
Err:   serial
enable watchdog

Hit any key to stop autoboot:  2 
..... 1 
..... 0 
mmc power off ...
sys: size:0x00300000, offset:0x00040000

SF: 3145728 bytes @ 0x40000 Read: OK
## Booting kernel from Legacy Image at 80008000 ...
   Image Name:   Linux-4.4.192V2.1
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2661184 Bytes = 2.5 MiB
   Load Address: 80008000
   Entry Point:  80008040
   Verifying Checksum ... OK
   XIP Kernel Image ... OK
   kernel loaded at 0x80008000, end = 0x80291b40
using: FDT

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

A few extra lines if booted with reset held and ppsMmcTool present:

enable watchdog
reset key pressed!
cmd:fatload mmc 0 0x82008000 ppsMmcTool.txt
mmc/sd share pin!
reading ppsMmcTool.txt
111 bytes read in 0 ms
cmdBuf:fatload mmc 0 0x82008000 env;env import 82008000;saveenv;printenv
reading env
269 bytes read in 0 ms
## Warning: defaulting to text format
## Info: input data size = 268 = 0x10C
Writing to SPI flash...
total partitions: 6
< PRINTENV REMOVED, SEE BELOW>
size:269
error: Pack header size error!
error: upgrade.bin unpack error!

Original printenv:

a_uboot_flags=0x1
baudrate=115200
boot_normal=env set bootargs console=${console}  ${mtdparts} ${mem} ${memsize}; run read_kernel; bootm ${loadaddr} - ${fdtcontroladdr}
bootargs=console=${console}  root=/dev/mtdblock5 rootfstype=squashfs init=/sbin/init
bootargs_mode=0x0
bootcmd=run boot_normal
console=/dev/null
dtb_addr=0x0
dtb_name=DTB
dtb_offset=0x0
dtb_size=0x0
env_name=ENV
env_platform=anycloud_h3b_nor_v330
env_version=1.0.01
envup_flags=1
ethaddr=00:55:7b:b5:7d:f7
fdt_high=0xFFFFFFFF
fdtcontroladdr=0x81300000
filesize=f6
image_name=uImage
init=/sbin/init
kernel_addr=0x0
kernel_name=sys
kernel_offset=0x40000
kernel_size=0x300000
loadaddr=0x80008000
logo_switch=0x0
mem=mem=64M
memsize=memsize=64M
mtd_root=/dev/mtdblock4
mtdparts=mtdparts=spi0.0:256K@0x0(BOOT),3072K@0x40000(sys),4288K@0x340000(app),448K@0x770000(cfg),64K@0x7E0000(enc),64K@0x7F0000(sysflg)
netmask=255.255.255.0
part_table_offset=0x0
parttab_type=AK
read_dtb=sf probe 0; sf read ${fdtcontroladdr} ${dtb_offset} ${dtb_size};fdt addr ${fdtcontroladdr}
read_kernel=sf probe 0; sf read ${loadaddr} ${kernel_offset} ${kernel_size}
root_name=ROOTFS
rootfstype=squashfs
sd_det_mode=0x0
serverip=192.168.1.1
setcmd=setenv bootargs console=${console} root=${mtd_root} rootfstype=${rootfstype} init=${init} mem=${memsize}
setgpio=0
sf_hz=10000000
stderr=serial
stdin=serial
stdout=serial
uboot_name=BOOT
update=tftp $(loadaddr) $(image_name); sf probe ; sf update $(loadaddr) $(update_offset) $(filesize)
update_flag=0x0
update_offset=0x0
update_size=0x0
ver=U-Boot 2013.10.0-V3.1.28_bchV1.0.00 (Aug 01 2023 - 15:44:53)
thomasloven commented 1 month ago

Well... I extracted the flash and looked through the startup scripts for anything using /proc/cmdline or /dev/mmc0 and things are looking bleak. The only thing I've managed so far is stop ppsapp from launching at all, by adding noapp to the commandline. But that seems a bit counterproductive.

I've also dug through the executables a bit, and I think that the up.bin that's been mentioned in some other issue is not actually useful. It seems to me that that is a temporary file that's downloaded by ppsapp itself for doing upgrades from the internet. So it probably won't be read unless it's also just been downloaded.

Patching the flash and writing it back using ppsMmcTool and partition hacking does not sound fun, so I think this is where my journey ends. 25$ for a few nights of entertainment and exploration is good enough, I guess.

guino commented 1 week ago

You are correct that the way the hack works is by getting commands to execute using a 'crafted' boot parameter that is parsed by one of the startup scripts. If you can share the firmware you extracted I would gladly take a look to see if I find anything we can use, but it is not always the case we can find a way to root it. Obviously if you're willing to go the hardware programmer route, that is usually possible, but yes, it does require tools and some tinkering with the hardware itself (desoldering/soldering/etc).