New cam Speed-17F #53
Comments
|
@jacekzubel Are you able at all to interrupt the boot by pressing a key in the UART terminal during boot ? on older devices they used to show a count down something like 'Press any key to interrupt boot...' or something similar. From the output provided above this looks like a whole new board, with 16Mb flash (most we've modded are 8Mb) and newer kernel (4.4) + new boot loader (Uboot) dated of last year. It's almost certain the u-boot scripts have changed so the changes we had for old cameras will likely have no effect on the new one. If you can get into the bootloader from the UART (interrupting the boot by pressing a key) let me know and we can try some stuff. If the boot can't be interrupted (which is an option they have when compiling it), then the only way to move forward would be to removing the chip to get a flash dump. |
|
@guino Thanks for the insights. No, there is no way to interrupt the boot, no prompt is coming, and I am not sure if the rx line is cut off, so no interrupt could be done. On other devices it worked up to now. Somewhere I have read you can trick uboot to stop if it cannot read the kernel from flash, it would then stop with a prompt. For this I would need to interrupt the flash read by shorting it or something. I'll get the datasheet and try it. If this won't work I'll try to remove the flash chip and try to dump the image. It will take some time, but I'll update here if I get some more details. I hope I won't break the cam in the process :-) |
|
@guino I came a little bit further, I now can get the uboot to stop with the following: but it seems it does not accept any keyboard input through uart. Below the uart pads there are some resistors soldered, and one is missing, but I have measured the voltage in the pins, and on rx and tx both voltage is about 3V. If this missing resistor would break the rx circuit, I was thinking it would always be at ground level. |
|
The last few lines of the log about erasing/writing the SPI flash worry me a bit - I hope you have verified the device still boots normally? In any case I have not seen any device with missing resistors (or Ingenic boards) but have seen bootloaders with the serial input blocked. These devices are all 3.3v so you should always use the correct uart adapter levels to avoid damaging the board. The picture you sent looks like the right place but if they didn’t populate the resistor you could try to solder the resistor pins together and add a resistor to your wiring (of value similar to whatever value of their tx line resistor). You should probably verify that the rx wire you soldered is connected to one of the resistor pins and be warned these boards are very fragile so it’s easy to damage them with a soldering iron. The above still seems easier than removing the flash chip but that also depends on available equipment and it’s still your call in the end. |
|
The cam is still working, even though there was this erasing and writing flash lines. I tried to follow the tracks to check to which contact of the t41 chip it would go. I think I even found it, but there is no datasheet for that chip available. I cannot figure out what function it would have, and I don't want to brick that thing. I ordered ch341a programmer and will first try to read the flash soldered on board. If that won't work I think I'll risk de-soldering it even if it gets bricked, I have a hot air soldering station, but very little experience with that small smd stuff. |
|
It should not be too bad with a hot air station - I would just practice removing and soldering a chip a couple of times on any old/broken board you may have around. |
|
I was able to dump the flash, this is what binwalk returns: I uncomplessed the squashfs filesystem and git a directory structure like this: What can I do next? |
|
I separated the dump into the mtd parts from the start command: mtdparts=sfc0_nor:256k(BOOT),2560k(sys),7680k(app),5120k(recove),640k(cfg),64k(enc),64k(sysflg) this is the result when I scan for boot: it seems the sys partition is encrypted somehow and binwalk does not recognize anything correctly: looking at the boot logs it seams to read and do some 'sb': Do you have any idea hot to find out what the bootloader is doing here? |
|
@jacekzubel The address for your device seems to be 80600000 -- so that's what you'd have to set in env and ppsMmcTool.txt to try and root it. If you post (or email me a copy) of the zipped firmware I can take a look to be sure the required scripts, etc are in the firmware OR look for any other options. My email is in my github profile. |
|
I've sent you the dump by email. I started cam with changed address to 80600000. I think it did not work: but there was no http server on port 80 and I could not access the files as in here: https://github.com/guino/Merkury720 |
|
@jacekzubel if you place ppsFactoryTool.txt in the SD card are you able to get the output from http://admin:[email protected]/proc/cmdline ? I wanted to see if the cmdline changed because the output you provided above suggests the file was loaded and likely applied changes to the bootloader settings but it is possible that the bootloader is just ignoring the new settings. Sorry I haven't had a chance to look at the flash dump yet. |
|
@guino cmdline is as follows:
previously it was: seems like debug_mode=0 was added, so something was modified. |
|
@guino I desoldered the flash again and dumped it. It seems something has been executed. In the flash area where the env variables are is now also a new hack variable: but the bootargs are still almost original, only debug_mode=0 is added. I tried to modify the env in the flash manually and use the mkenvimage tool to create a valid one with the right checksum. after flashing and soldering the flash back the cam seemed to be bricked. No output was generated. I desoldered it and flashed back the last unmodified image and it works now again. I also tried to modify the ppsapp binary that I have found in one of the mtd parts. I have too less knowledge there. I tried to set the onvif_enabled variable to 1 in the two placed where it is set, but I don't know how to set the variable: and the decompiled code: maybe you could give me a hint? |
|
@jacekzubel the problem is likely that your boot loader is ignoring the ipaddr setting used in other devices, I'll have to take a look at your firmware dump to see what/if we can do about it. If we modify ppsapp we'd also have to prepare the new cramfs to flash into the device -- it may take a few tries to get it working. |
|
Hi There,
Sorry for the long delay, I finally found a few minutes to look at the dump file you sent over.
From what I can tell the S80network script that reads the boot settings and allows us to root the device is missing, so the standard rooting will not work.
I looked at the the ppsapp file in ghidra and it seems we can probably patch it to enable RTSP, but right now the only way to root this thing is using a flash programmer (similar to what I originally did in https://github.com/guino/BazzDoorbell ).
I have not had a chance to look at the bootloader but ppsapp seems to suggest it will try to read a 'up.bin' file from the root of the SD card to perform an update – the problem is that it takes considerable time to review the code to figure out the exact file format it expects and if we don't do it right we possibly brick the device.
If you want to try rooting with the flash programmer, what I would do is modify the S60ppsapp file to try and run a script from the SD card after ppsapp mounts it, if that works then we can work on patching ppsapp to enable RTSP.
Thanks,
Wagner.
…________________________________
From: jacekzubel ***@***.***>
Sent: February 12, 2024 3:56 PM
To: guino/Merkury1080P ***@***.***>
Cc: Wagner ***@***.***>; Mention ***@***.***>
Subject: Re: [guino/Merkury1080P] New cam Speed-17F (Issue #53)
I've sent you the dump by email. I started cam with changed address to 80600000. I think it did not work:
U-Boot SPL 2013.07 (May 17 2023 - 19:30:08)
Board info: T41LQ
apll_freq = 1104000000
mpll_freq = 1200000000
vpll_freq = 1080000000
sdram init start
DDR clk rate 600000000
T41LQ ddr phy skew set
board_init_r
image entry point: 0x80100000
Board: ISVP (Ingenic XBurst2 T41 SoC)
Boot: -s
DRAM: DRAM size is 64 MiB
64 MiB
Top of RAM usable for U-Boot at: 84000000
Reserving 481k for U-Boot at: 83f84000
Reserving 32772k for malloc() at: 81f83000
Reserving 32 Bytes for Board Info at: 81f82fe0
Reserving 124 Bytes for Global Data at: 81f82f64
Reserving 128k for boot params() at: 81f62f64
Stack Pointer at: 81f62f48
Now running in RAM - U-Boot at: 83f84000
MMC: MSC: 0
SF: Detected PY25Q128HA, flash size: 16MB, manufacturer id: 85
Data transfer: serial
Net: Jz4775-9161
watchdog open!
SF: Detected PY25Q128HA, flash size: 16MB, manufacturer id: 85
watchdog close!
reset key pressed!
cmd:fatload mmc 0 0x80600000 ppsMmcTool.txt
reading ppsMmcTool.txt
102 bytes read in 11 ms (8.8 KiB/s)
cmdBuf:fatload mmc 0 0x80600000 env;env import 80600000;saveenv
reading env
131 bytes read in 11 ms (10.7 KiB/s)
## Warning: defaulting to text format
## Info: input data size = 130 = 0x82
SF: Detected PY25Q128HA, flash size: 16MB, manufacturer id: 85
Erasing SPI flash...Writing to SPI flash...done
error: Pack header size error!
error: upgrade.bin unpack error!
mmc power off ...
SF: Detected PY25Q128HA, flash size: 16MB, manufacturer id: 85
--->probe spend 6 ms
SF: 2621440 bytes @ 0x40000 Read: OK
--->read spend 842 ms
--->sb spend 276 ms
Image Name: Linux-4.4.94
Image Type: MIPS Linux Kernel Image (lzma compressed)
Data Size: 2565020 Bytes = 2.4 MiB
Load Address: 80010000
Entry Point: 803afaa0
Verifying Checksum ... OK
Uncompressing lzma Kernel Image ... OK
Starting kernel ...
but there was no http server on port 80 and I could not access the files as in here: https://github.com/guino/Merkury720
—
Reply to this email directly, view it on GitHub<#53 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABF3MEQGLZ77P4UF6TPOGSLYTJ6ZNAVCNFSM6AAAAABCF4UPVOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZZGU2TSNRRGI>.
You are receiving this because you were mentioned.
|
Hi guino,
I have a new cam which responds to the ppsFactoryTool.txt
I have soldered uart, here is what happens on start:
this is the response for deviceinfo:
{"devname":"Smart Home Camera","model":"Speed 17F","serialno":"115201128","softwareversion":"5.6.0","hardwareversion":"S17F_T17_V10_GC6","firmwareversion":"ppstrong-c40ba-m_general_8733-5.6.0.20230906","identity":"xxxxxx","licence_id":"xxxxxx","licence_key":"xxxxx","pid":"aaa","WiFi MAC":"xxxxx","ETH MAC":"00:00:00:00:00:00"}and this is coming from cmdline endpoint:
console=/dev/null mem=39084K@0x0 rmem=22356K@0x262b000 nmem=4M@0x3c00000 init=/linuxrc mtdparts=sfc0_nor:256k(BOOT),2560k(sys),7680k(app),5120k(recove),640k(cfg),64k(enc),64k(sysflg) lpj=11968512 pcbversion=S18F_T17_V10 sensor=gc4023fmipi model_name=Speed-17F pro_no=115201128I tried to take the files from the Mercury1080p repo and exchanged the address to 80010000 in ppsMmcTool.txt and env as I have read this somewhere, but it doesn't help. I still cannot save the env.
Can you please assist in getting this cam to run rtsp?
Thanks,
jacek
The text was updated successfully, but these errors were encountered: