Dahua IPC EASY unbricking / recovery over TFTP

usaf_pride

Pulling my weight
Joined
Mar 10, 2017
Messages
284
Reaction score
170
First off, this 5231 camera always seemed a bit odd, but it was working, so I put up with some weird reboots along the way. I decided to UG the firmware to get the day/night functionality and the UG seemed to go ok, but it would run for 5 minutes and then reboot. I then attempted to downgrade the firmware back to the original and of course at 99% it reboots and went into a boot loop. I got the TFTP working and was able to get the November 2017 firmware on board and it was working. Not one to leave well enough alone, I thought I would go back to the September firmware that was originally on the camera and of course, boot loop. No worries (so I thought) I'll just go back to the November firmware that was working. Same result for that firmware or any other firmware that I try to install.

My command.txt has (removed the pd-x.squashfs.img as it would timeout)
Code:
run dr
run dk
run du
run dw
run dp
run dc
tftp 0x82000000 .FLASHING_DONE_STOP_TFTP_NOW
sleep 5
The TFTP server reports success:
Code:
Listening On: 192.168.254.254:69
Client 192.168.1.108:2655 root\upgrade_info_7db780a713a4.txt, 1 Blocks Served
Client 192.168.1.108:2815 root\romfs-x.squashfs.img, 910 Blocks Served
Client 192.168.1.108:3735 root\kernel.img, 1070 Blocks Served
Client 192.168.1.108:1446 root\user-x.squashfs.img, 10517 Blocks Served
Client 192.168.1.108:3000 root\web-x.squashfs.img, 4448 Blocks Served
Client 192.168.1.108:3274 root\partition-x.cramfs.img, 6 Blocks Served
Client 192.168.1.108:1364 root\custom-x.squashfs.img, 31 Blocks Served
Client 192.168.1.108:2191 root\.FLASHING_DONE_STOP_TFTP_NOW, 1 Blocks Served
and the console has this at the end (all img's appear to download and write 100%)
Code:
partition file version 2
rootfstype squashfs root /dev/mtdblock5
fail to load bootargsParameters.txt
fail to load bootargsParameters.txt file
cmdLine console=ttyS0,115200 mem=118M root=/dev/mtdblock5 rootfstype=squashfs init=/linuxrc
Is it the bootargsParamaters.txt that is causing this or some other issue? My other 3 cameras took the update successfully with no issues. Like I said, this was a weird camera to start with.
 

riogrande75

Pulling my weight
Joined
Oct 19, 2017
Messages
390
Reaction score
140
Location
AUSTRIA
I just upgraded my my VTO2000A via dahua toolbox (VDPconfig) to actual SIP firmware 20180105 (signed now!).
Obviously this upgraded my boot loader to "1.46t(DM365)18:30:31 Jan 5 2018".
Since that, I do not get any useful output on UART anymore (just lots of "àààààààà" with 115kBaud, tried other rates unsuccessful as well) and TFTP upgrade does not work either.:angry:
Instead of requesting the "upgrade_info..." it requests a file called "failed.txt" only. Pressing doorbell nor sabotage button during boot changes this.
Stepping back to old FW 20170425 does not work, as exptected.

I guess dahua did a lot for keeping people away from the device's software...:wtf:
 
Last edited:

ladler

n3wb
Joined
Jul 25, 2018
Messages
1
Reaction score
0
Location
Graz
TFT Server cant find the file.

default timeout: 60
file read allowed: Yes
file create allowed: No
file overwrite allowed: No
thread pool size: 1

Why is create and overwrite :No????

thanks for help

ng from Austria

Ladler
 
Joined
Jul 26, 2018
Messages
6
Reaction score
1
Location
FRANCE - EURE ET LOIR
I just upgraded my my VTO2000A via dahua toolbox (VDPconfig) to actual SIP firmware 20180105 (signed now!).
Obviously this upgraded my boot loader to "1.46t(DM365)18:30:31 Jan 5 2018".
Since that, I do not get any useful output on UART anymore (just lots of "àààààààà" with 115kBaud, tried other rates unsuccessful as well) and TFTP upgrade does not work either.:angry:
Instead of requesting the "upgrade_info..." it requests a file called "failed.txt" only. Pressing doorbell nor sabotage button during boot changes this.
Stepping back to old FW 20170425 does not work, as exptected.

I guess dahua did a lot for keeping people away from the device's software...:wtf:
Hi,

Is there a way to verify if the firmware upgrade file contain the new boot loader "1.46t(DM365)18:30:31 Jan 5 2018" BEFORE FLASHING IT (maybe with Dahua-Firmware-Mod-Kit extraction and search for a string) ?

A++
 

alastairstevenson

Staff member
Joined
Oct 28, 2014
Messages
15,930
Reaction score
6,778
Location
Scotland
If the firmware is structured in the usual Dahua way, the .bin firmware files are just ZIP files with the first 2 bytes set to DH.
Change the DH to PK and unzip the file and you can see all the components within.
 
Joined
Jul 26, 2018
Messages
6
Reaction score
1
Location
FRANCE - EURE ET LOIR
If the firmware is structured in the usual Dahua way, the .bin firmware files are just ZIP files with the first 2 bytes set to DH.
Change the DH to PK and unzip the file and you can see all the components within.
Do you have a detailed process on this specific part ?

I mean, here we need to search for « boot loader "1.46t(DM365)18:30:31 Jan 5 2018" » trace of evidence.

So to be clear :

1) We download from Dahua a new firmware « .bin » file.
2) We extract it.
3) We search for trace of evidence of the new boot loader
<- How exactly ???

A++
 

alastairstevenson

Staff member
Joined
Oct 28, 2014
Messages
15,930
Reaction score
6,778
Location
Scotland
Do you have a detailed process on this specific part ?
OK - here you go, a sample transcript :
Code:
alastair@PC-I5 ~/cctv/Dahua/IPC-HDB4431C-AS/DH_IPC-HX5X3X-Rhea_Eng_P_Stream3_V2.460.0000000.16.R.20170904 $ ll
total 24172
drwxr-xr-x 2 alastair alastair     4096 Jul 29 09:10 ./
drwxr-xr-x 6 alastair alastair     4096 Apr 17 13:09 ../
-rw-r--r-- 1 alastair alastair 24739963 Dec 26  2017 DH_IPC-HX5X3X-Rhea_Eng_P_Stream3_V2.460.0000000.16.R.20170904.zip
alastair@PC-I5 ~/cctv/Dahua/IPC-HDB4431C-AS/DH_IPC-HX5X3X-Rhea_Eng_P_Stream3_V2.460.0000000.16.R.20170904 $ unzip *.zip
Archive:  DH_IPC-HX5X3X-Rhea_Eng_P_Stream3_V2.460.0000000.16.R.20170904.zip
  inflating: DH_IPC-HX5X3X-Rhea_Eng_P_Stream3_V2.460.0000000.16.R.20170904.bin
alastair@PC-I5 ~/cctv/Dahua/IPC-HDB4431C-AS/DH_IPC-HX5X3X-Rhea_Eng_P_Stream3_V2.460.0000000.16.R.20170904 $ hd -n 32 *.bin
00000000  44 48 03 04 14 00 00 00  08 00 a2 7e 24 4b e5 06  |DH.........~$K..|
00000010  83 27 02 01 00 00 de 02  00 00 07 00 1c 00 49 6e  |.'............In|
00000020
alastair@PC-I5 ~/cctv/Dahua/IPC-HDB4431C-AS/DH_IPC-HX5X3X-Rhea_Eng_P_Stream3_V2.460.0000000.16.R.20170904 $ file *.bin
DH_IPC-HX5X3X-Rhea_Eng_P_Stream3_V2.460.0000000.16.R.20170904.bin: data
alastair@PC-I5 ~/cctv/Dahua/IPC-HDB4431C-AS/DH_IPC-HX5X3X-Rhea_Eng_P_Stream3_V2.460.0000000.16.R.20170904 $ echo "After the first 2 bytes changed tp PK"
After the first 2 bytes changed to PK
alastair@PC-I5 ~/cctv/Dahua/IPC-HDB4431C-AS/DH_IPC-HX5X3X-Rhea_Eng_P_Stream3_V2.460.0000000.16.R.20170904 $ file *.binDH_IPC-HX5X3X-Rhea_Eng_P_Stream3_V2.460.0000000.16.R.20170904.bin: Zip archive data, at least v2.0 to extract
alastair@PC-I5 ~/cctv/Dahua/IPC-HDB4431C-AS/DH_IPC-HX5X3X-Rhea_Eng_P_Stream3_V2.460.0000000.16.R.20170904 $ unzip *.bin
Archive:  DH_IPC-HX5X3X-Rhea_Eng_P_Stream3_V2.460.0000000.16.R.20170904.bin
  inflating: Install              
  inflating: check.img            
  inflating: dhboot-min.bin.img  
  inflating: dhboot.bin.img      
  inflating: kernel.img          
  inflating: romfs-x.squashfs.img
  inflating: user-x.squashfs.img  
  inflating: web-x.squashfs.img  
  inflating: pd-x.squashfs.img    
  inflating: custom-x.squashfs.img
  inflating: partition-x.cramfs.img
 extracting: sign.img            
alastair@PC-I5 ~/cctv/Dahua/IPC-HDB4431C-AS/DH_IPC-HX5X3X-Rhea_Eng_P_Stream3_V2.460.0000000.16.R.20170904 $ ll
total 72812
drwxr-xr-x 2 alastair alastair     4096 Jul 29 09:14 ./
drwxr-xr-x 6 alastair alastair     4096 Apr 17 13:09 ../
-rw-rw-r-- 1 alastair alastair    35646 Sep  4  2017 check.img
-rw-rw-r-- 1 alastair alastair    45120 Sep  4  2017 custom-x.squashfs.img
-rw-rw-r-- 1 alastair alastair   243776 Sep  4  2017 dhboot.bin.img
-rw-rw-r-- 1 alastair alastair   131136 Sep  4  2017 dhboot-min.bin.img
-rw-r--r-- 1 alastair alastair 24737152 Jul 29 09:13 DH_IPC-HX5X3X-Rhea_Eng_P_Stream3_V2.460.0000000.16.R.20170904.bin
-rw-r--r-- 1 alastair alastair 24739963 Dec 26  2017 DH_IPC-HX5X3X-Rhea_Eng_P_Stream3_V2.460.0000000.16.R.20170904.zip
-rwxrwxr-x 1 alastair alastair      734 Sep  4  2017 Install*
-rw-rw-r-- 1 alastair alastair  1534324 Sep  4  2017 kernel.img
-rw-rw-r-- 1 alastair alastair     8256 Sep  4  2017 partition-x.cramfs.img
-rw-rw-r-- 1 alastair alastair    57408 Sep  4  2017 pd-x.squashfs.img
-rw-rw-r-- 1 alastair alastair  1310784 Sep  4  2017 romfs-x.squashfs.img
-rw-rw-r-- 1 alastair alastair      128 Sep  4  2017 sign.img
-rw-rw-r-- 1 alastair alastair 15224896 Sep  4  2017 user-x.squashfs.img
-rw-rw-r-- 1 alastair alastair  6434880 Sep  4  2017 web-x.squashfs.img
alastair@PC-I5 ~/cctv/Dahua/IPC-HDB4431C-AS/DH_IPC-HX5X3X-Rhea_Eng_P_Stream3_V2.460.0000000.16.R.20170904 $
And you can see a couple of versions of the bootloader were in the firmware package.





The original .bin file :
upload_2018-7-29_9-12-50.png

Then with the first 2 bytes that were DH changed to PK
upload_2018-7-29_9-13-53.png
 
Joined
Jul 26, 2018
Messages
6
Reaction score
1
Location
FRANCE - EURE ET LOIR
Ok alastairstevenso, so, let me expose my side in a very detailed way :

Code:
printf "\n\nExtracting the original firmware package file « General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.zip »\n\n" ; unzip ../Documents20180727220928/General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.zip && printf "\nThe first 2 bytes of « General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.bin » are set to « $(head -c 2 General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.bin) », we need to change it "'!!!'"\n\nOk let's go...\n" ; perl -pe 's/\x{44}\x{48}/\x{50}\x{4B}/g' < General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.bin > General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.zip ; printf "\nSuccessfully transformed :\n\nBinary file : « General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.bin »\n\nTo :\n\nZIP File    : « General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.zip »\n\nDone "'!!!'"\n\nUnziping « General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.zip » file...\n\n" ; mkdir extract ; cd extract ; unzip ../General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.zip ; printf "\nThen, so ??? How I can find the trace of evidence of the new boot loader inside all these new files ???\n\n"


Extracting the original firmware package file « General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.zip »

Archive:  ../Documents20180727220928/General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.zip
  inflating: data-x.cramfs.img      
  inflating: dm365_ubl_boot_16M.bin.img 
  inflating: General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.bin 
  inflating: General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.language.bin 
  inflating: kernel-x.cramfs.img    
  inflating: pd-x.cramfs.img        
  inflating: romfs-x.cramfs.img    
 extracting: safeEnv.img            
 extracting: sign.img              
 extracting: sonia.zip              
  inflating: Upall_VTO2000A-2.20180211.bin 
  inflating: update.img            
  inflating: user-x.cramfs.img      
 extracting: VideoDaemon.zip        
  inflating: web-x.cramfs.img      

The first 2 bytes of « General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.bin » are set to « DH », we need to change it !!!

Ok let's go...

Successfully transformed :

Binary file : « General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.bin »

To :

ZIP File    : « General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.zip »

Done !!!

Unziping « General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.zip » file...

Archive:  ../General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.zip
  inflating: Install                
  inflating: dm365_ubl_boot_16M.bin.img   bad CRC 0a72a7e9  (should be c0f70b3b)
  inflating: kernel-x.cramfs.img      bad CRC c908bd4c  (should be 92628de0)
  inflating: romfs-x.cramfs.img       bad CRC 4340c189  (should be fba85a83)
  inflating: user-x.cramfs.img        bad CRC 60e70826  (should be a17b0417)
  inflating: web-x.cramfs.img         bad CRC 07365fd5  (should be 78578505)
  inflating: data-x.cramfs.img        bad CRC 7f7e9ac6  (should be 826c40b4)
  inflating: pd-x.cramfs.img        
 extracting: sign.img              

Then, so ??? How I can find the trace of evidence of the new boot loader inside all these new files ???

bigbob@bigbob-UX31A:~/Documents/Maison/Dahua/Vrac/extract$
 
Last edited:
Joined
Jul 26, 2018
Messages
6
Reaction score
1
Location
FRANCE - EURE ET LOIR
Ok alastairstevenso, so, let me expose my side in a very detailed way :

Code:
printf "\n\nExtracting the original firmware package file « General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.zip »\n\n" ; unzip ../Documents20180727220928/General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.zip && printf "\nThe first 2 bytes of « General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.bin » are set to « $(head -c 2 General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.bin) », we need to change it "'!!!'"\n\nOk let's go...\n" ; perl -pe 's/\x{44}\x{48}/\x{50}\x{4B}/g' < General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.bin > General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.zip ; printf "\nSuccessfully transformed :\n\nBinary file : « General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.bin »\n\nTo :\n\nZIP File    : « General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.zip »\n\nDone "'!!!'"\n\nUnziping « General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.zip » file...\n\n" ; mkdir extract ; cd extract ; unzip ../General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.zip ; printf "\nThen, so ??? How I can find the trace of evidence of the new boot loader inside all these new files ???\n\n"


Extracting the original firmware package file « General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.zip »

Archive:  ../Documents20180727220928/General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.zip
  inflating: data-x.cramfs.img    
  inflating: dm365_ubl_boot_16M.bin.img
  inflating: General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.bin
  inflating: General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.language.bin
  inflating: kernel-x.cramfs.img  
  inflating: pd-x.cramfs.img      
  inflating: romfs-x.cramfs.img  
 extracting: safeEnv.img          
 extracting: sign.img            
 extracting: sonia.zip            
  inflating: Upall_VTO2000A-2.20180211.bin
  inflating: update.img          
  inflating: user-x.cramfs.img    
 extracting: VideoDaemon.zip      
  inflating: web-x.cramfs.img    

The first 2 bytes of « General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.bin » are set to « DH », we need to change it !!!

Ok let's go...

Successfully transformed :

Binary file : « General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.bin »

To :

ZIP File    : « General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.zip »

Done !!!

Unziping « General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.zip » file...

Archive:  ../General_VTO2000A-2_EngHgrBulSvnPolFinCzhSvk_P_16M_V3.120.1026000.0.R.20180211.zip
  inflating: Install              
  inflating: dm365_ubl_boot_16M.bin.img   bad CRC 0a72a7e9  (should be c0f70b3b)
  inflating: kernel-x.cramfs.img      bad CRC c908bd4c  (should be 92628de0)
  inflating: romfs-x.cramfs.img       bad CRC 4340c189  (should be fba85a83)
  inflating: user-x.cramfs.img        bad CRC 60e70826  (should be a17b0417)
  inflating: web-x.cramfs.img         bad CRC 07365fd5  (should be 78578505)
  inflating: data-x.cramfs.img        bad CRC 7f7e9ac6  (should be 826c40b4)
  inflating: pd-x.cramfs.img      
 extracting: sign.img            

Then, so ??? How I can find the trace of evidence of the new boot loader inside all these new files ???

bigbob@bigbob-UX31A:~/Documents/Maison/Dahua/Vrac/extract$
Damn !!! I'm a faggot !!!

Code:
bigbob@bigbob-UX31A:~/Documents/Maison/Dahua/Vrac/extract$ ll
total 13108
-rw-r--r-- 1 bigbob bigbob 1912540 2018-02-11 04:39:33.000000000 +0100 kernel-x.cramfs.img
-rw-r--r-- 1 bigbob bigbob  258860 2018-02-11 04:39:33.000000000 +0100 dm365_ubl_boot_16M.bin.img <- BINGO !!!
-rw-r--r-- 1 bigbob bigbob 2981951 2018-02-11 04:39:34.000000000 +0100 romfs-x.cramfs.img
-rw-r--r-- 1 bigbob bigbob  639040 2018-02-11 04:39:34.000000000 +0100 data-x.cramfs.img
-rw-r--r-- 1 bigbob bigbob 1503296 2018-02-11 04:39:35.000000000 +0100 web-x.cramfs.img
-rw-r--r-- 1 bigbob bigbob 6041664 2018-02-11 04:39:42.000000000 +0100 user-x.cramfs.img
-rw-r--r-- 1 bigbob bigbob     128 2018-02-11 04:39:42.000000000 +0100 sign.img <- BINGO !!!
-rw-r--r-- 1 bigbob bigbob   45120 2018-02-11 04:39:42.000000000 +0100 pd-x.cramfs.img
-rwxr-xr-x 1 bigbob bigbob     451 2018-02-11 04:39:42.000000000 +0100 Install
drwxr-xr-x 3 bigbob bigbob    4096 2018-07-29 11:41:24.341486620 +0200 ..
drwxr-xr-x 2 bigbob bigbob    4096 2018-07-29 11:41:24.461490193 +0200 .
bigbob@bigbob-UX31A:~/Documents/Maison/Dahua/Vrac/extract$ strings dm365_ubl_boot_16M.bin.img | grep DM365
1.46t(DM365)11:07:41 Jul 24 2017
bigbob@bigbob-UX31A:~/Documents/Maison/Dahua/Vrac/extract$
 
Joined
Jul 26, 2018
Messages
6
Reaction score
1
Location
FRANCE - EURE ET LOIR
You could try it with the TFTP method that should still work fine in the old bootloader.
If I try it with the TFTP method from the old boot loader (my actual version since I am running « 493724_General_Multi3_VTO2000A-2_Eng_P_16M_V3.100.0000.0.R.20170401 »), does it mean TFTP method doesn't update the boot loader, or does it mean I need to change something before upgrading ?
 

alastairstevenson

Staff member
Joined
Oct 28, 2014
Messages
15,930
Reaction score
6,778
Location
Scotland
Is there a way to flash firmware without overlapping the boot loader with the new one ?
With serial console access, selective use of the various 'ru xx' commands available?

Or, and this is not something I have tried, suitable similar contents in the commands.txt file using the tftp update method?
 

riogrande75

Pulling my weight
Joined
Oct 19, 2017
Messages
390
Reaction score
140
Location
AUSTRIA
Check the "upgrade_..." file on the tftp server and edit it accordingly to NOT upgrade the bootloader. I guess it's pretty easy to understand if you open the file.

Gesendet von meinem SM-G930F mit Tapatalk
 

Comboy007

n3wb
Joined
Jul 28, 2018
Messages
2
Reaction score
0
Location
Nederland
I have a bricked VTO 2000A-C, it happened when I changed the brightness setting in the video menu with config tool.
I never thought this would happen, however, with putty I can see several processes being executed.
Only port 22 is still working;
I think that a change to the firmware default status could do the trick but I do not know how to accomplish that, can anyone help me?
 
Joined
Feb 19, 2017
Messages
10
Reaction score
0
I have TFTP running and verified it is working from another pc. When I plug the camera in, I can see the file request from 192.168.1.108 on wireshark but the server doesn't echo any activity. The camera spins a few times and then stops and the led stays red. Any suggestions would be greatly appreciated.
 

riogrande75

Pulling my weight
Joined
Oct 19, 2017
Messages
390
Reaction score
140
Location
AUSTRIA
It seems to be a network issue. I had a similar behaviour when using a network hub - changed that to a old 10/100 MBit autoneg switch and now tftp is working fine.
 

riogrande75

Pulling my weight
Joined
Oct 19, 2017
Messages
390
Reaction score
140
Location
AUSTRIA
In the meantime I installed latest SIP FW from 20180627 - off course signed again. It comes along with UBL bootloader from "Aug 4 2017" and UBOOT from "May 23 2018".
Flashing with TFTP is still possible (I guess this feature remains forever), but as soon as you install a modified part (e.g. data-x.cramfs.img) the signiture validation in the software fails and the device keeps on rebooting.
At least I was able to flash good old 20170425 SIP firmware (not signed) via TFTP method to recover the device.
 
Joined
Feb 19, 2017
Messages
10
Reaction score
0
In the meantime I installed latest SIP FW from 20180627 - off course signed again. It comes along with UBL bootloader from "Aug 4 2017" and UBOOT from "May 23 2018".
Flashing with TFTP is still possible (I guess this feature remains forever), but as soon as you install a modified part (e.g. data-x.cramfs.img) the signiture validation in the software fails and the device keeps on rebooting.
At least I was able to flash good old 20170425 SIP firmware (not signed) via TFTP method to recover the device.
It seems to be a network issue. I had a similar behaviour when using a network hub - changed that to a old 10/100 MBit autoneg switch and now tftp is working fine.
Thank you. I will dig into the old hardware box.

I also ordered a cp2101 to see if I can fix it via serial.
 

riogrande75

Pulling my weight
Joined
Oct 19, 2017
Messages
390
Reaction score
140
Location
AUSTRIA
You don't really need a CP2101 to recover the device as long as u follow the tutorial step by step.
Indeed UART helps to follow the bootloader doing things but if you are experienced with wireshark, you should see TFTP downloads working or at least, where the problem seems to be.
 
Top