New cam Speed-17F - Githubissues

Hi guino, I have a new cam which responds to the ppsFactoryTool.txt I have soldered uart, here is what happens on start:

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

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 274 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 ...

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=115201128

I 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

@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:

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:   cd pin not insert, not init mmc

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

mmc power off ...
the id code = 852000
unsupport ID is if the id not be 0x00,the flash is ok for burner
SF: Detected PY25Q128HA, flash size: 16MB, manufacturer id: 85

--->probe spend 14 ms
SF: 2621440 bytes @ 0x40000 Read: OK
--->read spend 842 ms
ERROR: can't get kernel image!
watchdog close!
set debug mode ...
SF: Detected PY25Q128HA, flash size: 16MB, manufacturer id: 85

Erasing SPI flash...Writing to SPI flash...done
Device feature code: 
AgAAAAEAAAAwMTEyOAAAAA8PpaUAAAAA
input key >>

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. Do you think it makes sense to continue searching the rx line? Did you face a similar thing with some other board? Here is one pic of the uart pads: uart

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:

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
206016        0x324C0         AES S-Box
206272        0x325C0         AES Inverse S-Box
210760        0x33748         CRC32 polynomial table, little endian
224268        0x36C0C         Android bootimg, kernel size: 0 bytes, kernel addr: 0x70657250, ramdisk size: 543519329 bytes, ramdisk addr: 0x6E72656B, product name: "ution! Your devices Erase group is 0x%x"
234968        0x395D8         Base64 standard index table
869436        0xD443C         MySQL MISAM index file Version 9
2883584       0x2C0000        Squashfs filesystem, little endian, version 4.0, compression:xz, size: 6146446 bytes, 87 inodes, blocksize: 131072 bytes, created: 2023-09-06 08:03:00
15990784      0xF40000        JFFS2 filesystem, little endian
16160284      0xF6961C        Zlib compressed data, compressed
16160884      0xF69874        Zlib compressed data, compressed
16162456      0xF69E98        Zlib compressed data, compressed
16162756      0xF69FC4        Zlib compressed data, compressed
16163056      0xF6A0F0        Zlib compressed data, compressed
16163368      0xF6A228        Zlib compressed data, compressed
16163680      0xF6A360        Zlib compressed data, compressed
16164008      0xF6A4A8        Zlib compressed data, compressed
16164336      0xF6A5F0        Zlib compressed data, compressed
16164668      0xF6A73C        Zlib compressed data, compressed
16164932      0xF6A844        JFFS2 filesystem, little endian
16165328      0xF6A9D0        JFFS2 filesystem, little endian
16165596      0xF6AADC        Zlib compressed data, compressed
16165936      0xF6AC30        Zlib compressed data, compressed
16166276      0xF6AD84        Zlib compressed data, compressed
16166624      0xF6AEE0        Zlib compressed data, compressed
16166972      0xF6B03C        Zlib compressed data, compressed
16167336      0xF6B1A8        Zlib compressed data, compressed
16167700      0xF6B314        Zlib compressed data, compressed
16168076      0xF6B48C        Zlib compressed data, compressed
16168452      0xF6B604        Zlib compressed data, compressed
16168836      0xF6B784        Zlib compressed data, compressed
16169220      0xF6B904        Zlib compressed data, compressed
16169608      0xF6BA88        Zlib compressed data, compressed
16169996      0xF6BC0C        Zlib compressed data, compressed
16170388      0xF6BD94        Zlib compressed data, compressed
16170780      0xF6BF1C        Zlib compressed data, compressed
16171180      0xF6C0AC        Zlib compressed data, compressed
16171580      0xF6C23C        Zlib compressed data, compressed
16171984      0xF6C3D0        Zlib compressed data, compressed
16172388      0xF6C564        Zlib compressed data, compressed
16172828      0xF6C71C        Zlib compressed data, compressed
16175056      0xF6CFD0        JFFS2 filesystem, little endian
16176636      0xF6D5FC        JFFS2 filesystem, little endian
16176972      0xF6D74C        JFFS2 filesystem, little endian
16321444      0xF90BA4        Zlib compressed data, compressed
16321836      0xF90D2C        Zlib compressed data, compressed
16325128      0xF91A08        Zlib compressed data, compressed
16325624      0xF91BF8        Zlib compressed data, compressed
16328920      0xF928D8        Zlib compressed data, compressed
16329520      0xF92B30        Zlib compressed data, compressed
16330040      0xF92D38        Zlib compressed data, compressed
16330116      0xF92D84        JFFS2 filesystem, little endian
16334984      0xF94088        Zlib compressed data, compressed
16335324      0xF941DC        Zlib compressed data, compressed
16335596      0xF942EC        JFFS2 filesystem, little endian
16335876      0xF94404        Zlib compressed data, compressed
16336132      0xF94504        JFFS2 filesystem, little endian
16338924      0xF94FEC        JFFS2 filesystem, little endian
16339168      0xF950E0        Zlib compressed data, compressed
16339424      0xF951E0        JFFS2 filesystem, little endian
16339772      0xF9533C        Zlib compressed data, compressed
16340164      0xF954C4        Zlib compressed data, compressed
16340420      0xF955C4        JFFS2 filesystem, little endian
16418328      0xFA8618        Zlib compressed data, compressed
16421028      0xFA90A4        Zlib compressed data, compressed
16425860      0xFAA384        JFFS2 filesystem, little endian
16556924      0xFCA37C        Zlib compressed data, compressed
16580808      0xFD00C8        Zlib compressed data, compressed
16581372      0xFD02FC        JFFS2 filesystem, little endian
16583508      0xFD0B54        Zlib compressed data, compressed
16584296      0xFD0E68        Zlib compressed data, compressed
16584640      0xFD0FC0        JFFS2 filesystem, little endian
16584928      0xFD10E0        Zlib compressed data, compressed
16585380      0xFD12A4        JFFS2 filesystem, little endian

I uncomplessed the squashfs filesystem and git a directory structure like this:

squashfs-root# ls -R
.:
app  initrun.sh

./app:
appfiles  binfiles  configfiles  init  iqfiles  kofiles  libfiles

./app/appfiles:
app  etc  sound

./app/appfiles/app:
libpps_product_test.so  ppsapp  ppstool  yolov5s-common-4bit.bin

./app/appfiles/etc:
ifplugd.action  udhcpc.script  udhcpd.conf  webrtc_profile.ini  wpa_supplicant.conf

./app/appfiles/sound:
dingdong.g711u  login.g711u  restart.g711u  warning.pcm

./app/binfiles:
bin

./app/binfiles/bin:
cfg_erase  cmd_router  connect_wifi  crda  iwconfig  lookup_proc  netctrl  ppsconfig  pps_dlink  wpa_cli  wpa_supplicant

./app/configfiles:
config  etc

./app/configfiles/config:
arenti_1920x1080.bmp  arenti_2304x1296.bmp  arenti_640x360.bmp

./app/configfiles/etc:
mdev.conf  pps  set_rate_power.txt

./app/configfiles/etc/pps:
media.mconf

./app/init:
rcS  S00load_ko  S20cmd_router  S27wpa_supplicant  S60ppsapp

./app/iqfiles:
iqfile

./app/iqfiles/iqfile:
gc4023-t41.bin  gc5603-t41.bin  mis4001-t41.bin  sc531ai-t41.bin  sc5338-t41.bin

./app/kofiles:
ko

./app/kofiles/ko:
8188fu.ko  8733bu.ko         audio.ko  mpsys.ko              sensor_gc5603_t41.ko   sensor_sc531ai_t41.ko  sinfo.ko    strnio.ko
8192fu.ko  atbm603x_HT20.ko  avpu.ko   sensor_gc4023_t41.ko  sensor_mis4001_t41.ko  sensor_sc5338_t41.ko   soc-nna.ko  tx-isp-t41.ko

./app/libfiles:
lib

./app/libfiles/lib:
crda  libaip.so  libaudioProcess.so  libdrivers.so  libnl-3.so.200  libnl-genl-3.so.200  libppsmedia_barcode.so  libppsnn.so  libreg.so  libvenus.so

./app/libfiles/lib/crda:
regulatory.bin

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) for the boot partition binwalk at least seems to find something, if I run strings, I see some strings that are from uboot, like bootcmd

$ binwalk mtd0_BOOT.bin 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
206016        0x324C0         AES S-Box
206272        0x325C0         AES Inverse S-Box
210760        0x33748         CRC32 polynomial table, little endian
224268        0x36C0C         Android bootimg, kernel size: 0 bytes, kernel addr: 0x70657250, ramdisk size: 543519329 bytes, ramdisk addr: 0x6E72656B, product name: "ution! Your devices Erase group is 0x%x"
234968        0x395D8         Base64 standard index table

this is the result when I scan for boot:

$ strings mtd0_BOOT.bin | grep boot
*** Warning: no boot file name; using '%s'
mtd_recove_boot
pps_boot_paras_read
Reserving %dk for boot params() at: %08lx
bootargs
Automatic boot of image at addr 0x%08lX ...
bootm 0x%lx
mmcboot
'bootd' recursion detected
bootargs=console=/dev/null mem=40M@0x0 rmem=20M@0x2800000 nmem=4M@0x3C00000
bootcmd=sf0 probe;sf0 read 0x80600000 0x40000 0x280000;bootm 0x80600000
bootdelay=2
mem boot start
mem boot error
Nand boot start
Nand boot error
%s boot unsupport
bootcmd
ERROR: booting os '%s' (%d) is not supported
change bootargs .... 
bootfile
** No boot file defined **
bootdevice
bootdelay
bootdelaykey
bootdelaykey2
bootstopkey
bootstopkey2
Enter mem_boot routine ...
.callbacks:callbacks,.flags:flags,baudrate:baudrate,bootfile:bootfile,loadaddr:loadaddr,stdin:console,stdout:console,stderr:console,
tftpboot 0x%x %s
boota
boot android system
bootd
boot default, i.e., run 'bootcmd'
bootm
boot application image from memory
update uboot
tftpboot
boot image via network using TFTP protocol
[loadAddress] [[hostIPaddr:]bootfilename]
bootp
boot image via network using BOOTP/TFTP protocol
u-boot
security login uboot
   eg: secboot <keynum>
u-boot.bin
- boot Android system....
        The argument [way] means the way of booting boot.img.[way]='mem'/'mmc'/'nand'.
        The argument [mem_address] means the start position of boot.img in memory.
        The argument [sectors] means the position of boot.img in MMC/NAND.
    - boot application image stored in memory
        passing arguments 'arg ...'; when booting a Linux kernel,
Sub-commands to do part of the bootm sequence.  The sub-commands must be
bootargs=console=/dev/null mem=40M@0x0 rmem=20M@0x2800000 nmem=4M@0x3C00000 init=/linuxrc mtdparts=sfc0_nor:256k(BOOT),2560k(sys),7680k(app),5120k(recove),640k(cfg),64k(enc),64k(sysflg) lpj=11968512 debug_mode=0
bootcmd=sf0 probe;sf0 read 0x80600000 0x40000 0x280000;bootm 0x80600000
bootdelay=2

it seems the sys partition is encrypted somehow and binwalk does not recognize anything correctly:

cam_flash$ binwalk mtd1_sys.bin 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
607292        0x9443C         MySQL MISAM index file Version 9

looking at the boot logs it seams to read and do some 'sb':

SF: 2621440 bytes @ 0x40000 Read: OK
--->read spend 842 ms
--->sb spend 274 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 ...

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:

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

@jacekzubel if you place ppsFactoryTool.txt in the SD card are you able to get the output from http://admin:056565099@192.168.x.x/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:

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 debug_mode=0 pcbversion=S18F_T17_V10 sensor=gc4023fmipi model_name=Speed-17F pro_no=115201128

previously it was: 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=115201128

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:

baudrate=115200
bootargs=console=/dev/null mem=40M@0x0 rmem=20M@0x2800000 nmem=4M@0x3C00000 init=/linuxrc mtdparts=sfc0_nor:256k(BOOT),2560k(sys),7680k(app),5120k(recove),640k(cfg),64k(enc),64k(sysflg) lpj=11968512 debug_mode=0
bootcmd=sf0 probe;sf0 read 0x80600000 0x40000 0x280000;bootm 0x80600000
bootdelay=2
ethact=Jz4775-9161
ethaddr=00:11:22:56:96:69
filesize=83
gatewayip=193.169.4.1
hack=setenv bootargs ${bootargs} '- ip=30;/mnt/mmc01/initrun.sh)&:::::;date>/tmp/hack;(sleep.ipaddr=0;run hack;bootm 0x80600000;
loads_echo=1
netmask=255.255.255.0
serverip=193.169.4.2
stderr=serial.stdin=serial.stdout=serial

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: here is the assembler:

                             LAB_004a348c                                    XREF[1]:     004a3478(j)  
        004a348c 7b 00 05 3c     lui        a1,0x7b
        004a3490 a4 1c a5 24     addiu      a1=>s_onvif_enable_007b1ca4,a1,0x1ca4            = "onvif_enable"
        004a3494 19 98 1e 0c     jal        FUN_007a6064                                     undefined FUN_007a6064()
        004a3498 25 20 00 02     _or        a0,s0,zero
        004a349c 04 00 40 10     beq        v0,zero,LAB_004a34b0
        004a34a0 89 00 03 3c     _lui       v1,0x89
        004a34a4 18 00 40 d4     ldc1       f0,0x18(v0)
        004a34a8 0d 00 20 46     trunc.w.D  f0,f0
        004a34ac 38 2b 60 e4     swc1       f0,offset DAT_00892b38(v1)

and the decompiled code:

        iVar3 = FUN_007a6064(iVar2,"onvif_enable");
        if (iVar3 != 0) {
          DAT_00892b38 = (int)*(double *)(iVar3 + 0x18);
        }

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 GitHubhttps://github.com/guino/Merkury1080P/issues/53#issuecomment-1939559612, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABF3MEQGLZ77P4UF6TPOGSLYTJ6ZNAVCNFSM6AAAAABCF4UPVOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZZGU2TSNRRGI. You are receiving this because you were mentioned.

guino / Merkury1080P

New cam Speed-17F #53

Warning: defaulting to text format

Info: input data size = 130 = 0x82