Raysharp Firmware

Will dump tonight. So hopefully tomorrow we have something to play around with.
 

Attachments

  • dump_attempt1.jpg
    dump_attempt1.jpg
    1.3 MB · Views: 51
Not much luck last night dumping the flash due to it being soldered on the board and causing shorts. So will de-solder today and then try again.
 
Not much luck last night dumping the flash due to it being soldered on the board and causing shorts. So will de-solder today and then try again.
You can probably avoid all that just by using a test clip in-situ.

If you haven't already done it - here is a split script :
Code:
#!/bin/sh
# This script holds the steps to unpack the flash dump from the raysharp-PowerEdge-R720.
# The offsets will very likely be specific to that version of firmware. There is no attempt to
# use logic to make it universal - it's as much a memory-jogger as anything.
#
# The assumption is the the flash dump follows this partition scheme from the serial console
# Kernel command line: mem=205M console=ttyAMA0,115200 root=/dev/mtdblock2
# rootfstype=squashfs mtdparts=hi_sfc:448K(boot),2560K(kernel),3M(rootfs),5824K(app),4032K(www),384K(para),64K(p2p)
#
# So the partitions are also deduced as follows:
#
#SPI Nor(cs 0) ID: 0xc2 0x20 0x18
#Block:64KB Chip:16MB Name:"MX25L128XX"
#SPI Nor total size: 16MB
#7 cmdlinepart partitions found on MTD device hi_sfc
#7 cmdlinepart partitions found on MTD device hi_sfc
#Creating 7 MTD partitions on "hi_sfc":
#0x000000000000-0x000000070000 : "boot"
#0x000000070000-0x0000002f0000 : "kernel"
#0x0000002f0000-0x0000005f0000 : "rootfs"
#0x0000005f0000-0x000000ba0000 : "app"
#0x000000ba0000-0x000000f90000 : "www"
#0x000000f90000-0x000000ff0000 : "para"
#0x000000ff0000-0x000001000000 : "p2p"
#
#
dd if=FlashDumpRedlineFirmware-D1.BIN of=boot.part bs=1 count=448K
dd if=FlashDumpRedlineFirmware-D1.BIN of=kernel.part bs=1 count=2560K skip=$((0x70000))
dd if=FlashDumpRedlineFirmware-D1.BIN of=rootfs.part bs=1 count=3M skip=$((0x2f0000))
dd if=FlashDumpRedlineFirmware-D1.BIN of=app.part bs=1 count=5824K skip=$((0x5f0000))
dd if=FlashDumpRedlineFirmware-D1.BIN of=www.part bs=1 count=4932K skip=$((0xba0000))
dd if=FlashDumpRedlineFirmware-D1.BIN of=para.part bs=1 count=384K skip=$((0xf90000))
dd if=FlashDumpRedlineFirmware-D1.BIN of=p2p.part bs=1 count=64K skip=$((0xff0000))
#
# The rootfs and app and www partitions are squashfs so can be extracted
[ -d rootfs.part_contents ] && sudo chmod -R 777 rootfs.part_contents/ && rm -rf rootfs.part_contents
sudo unsquashfs -d rootfs.part_contents rootfs.part
[ -d app.part_contents ] && sudo chmod -R 777 app.part_contents/ && rm -rf app.part_contents
sudo unsquashfs -d app.part_contents app.part
[ -d www.part_contents ] && sudo chmod -R 777 www.part_contents/ && rm -rf www.part_contents
sudo unsquashfs -d www.part_contents www.part
#
#
# I'm not sure if this method works correctly - the first time it yielded no results.
# The 'jefferson' tool worked OK.
# sudo modprobe  mtdram total_size=32768
# sudo modprobe  mtdblock
# sudo chmod 777 /dev/mtdblock0
# sudo cat mtd.part > /dev/mtdblock0
# sudo mount -t jffs2 /dev/mtdblock0 ~/tmp
#
#jefferson -d mtd.part_contents mtd.part
# mkfs.jffs2 -o mtd_new.part -d build_from_here
#
#

And attached is the result :
 

Attachments

  • Like
Reactions: VorlonFrog
Thanks @alastairstevenson

I was hoping i could just tap onto the pins. But sometimes due to board design, current is sent to other components like the CPU when the programmer goes to read the chip. This sometimes causes a short. So I had no choice but to remove it from the board. But all good because now i have an adapter installed so i can take the chip in and out as required.

Thanks for the script. I generally use: $> binwalk -e <firmware.bin> and it will auto extract everything.

At this stage I will likely build Linux for the board using: hi35xx/hi35xx-buildroot

Will then take the raysharp_dvr binary found in the firmware binary and try and run that.

Not much use to people who cannot program the flash directly however :thumbdown:

I am quite interested in what library/toolset was used to build the raysharp_dvr binary. Any thoughts?
 
Thanks for the script. I generally use: $> binwalk -e <firmware.bin> and it will auto extract everything.
Agreed, it's a really useful tool, but I treat it as an indicator of content as it does tend to have a lot of false hits.
Quite often, a manual inspection of the firmware shows a 'manifest' header section which can be very useful.

At this stage I will likely build Linux for the board using: hi35xx/hi35xx-buildroot

Will then take the raysharp_dvr binary found in the firmware binary and try and run that.
That's ambitious!
It will be interesting to hear how you get on.
I am quite interested in what library/toolset was used to build the raysharp_dvr binary. Any thoughts?
strings -8 raysharp.dvr yields some useful info :
Code:
compiler: arm-hisiv300-linux-gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_DYNAMIC_ENGINE -DOPENSSL_PIC -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/engines-1.1\""  -mcpu=cortex-a7 -mfloat-abi=softfp -mfpu=neon-vfpv4 -mno-unaligned-access -fno-aggressive-loop-optimizations -g
OpenSSL 1.1.0i-dev  xx XXX xxxx
built on: reproducible build, date unspecified
platform: linux-generic32
OPENSSLDIR: "/usr/local/ssl"
ENGINESDIR: "/usr/local/lib/engines-1.1"

readelf can provide masses of (cryptic) info.
A small fragment :
Code:
Dynamic section at offset 0xc17e90 contains 35 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libpthread.so.0]
 0x00000001 (NEEDED)                     Shared library: [libcrypt.so.0]
 0x00000001 (NEEDED)                     Shared library: [libdevhal.so]
 0x00000001 (NEEDED)                     Shared library: [libfreetype.so]
 0x00000001 (NEEDED)                     Shared library: [librstool.so]
 0x00000001 (NEEDED)                     Shared library: [libdl.so.0]
 0x00000001 (NEEDED)                     Shared library: [librt.so.0]
 0x00000001 (NEEDED)                     Shared library: [libstdc++.so.6]
 0x00000001 (NEEDED)                     Shared library: [libm.so.0]
 0x00000001 (NEEDED)                     Shared library: [libgcc_s.so.1]
 0x00000001 (NEEDED)                     Shared library: [libc.so.0]
 0x00000001 (NEEDED)                     Shared library: [ld-uClibc.so.0]
 0x0000000c (INIT)                       0x17b98
 0x0000000d (FINI)                       0xa4e6f4
 0x00000019 (INIT_ARRAY)                 0xc165e4
 0x0000001b (INIT_ARRAYSZ)               832 (bytes)
 0x0000001a (FINI_ARRAY)                 0xc16924
 0x0000001c (FINI_ARRAYSZ)               12 (bytes)
 0x00000004 (HASH)                       0x8128
 0x00000005 (STRTAB)                     0xf560
 0x00000006 (SYMTAB)                     0xa550
 0x0000000a (STRSZ)                      25660 (bytes)
 0x0000000b (SYMENT)                     16 (bytes)
 0x00000015 (DEBUG)                      0x0
 0x00000003 (PLTGOT)                     0xc27fd0
 0x00000002 (PLTRELSZ)                   5408 (bytes)
 0x00000014 (PLTREL)                     REL
 0x00000017 (JMPREL)                     0x16678
 0x00000011 (REL)                        0x16440
 0x00000012 (RELSZ)                      568 (bytes)
 0x00000013 (RELENT)                     8 (bytes)
 0x6ffffffe (VERNEED)                    0x163a0
 0x6fffffff (VERNEEDNUM)                 2
 0x6ffffff0 (VERSYM)                     0x1599c
 0x00000000 (NULL)                       0x0
 
By the way - and I don't know in what environment it would get used - one of the root passwords, the one in /etc/passwd (which is generally not used)
is :
root:Al19!@:0:0::/root:/bin/sh
 
root:Al19!@:0:0::/root:/bin/sh

Interesting. I ran both the -passwd and passwd DES/DES128 hashes through HashCat and did not yield any results. How did you get the cleartext?

Another approach is to enable telnet/ssh, rebundle the firmware, flash, and then login with root credentials.

If you look at the raysharp_dvr it also has the credentials for the 'ftp:/ftp.rlupdate.ru' firmware update server.
 

Attachments

  • redline-update-ftp-server.png
    redline-update-ftp-server.png
    1.9 KB · Views: 51
Apologies been awol due to trying to repair pads on me board, @garbage-1 would u be able to take a image of the spi chip and area around it so I can make sure I ain’t stripped some capacitors along with the pads

I’ll get back to reversing the firmware structure when I got a working board again
 
  • Like
Reactions: mat200
this looks pretty interesting too me, have to figure how its able to be called now.
 

Attachments

  • Screen Shot 2020-05-26 at 2.42.41 am.png
    Screen Shot 2020-05-26 at 2.42.41 am.png
    63.2 KB · Views: 62
  • Like
Reactions: mat200
this looks pretty interesting too me, have to figure how its able to be called now.
Here you go, probably :
In the initiallisation script /etc/init.d/S21aconfig the telnet daemon is called, in line 15.
But the main app, raysharp.dvr is called after it, in line 120.
So if that killall in raysharp.dvr is executed (I've not checked, it might just be part of preparations for firmware update) then the telnet daemon will be stopped.

So the thing to test out is to place the 'telnetd &' invocation after the raysharp.dvr invocation in the S21aconfig script.
See the S21aconfig below :
Code:
#!/bin/sh
#load the phy module
 # insmod /hitoe/stmmac.ko 
. /etc/profile

echo 4096 > /proc/sys/vm/min_free_kbytes
echo 10 > /proc/sys/vm/dirty_background_ratio
echo 20 > /proc/sys/vm/dirty_ratio
echo 200 > /proc/sys/vm/vfs_cache_pressure
 
echo "rootfs compile user:tuzuguo time:2019-04-28 14:57:50"
ifconfig lo 127.0.0.1
ifconfig eth0 192.168.1.99
#  mount -t nfs -o nolock 192.168.1.63:/home/admin1/work/hi/3531/nfs /home/
telnetd &
  cd /moudle/ko_hi3521a/
insmod extdrv/rs_gpio.ko
./load3521a -i

readkeyid
keyid=$?
if [ $keyid = "1" ];then
    insmod extdrv/keygpio.ko
    echo "The KEY_ID is key_gpio!"
elif [ $keyid = "3" ] || [ $keyid = "4" ];then
    insmod extdrv/keytouch.ko
    echo "The KEY_ID is key_touch!"
elif [ $keyid = "2" ];then
    echo "The KEY_ID is key_serial!"
else
    echo "The KEY_ID is error!"
fi

insmod extdrv/gpioi2c.ko

#insmod extdrv/rtc_ds1339.ko
insmod extdrv/hi_ir.ko
insmod extdrv/hi_wdt.ko
insmod extdrv/hi_rtc.ko
#insmod extdrv/rtc_rx8010.ko
insmod extdrv/74hc165.ko

checkADauthor
ADauthor=$?
if [ $ADauthor = "2" ];then
    insmod extdrv/pr1000_drv.ko
else   
    readkeyboardid
    board_id=$?
      norm
      if [ "$?" = "1" ];then
        insmod extdrv/RSAD_DRV.ko vdec_mode=0 boardid=$board_id
        echo "Set RSAD_DRV NTSC!"
      else
        insmod extdrv/RSAD_DRV.ko vdec_mode=1 boardid=$board_id
        echo "Set RSAD_DRV PAL!"
      fi
fi

readkeyboardid
board=$?
if [ $board = "106" ];then
    insmod extdrv/DriverEs8323.ko
fi     
#checkkey


#ext4 fs check
index=1
for i in a b c d e f g h
do
    disk=/dev/sd$i$index
    if [ -b $disk ]; then
        checke2 $disk
        e2type=$?
        if [ $e2type = "0" ]; then
            echo "e2fsck $disk ..."
            fsck.ext2 -y -v $disk
        else
            echo "$disk not ext, and don't need fsck"
        fi
    else
        echo "$disk not exist"
    fi
done


  mount -t tmpfs -o size=100K tmpfs /var/run
  mount -t tmpfs -o size=100K tmpfs /var/lock
  mount -t tmpfs -o size=100K tmpfs /var/log
  mount -t tmpfs -o size=100K tmpfs /var/tmp
 
  mount -t tmpfs -o size=4K tmpfs /keys
  mount -t tmpfs -o size=64k tmpfs /tmp
  mount -t tmpfs -o size=100K tmpfs /etc/ppp
  mount -t tmpfs -o size=200K tmpfs /P2P
  mount -t tmpfs -o size=10K tmpfs /etc/Wireless/RT2870STA
  mount -t tmpfs -o size=64k tmpfs /usr/share/udhcpc
 
  mount -t squashfs /dev/mtdblock5 /agent
  mount -t squashfs /dev/mtdblock3 /mnt
  cp /ppp/* /etc/ppp -rf
  cp /usr/udhcpc/* /usr/share/udhcpc -rf
rsSystemServer &

cp /root/passwd /etc/ppp/passwd
cp /root/passwd- /etc/ppp/passwd-
cp /etc/Wireless/MT7601USTA.dat /etc/Wireless/RT2870STA/
cp /etc/Wireless/RT2870STA.dat /etc/Wireless/RT2870STA/
    
SerialSwitch
if [ "$?" = "1" ];then
    echo "open Serial!"   
else
    himm 0x12080030 0xd01
    echo "close Serial!"   
fi   
himm 0x120f00c4 0x02   
cd /mnt
./raysharp_dvr &
mount -t squashfs /dev/mtdblock4 /plugs
boa &
 
I think it refers to “EnableSerial=0” in app/custom-config.ini So looks like repackaging firmware is still the way forward with that enabled

I’ve also rebuilt the u-boot bootloader from the hi3521 sdk that has the u-boot env enabled instead of locked

mostly built a shell script todo this all automatically so will share once done
 
  • Like
Reactions: alastairstevenson
the hisilicon sdks are actually pretty decently packaged, usually you have to fight missing files that don’t get released due to being proprietary like the technicolor modems GPL releases :banghead:

Its pretty straight forward

Ubuntu14.04, install build-essentials with apt and follow the provided read me steps
 
Yet again digging up a topic, apologies. How did you manage to find those alternate model names/codes.
Alternate DVR8-4575 Codes

Code:
DM-274
DM-284
DM-298
DM-299
DM-307
DM-319
DM-321
DM-327
DM-358
DM-359
DVR16-4575
DVR16-4780
DVR4-1590
DVR4-1600
DVR4-4480
DVR4-4575
DVR4-4780
DVR8-1590
DVR8-1600
DVR8-4480
DVR8-4575
DVR8-4780
RS-DM-284
RS-DM-299
RS-DM-307
I've just thrown up a post asking for help with a few things (DVR4-1580/DVR4-720P/DVR-6904AU) and this is one part I need help with, see here.