I spent the last two weeks getting to know everything about these cameras and this thread will capture all this information. It will take me several weeks to document all the information so please be patient.

There are a variety of problems that I will try my best to explain and share the possible solutions. I have gotten pretty comfortable with these cameras and have purposely bricked them to various degrees of severity just to validate the recovery process. Most people “brick” their cameras trying to upgrade the firmware. This is not a serious issue and it can be corrected very easily. The camera runs an upgrade service on port 3800. The configTool always shows a default port of 37777 but this is not an issue as it can do the upgrade on port 3800 anyway. Change your port to 3800 and use a firmware file lsted below and you are back in business.

I will keep updating this post as I get more time to write all the details around recovery. I will also post links to over 40+ firmware files that and which cameras they will work with. It will take me a bit of time to capture all this information, so please be patient.

 How to Download and Prepare Firmware

This guide will show how to download and prepare the firmware file for a Dahua device.

Firmware files for Dahua devices can be found at Firmware by Device or the specific product page for the device

Firmware is typical provided in a ZIP file, a compressed file format

This file will contain the actual firmware file, which needs to be extracted from the ZIP file in preparation for the upgrade

Prerequisites

Video Instructions

Step by Step Instructions

Confirm the Model and current firmware of Dahua device

1. Enter the IP of the device into a browser

At the Web Login

Enter the Username and Password

Click Login

2. Click Info

3. Click Version

The Device Type will be displayed

The current System Version will be displayed

Download the firmware file for device from DahuaWiki

4. In a browser go to DahuaWiki.com

Under Specifications, Firmware, & Manuals

Click the device type (in this example Recorder)

5. Enter the device model into the field

6. The results will be filtered

7. Click the firmware icon to download the firmware file

8. The file will download

Extract the firmware file to local computer

9. Right click the Start Menu / Windows icon in the bottom left of the screen

Select File Explorer

10. Select Desktop

11. Click Home

Then click New folder to create a new folder to extract the contents of the firmware zip file

12. Find the created folder in the list, double click to open

13. Under the Downloads window of the browser, click ‘Show in folder’

A new File Explorer window should open containing the directory the firmware zip was downloaded to

Locate the file in the list

14. Right click

Select Cut

15. Select the window with the new directory

Right click in the window

Select Paste

The folder will appear in the directory

16. Right click the file

17. The contents of the zip file will appear in a new window

18. Click to select all files in the folder

Drag and drop the files to the created folder

The files will appear in the directory

The firmware file will appear in the directory ready to use

Unbricking your Dahua IP camera (Tips, Tricks & Firmware)

BRICKED CAMERA? How can you tell?

There are several types of “BRICKED” camera conditions and they have varying levels of severity and also varying levels of complexity for recovery. Most are simple and caused by bad firmware uploads. The worst will require a full rebuild of the partitions which load the kernel, software and all other data.

1. The first step in identifying the severity of your issue is to determine what still working on your camera. In order to do that, lets remove as many variables as possible to the troubleshooting process. If possible, connect the camera ethernet and PC ethernet on it’s own switch and make sure that no vlan tagging is enabled on the switch.

Next, you need to figure out if the IP address is still reacheable. Ping the last known ip address. The default address for most cameras is 192.168.1.108.

If you don’t know it you can use the arp/ping method to configure which adds as startic arp entry to a new ip address. (This feature is enabled on the camera by default)

2. Once you have a pingable IP, you need to know what services are still active on the camera. This can be done with a simple port scanner. I have added a link to below in tools.

3. Run the port scanner and record which ports are still open. In many cases port 23 and port 3800 will still be open. If this is your situation, it is a very simple fix. If no ports are open, you will need to do a full image load which is more complex.

The typical ports that you would see are:

23 – Telnet access

80 – Web User interface

443 – SSL

554 – Real time streaming port

3800 – Upgrade Deamon

5000 – UPnP

37777 – TCP Video streaming

37778 – UDP Video Streaming

42323 – Real time remote runner

Plus a whole bunch more of UDP ports and more TCP ports

REPAIR WITH PORT 3800

Download a step by step guide (DAHUA IP Camera Recovery v1.0.pdf) with screen prints @ http://tinyurl.com/lbl3up7

1A. If port 3800 is open you can connect with the Dahua Config tool (link below in tools). I tdefault to port 37777 but change it to 3800 as this port where the upgrade daemon is listening. Port 37777 is a redirect but it won’t work if your firmware has failed.

Launch the config tool and click on login button. Type the IP address , username and password then port 3800.

Open a know working firmware file and upload to the camera.

1B. If port 3800 is not open, go to the next step to enable port 3800.

2. If you have telnet access, you can login with putty. Link to putty below in tools. The default Web UI password is admin / admin.

In older firmware the telnet account is root / vizxv

In newer firmware the telnet account is admin / 7ujMko0+”web UI password” —> 7ujmko0admin

Once connected you can execute a ps command to see running processes. /usr/sbin/upgraded process is what listens on port 3800 for the firmware binary file.

There is also another copy in /var/tmp/

A useful tip for watching the upgrade process is to kill the “upgraded” process that is running and re-launch it in the foreground to watch the upgrade.

~#>ps

625 root 0:00 [mtdblock3]

630 root 0:00 [mtdblock4]

635 root 0:00 [mtdblock5]

772 root 0:00 [ubi_bgt7d]

776 root 0:00 [ubifs_bgt7_0]

790 root 0:00 /sbin/telnetd

798 root 0:00 [OSA_796_1]

860 root 0:00 syshelper elper 60

861 root 0:00 /usr/sbin/upgraded

869 root 0:00 [dsplogd]

870 root 0:00 [encode_guard]

889 root 0:00 [flush-ubifs_6_0]

923 root 3:29 ./VideoDaemon AEWB AF TVOUT

~#> kill -9 861

~#> /usr/sbin/upgraded

22:52:46|[crypt] crypt_open ok!

Name: upgraded, bulid date: Apr 19 2014 09:17:58, svn: 255

Fail to get env authcode!

@@@@ buf = PZC4MU056W00XXX

22:52:52|[pdc] WARN (MISC_ioctl|493): Get SdCard cfg failed !

UPGRADED_MSG: Can’t Open /mnt/mtd/Config/passwd

UPGRADED_MSG: Login success!

UPGRADED_MSG: Kill 976 successful

UPGRADED_MSG: reset_watchdog

UPGRADED_MSG: Receive A4(alarm)

UPGRADED_MSG: reset_watchdog

UPGRADED_MSG: Receive A1(alive package)

UPGRADED_MSG: reset_watchdog

UPGRADED_MSG: Received : 29868252, FileSize : 29868252

UPGRADED_MSG: Download Complete

UPGRADED_MSG: DoDownLoad success!

UPGRADED_MSG: Flash init success

UPGRADED_MSG: hwid file success!

Fail to get env native!

UPGRADED_ERR: LINE: 1074: invalid file: Install.lua

UPGRADED_MSG: zip file total size: 40900220

Fail to get env authcode!

@@@@ buf = PZC4MU056W00XXX

22:53:10|[pdc] WARN (MISC_ioctl|493): Get SdCard cfg failed !

UPGRADED_MSG: packet.name: SD6XXX, board.name: IPC-HFW4300S-V2

UPGRADED_MSG: packet.hardver: , board.hardver:

UPGRADED_MSG: packet.name: IPC-HX3XXX, board.name: IPC-HFW4300S-V2

UPGRADED_MSG: packet.hardver: , board.hardver:

UPGRADED_MSG: Verify version success

Header CRC Checking … OK

Image Name: kernel.img

Image Type: kernel.img (gzip compressed)

Data Size: 2546876 B, Bytes = 2.43 MB

Load Address: 0XC80000

Data CRC Checking … OK

Programing start at: 0XC80000

<5>UBIFS: un-mount UBI device 2, volume 0

<5>UBIFS: un-mount UBI device 4, volume 0

Upgrade : Complete Total 6%…

Header CRC Checking … OK

Image Name: partition-x.cramfs.img

Image Type: partition-x.cramfs.img (gzip compressed)

Data Size: 4160 B, Bytes = 0.00 MB

Load Address: 0X500000

Data CRC Checking … OK

Programing start at: 0X500000

Upgrade : Complete Total 6%…

Header CRC Checking … OK

Image Name: romfs-x.ubifs.img

Image Type: romfs-x.ubifs.img (gzip compressed)

Data Size: 7340096 B, Bytes = 7.00 MB

Load Address: 0X1200000

Data CRC Checking … OK

Programing start at: 0X1200000

Upgrade : Complete Total 24%…

Header CRC Checking … OK

Image Name: pd-x.ubifs.img

Image Type: pd-x.ubifs.img (gzip compressed)

Data Size: 1966144 B, Bytes = 1.88 MB

Load Address: 0X940000

Data CRC Checking … OK

Programing start at: 0X940000

Upgrade : Complete Total 28%…

Header CRC Checking … OK

Image Name: user-x.ubifs.img

Image Type: user-x.ubifs.img (gzip compressed)

Data Size: 21233728 B, Bytes = 20.25 MB

Load Address: 0X2200000

Data CRC Checking … OK

Programing start at: 0X2200000

Upgrade : Complete Total 80%…

Header CRC Checking … OK

Image Name: custom-x.ubifs.img

Image Type: custom-x.ubifs.img (gzip compressed)

Data Size: 1966144 B, Bytes = 1.88 MB

Load Address: 0X600000

Data CRC Checking … OK

Programing start at: 0X600000

Upgrade : Complete Total 85%…

Header CRC Checking … OK

Image Name: web-x.ubifs.img

Image Type: web-x.ubifs.img (gzip compressed)

Data Size: 5505088 B, Bytes = 5.25 MB

Load Address: 0X1A00000

Data CRC Checking … OK

Programing start at: 0X1A00000

Upgrade : Complete Total 99%… [libpdi] Read: blkIndex: 0,pageIndex: 1,byteIndex: 0 ,fLag: ff

Upgrade : Complete Total 100%… UPGRADED_MSG: will reboot system

Here you can see each partition being loaded wit the individual img files. I will write a quick how to on loading each one individually at a later time.

If you chose a valid firmware file, you will be back in working order. If you still have problems, repeat with another firmware file till you have a valid file. The IPC-HFW4300S-V2 is not natively compatible with all other 4300S firmware. I am in the process of writing a how to that explains how to over come this issue.

UNBRICK WITH UBOOT via SERIAL

NOTE: This section is coming soon… I’m gathering all the images I need for various camera types

OTHER USEFUL INFORMATION (to be sorted later)

The firmware consists of several images that are loaded into various partitions in flash in a UBI file system. You can load each partition separately if needed. More on this later…. (I’ll put a guide together on flashing and recovering partitions)

Once you telnet into the camera, there are number of useful binaries in the user shell that can help correct and diagnose some of the problems people are experiencing. One of the helpful steps is to kill the /var/tmp/upgraded process and run it in the foreground so you can see what is going on and easily capture error messaged. The /var/tmp/upgraded process is what opens the port 3800 and allows you to connect to the camera with the config tool if your web services have failed. There is also another copy in usr/sbin/.

Also, in there is a command to reset all the parameters back to factory defaults (username, password, ip address back to 192.168.1.108 etc.) This can be accomplished with /sbin/clearparam.

Another issue that people run into is the constant reboot issue. This can be caused by a failed process. The main application which provides all the camera capabilities (web interface, streaming, etc.) is /usr/bin/sonia. This process is what makes most firmware different from version to version (sort of). There are also changes to the web partition which contains the web server pages that /usr/bin sonia hosts on port 80. The sonia process is invoked by a shell script in init.d and if the process is killed, the camera reboots after a few minutes. This has cause many people issues when trying to “unbrick” the camera since you only have a few minutes between reboots.

To stop the reboots you can update the flash. There is a parameter called appauto that tells the camera to auto start /us/bin/sonia. If you want the camera to start and not invoke the shell script that launches sonia, you need to set appauto to 0. This will stop the camera from rebooting when sonia is not running.

This cam be accomplished by running ‘/sbin/appauto 0’. To turn it back on, just run /sbin/appauto 1. This writes the boot parameter in flash that the kernel reads before starting the process. You can check the current status of the appauto bootparameter with ‘cat /proc/dahua/bootpara’ It will only show what the parameter was when you booted up, so if you changes it you need to reboot to see the change in /proc/dahua/bootpara.

Realtime streaming URL – rtsp://192.168.1.108/cam/realmonitor?channel=1&subtype=0&proto=Onvif

You can change the subtype to 1 for the secondary stream also you can add user:password@ in front of the IP address if you have the permissions set requiring it.

You can use the HTTP API to configure some parameters that are not yet in the web UI. For instance, another member discovered he could enable NFS through the web UI in addition to the local SD card. This config is not possible through the web interface as you need to pick one or the other.

These documents details the API of Dahua video products (links provided to some of the versions below). Programmers or users can access and configure Dahua video products through the API. Every setting of the camera is available through the API whereas only a small number are available through the WEB interface. The document with version 1.10 is available with firmware version 2.0 and above. This document with version 1.20, 1.21, 1.22, 1.23,1.24,1,25,1,26,1,27,1,28 is available with firmware 2.210 and above.This document with version 1. 29 ,1.30, 1.31, 1.32, 1.33, 1.34, 1.35,

1.36 is available with firmware 2.210 and above.This document with version 1.37 is available with firmware 2.212, 2.4 and above.

I have also done a bit of testing around the tftp process that is invoked in u-boot that looks for upgrade_info_7db780a713a4.txt and failed.txt. I think with a little more work, I’ll figure out if there is a recovery method using tftp without serial access. This would be necessary if you lose telnet access and need to rebuild the kernel partition that hosts telnetd.

Tools

DAHUA IP Camera Recovery v1.0.pdf………………….. http://tinyurl.com/lbl3up7

Port Scanner ………………………………………….. http://tinyurl.com/q53pojg

Putty …………………………………………………….. http://tinyurl.com/lvbbmsq

Tftp Server …………………………………………….. http://tinyurl.com/m46wnhe

Dahua Docs & Tools

DAHUA_HTTP_API 1.0 .pdf ………………………………………… http://tinyurl.com/lb43lga

DAHUA_HTTP_API_1.23.pdf ………………………………………… http://tinyurl.com/lrwye3k

DAHUA_HTTP_API_FOR_IPC 1.28.pdf …………………………………. http://tinyurl.com/kskrcay

DAHUA_HTTP_API_FOR_IPC&SD-V1.36.pdf ……………………………… http://tinyurl.com/mooccf9

DAHUA_HTTP_API_FOR_IPC&SD-V1.37.pdf ……………………………… http://tinyurl.com/kvyddfp

DAHUA_HTTP_API_FOR_DVR_V1.29.pdf ………………………………… http://tinyurl.com/klc72tr

General_ConfigTool_Eng_V1.0.5.R.120428.zip …………………… http://tinyurl.com/mwlzbb3

General_ConfigTool_Eng_V1.06.1.T.120807.zip …………………… http://tinyurl.com/leudphu

General_ConfigTool_Eng_V1.07.2.R.130304.zip ………………….. http://tinyurl.com/obs5ud7

General_ConfigTool_Eng_V1.07.3.R.130701.zip ………………….. http://tinyurl.com/o6p628f <—- Use this one

General_ConfigTool_Eng_V2.00.0.R.140410.zip …………………… http://tinyurl.com/nbqtgev

Firmware Files

Firmware files are grouped by camera type and video signal (NTSC –> Eng_N / PAL –> Eng_P / or BOTH –> Eng_NP)

Files are ordered by version number with the latest Firmware in blue.

Files with DH_ prefix are DAHUA direct firmware files and those with General_ prefix are general release for OEM cameras but I’ve had good luck with both.

DH_IPC-HX1100_Eng_NP_V2.210.0000.3.R.20140416.bin ………………………………………….. http://tinyurl.com/m2jf3qv

General_IPC-HX3(2)XXX_Eng_N_V2.210.0001.0.R.20130517.bin ……………………………………….. http://tinyurl.com/q98zg9x

General_IPC-HX3(2)XXX_Eng_P_V2.210.0001.0.R.20130517.bin ………………………………………… http://tinyurl.com/nekapn3

General_IPC-HX3(2)XXX_Eng_NP_V2.210.0001.0.R.20130517.bin ……………………………………… http://tinyurl.com/p59ym6z

General_IPC-HX3(2)XXX_Eng_P_V2.211.0000.0.R.20130726.bin ………………………………………… http://tinyurl.com/my54r9z

General_IPC-HX3(2)XXX_Eng_N_V2.212.0000.0.R.20131206.bin ……………………………………….. http://tinyurl.com/lrvtm2z

General_IPC-HX3(2)XXX_Eng_P_V2.212.0000.0.R.20131206.bin ………………………………………… http://tinyurl.com/n9rv23n

General_IPC-HX3(2)XXX_Eng_N_V2.212.0001.0.R.20131224.bin ……………………………………….. http://tinyurl.com/l5kg2d9

General_IPC-HX3(2)XXX_Eng_P_V2.212.0001.0.R.20131224.bin ………………………………………… http://tinyurl.com/q6c2gox

DH_IPC-HX3(2)XXX_Eng_NP_8M_V2.212.0000.4.R.20140307.bin ……………………………………….. http://tinyurl.com/mnzx33h

DH_IPC-HX3(2)XXX_Eng_NP_8M_V2.212.0000.5.R.20140326.bin ……………………………………….. http://tinyurl.com/ke285w5

DH_IPC-HX3(2)XXX_Eng_NP_8M_V2.212.0000.6.R.20140419.bin ……………………………………….. http://tinyurl.com/mllzcox

General_IPC-HX3(2)XXX_Eng_P_V2.420.0000.0.R.20140414.bin ………………………………………… http://tinyurl.com/nftaogy

DH_IPC-HX3(2)XXX_Eng_N_V2.420.0000.0.R.20140414.bin ……………………………………………. http://tinyurl.com/ma5q64d

General_IPC-HX5(4)XXX_Eng_P_V2.210.0000.2.R.20130821.bin …………………………………………. http://tinyurl.com/pdcdmdk

General_IPC-HX5(4)XXX_Eng_N_V2.210.0000.4.R.20130911.bin ……………………………………………….. http://tinyurl.com/pdoxjzj

General_IPC-HX5(4)XXX_Eng_P_V2.210.0000.9.R.20131217.bin ……………………………………………….. http://tinyurl.com/p3g4t54

General_IPC-HX5(4)XXX_Eng_N_V2.210.0000.10.R.20140111.bin ……………………………………………… http://tinyurl.com/mnjpd79

General_IPC-HX5(4)XXX_Eng_P_V2.210.0000.12.R.20140225.bin ……………………………………………… http://tinyurl.com/nssnph6

DH_IPC-HX5(4)XXX_Eng_NP_V2.210.0000.12.R.20140225.bin …………………………………………….. http://tinyurl.com/lcjr8xv

DH_IPC-HX5(4)XXX_Eng_NP_V2.210.0000.16.R.20140421.bin …………………………………………….. http://tinyurl.com/k67gu9u

DH_IPC-HX5(4)XXX_Eng_NP_V2.210.0000.18.R.20140429.bin ……………………………………………. http://tinyurl.com/n779scx

General_IPC-HX5(4)XXX_Eng_N_V2.210.0000.21.R.20140613.bin ……………………………………………… http://tinyurl.com/qd2thhe

General_IPC-HX5(4)XXX_Eng_P_V2.210.0000.21.R.20140613.bin ……………………………………………… http://tinyurl.com/p8q75b4

General_IPC-HX5(4)XXX_Eng_N_V2.400.0000.0.R.20131231.bin ……………………………………………….. http://tinyurl.com/kmd7hu9

DH_IPC-HX5(4)XXX_Eng_N_Stream3_V2.420.0000.0.R.20140419.bin ………………………………………….. http://tinyurl.com/mb75g2n

DH_IPC-HX5(4)XXX_Eng_P_Stream3_V2.420.0002.0.R.20140621.bin …………………………………….. http://tinyurl.com/laj29k5

General_IPC-HX5(4)XXX_Eng_N_Stream3_V2.420.0000.0.R.20140419.bin ………………………………….. http://tinyurl.com/mzw85fz

General_IPC-HX5(4)XXX_Eng_P_Stream3_V2.420.0000.0.R.20140419.bin ………………………………….. http://tinyurl.com/ov6krph

General_IPC-HX5(4)XXX_Eng_P_Stream3_P2P_V2.420.0000.0.R.20140419.bin …………………………… http://tinyurl.com/oxgblkq

General_IPC-HX5(4)XXX_Eng_N_Stream3_V2.420.0002.0.R.20140621.bin ………………………………….. http://tinyurl.com/kejg3fv

General_IPC-HX5(4)XXX_Eng_P_Stream3_V2.420.0002.0.R.20140621.bin ………………………………….. http://tinyurl.com/pfmevdu

General_IPC-HX5(4)XXX_Eng_N_Stream3_V2.420.0003.0.R.20140930.bin ……………………………………….. http://tinyurl.com/kchslos

General_IPC-HX5(4)XXX_Eng_N_V2.420.0003.0.R.20140930.bin ……………………………………………….. http://tinyurl.com/ok4f8fx

General_IPC-HX5(4)XXX_Eng_N_Stream3_V2.420.0005.0.R.20141205.bin ………………………………………. http://tinyurl.com/qbrfg3k

General_IPC-HX5(4)XXX_Eng_P_Stream3_V2.420.0005.0.R.20141205.bin ………………………………….. http://tinyurl.com/ot99vgw

DH_IPC-HX8XXX_Eng_NP_V2.400.0000.2.R.20140506.bin …………………………………………………. http://tinyurl.com/lbar98x

I will also post the bare metal img files when I get some time which contain the firmware and all the img files including the update.img that can be used for serial recovery.

I have just started the process of uploading firmware… There are much more to come as well as many more camera models.

Also if you have any you want to share please PM me what you have and where I can link them to this thread.

Thanks to Euly for sharing firmware files!

IMPORTANT NOTE FOR IPC-HFW4300S-V2 CAMERAS

The new camera appears to have differences (a few that I already found) that makes some of the general firmware incompatible with them. I have found a workaround, but it is complex. I will try to summarize it in a separate thread in the following weeks. I will also repackage the newest firmware files in versions that will work for the V2 cameras. Stay tuned! In the meantime, you can use General_IPC-HX5(4)XXX_Eng_N_V2.210.0000.21.R.20140613.bin or the PAL equivalent to recover your camera.

Well, that’s all I have time to share for now, but I’ll do my best to put together a comprehensive guide to the inner workings of these cameras and a guide to unbrick in any failed software situation.

Thanks and take care.

<p>The post Unbricking your Dahua IP camera (Tips, Tricks & Firmware) first appeared on NVR IPCAMERA SECURITY.</p>

As mentioned in the introduction, the BIOS chip from my Lenovo X1 Yoga laptop got corrupt and I managed to repair things by reflashing it with a working BIOS ROM. For this article, I will repeat the steps I took, on a Dell Precision T1700 MT. The process is exactly the same.

editor’s note: the following explanation also applies to dvr or nvr recorders.

Youtube Video

If you are interested, I also created a YouTube video from this blogpost. If you prefer classic text, you can just follow the rest of this article:

Introduction

There are several ways to (re-)program the contents on your BIOS chip. The easiest is by running a BIOS update/programming tool directly on your working machine. The BIOS is mostly only used during the initial boot time and can safely be reflashed on a started system. Obviously, for that to work, the system still has to be able to boot. If this is no longer the case, you will need to reprogram the BIOS using another device.

BIOS chips come in several different packages. Today, in my experience, most of the times, a SOIC-8 package is used. This is a soldered 8 pin (2×4) IC. This was the case for the Lenovo X1 yoga but also for the Dell Precision T1700 MT and some other systems I checked.

Hardware requirements

1) Programmer

In order to read and write the contents on our BIOS chip, we will need a programmer that can physically connect with it and perform those actions.

There are a lot of different types of programmers out there but a popular model, most likely due it’s wide availability for low prices on Ebay, Amazon or Aliexpress, is the CH341a MiniProgrammer:

This device allows a variety of options to program/flash SPI flash or BIOS chips but also other types of EEPROMs of type 24XX and 25XX which are found in various devices like routers, access points, videocards,… and is suited to program the SOIC-8 BIOS chips that are used in a lot of systems these days.

2) Adapter, cable or clip

In case your BIOS chip is socketed, you can remove the chip from the board and place it on top of the programmer (with an adapter). If it’s soldered on the board you will either need to de-solder it or use a clamp/clip that fits the package type of your BIOS chip.

Although desoldering this type of IC is not very hard, it’s still a lot easier to use a clip that is suited for the package type. This avoids the need to remove the chip from the motherboard and the risk to potentially damage other components.

The clip, as you can see above, can be placed on top of the chip on the board. When doing so, you need to carefully pay attention that the red wire, indicating pin 1, matches with the side of the IC that has a small dot, indicating pin 1 on chip side.

The rest of the connections should follow the same rule. On the CH341a MiniProgrammer, there is also an indication to where pin 1 should be inserted. As you can see, this is more towards the middle: top row, 4th pin from left to right, of the pin layout for a SPI/BIOS chip (type 25).

While connecting the IC to the programmer, make sure the motherboard is powerless and the programmer is not connected to USB either as this could potentially corrupt/erase or even break the BIOS chip.

3) Locate the BIOS chip on the motherboard

The location of the BIOS chip on the motherboard is not always very clear. By searching for ICs that look like a SOIC-8 chip, you can already eliminate a lot. If you’re lucky it has a nearby label like BIOS or SPI. Also, I noticed that in most cases it is not too far from the CMOS battery. Unfortunately there is no fixed rule. You probably will need to search a bit or put your hopes on mighty Google to find someone else that already went through the same exercise.

For the Dell system, I found the BIOS chip on the lower right part of the motherboard, next to a label “SPI”:

For my Lenovo X1 Yoga, it was harder to find as the laptop has a plastic foil covering the internal components and I didn’t want to completely remove it. It turned out to be located near the cellular modem, under the connector for the screen:

4) Identify BIOS chip type

The programmer is not always able to detect the exact chip type. To make sure, you will need to read the physical label on the chip itself or make sure to look up which exact type is used in your system.

For the Dell system I used, the text was pretty readable by taking a proper macro picture and zooming in:

The label is among the detected types: MX25L3273E.

For the Lenovo X1 Yoga, I was not able to read the label as it got washed out somehow. All I could see was the Winbond label. After a quick Google search I found that for that device, the SPI type was W25Q128FV.

Software requirements

Windows

For Windows, you will need a tool to read and write the contents of the BIOS flash chip. For this post, I used AsProgrammer which you can download from here: https://github.com/nofeletru/UsbAsp-flash/releases/

There are probably other working tools but I found this one to give the best results with the CH341a. Drivers were not needed for the programmer. It just worked when connecting it to USB on Windows 10.

Linux

For Linux, similar as in Windows, you will need a tool to read/write to the SPI. Here I used flashrom which is part of most distributions’ repositories. Same as for Windows, no additional kernel modules were needed to recognize and use the CH341a on my system.

You can easily install flashrom using your package manager.

For example for Debian 10:

jensd@deb10:~$ sudo apt install flashom
Reading package lists… Done
Building dependency tree
Reading state information… Done
…

BIOS chip programming

For both Windows and Linux, the same sequence of steps can be following:

1. Connect the clip to the BIOS chip, nothing should be powered
2. Connect the clip or adapters to the CH341a programmer
3. Connect the CH341a programmer to USB.
   I recommend using an extension cable instead of putting it directly in your USB port.
4. Start the tool to program (AsProgrammer for Windows, flashrom for Linux)
5. Make sure you configure the correct type of programmer and BIOS chip
6. Read the data from the chip twice and save it to a file each time
7. Verify the checksum of both files
   This is to make sure that there is no corruption when reading data from the chip. As reading in this condition could brick/corrupt it.
8. Write the correct/modified file to the chip
9. Optionally perform another read and verify the checksum of this with the written file to make sure the contents matches with what you flashed in it.

Programming under Windows

We start with step 5 as explained above. After starting AsProgrammer we first need to set it to use a CH341a. This can be done in the hardware menu:

Next. we can click the icon to detect the chip type:

As mentioned above, the programmer is not always able to detect the exact type and gives you a list of possible options. We identified the Dell BIOS chip as type MX25L3273E so we can select this from the list here.

Next, step 6, we can read the data from the chip by clicking the icon with the green arrow. Once reading is completed, save the output to a file by clicking on the save (disk) icon.

It’s important to repeat this step twice as we need to make sure that communication with the IC is working as expected:

After completing and saving the second dump of the BIOS, we can compare the two files to see if they are exactly the same. This is step 7. We can do that easily by calculating the MD5 checksum from them. In Windows this can be done using certutil with the following command:

Microsoft Windows [Version 10.0.18363.1256]
(c) 2019 Microsoft Corporation. All rights reserved.

C:\Users\jensd>cd c:\data\BIOS

c:\data\BIOS>certutil -hashfile bios1 md5
MD5 hash of bios1:
83bcd273cf7a5fd9a1075b823c83a0e2
CertUtil: -hashfile command completed successfully.

c:\data\BIOS>certutil -hashfile bios2 md5
MD5 hash of bios2:
83bcd273cf7a5fd9a1075b823c83a0e2
CertUtil: -hashfile command completed successfully.

In the above output we can see that both files generated the same hash, so they are identical. This is a good indication that communication with the IC and programmer works as expected.

Both files can now be saved as a backup in case things go wrong of in case you want to reflash the BIOS to an older version.

Next, we can finally write the new or modified contents to the BIOS chip. This can be done by first opening a rom file in AsProgrammer, using the open button, then clicking the down arrow next to the write button and choosing Unprotect -> erase -> programm -> verify:

You can follow the progress and status in the bottom of the window:

Once programming is done, optionally, you can read the BIOS chip again, as indicated above, and compare the hash of the written file with the actual contents after writing. This is to make sure that there is no corruption and the contents of the chip matches exactly with the data you wanted to be there.

Programming under Linux

The steps under Linux are the same as from Windows. Only here we will use the CLI tool flashrom. As on Windows, we need to go through step 5 and set the correct programmer and BIOS type. The easiest is to launch the tool and let it try to detect the type of BIOS chip:

jensd@deb10:~$ sudo flashrom --programmer ch341a_spi -r backup1.bin
flashrom  on Linux 4.19.0-13-amd64 (x86_64)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Macronix flash chip "MX25L3205(A)" (4096 kB, SPI) on ch341a_spi.
Found Macronix flash chip "MX25L3205D/MX25L3208D" (4096 kB, SPI) on ch341a_spi.
Found Macronix flash chip "MX25L3206E/MX25L3208E" (4096 kB, SPI) on ch341a_spi.
Found Macronix flash chip "MX25L3273E" (4096 kB, SPI) on ch341a_spi.
Multiple flash chip definitions match the detected chip(s): "MX25L3205(A)", "MX25L3205D/MX25L3208D", "MX25L3206E/MX25L3208E", "MX25L3273E"
Please specify which chip definition to use with the -c <chipname> option.

Same as with AsProgrammer, we can see that flashrom is able to come up with a selection but we still have to specify the exact type using the -c option. As our type is MX25L3273E, we can now read the contents of the chip and save it to file backup1.bin using the following command:

jensd@deb10:~$ sudo flashrom --programmer ch341a_spi -r backup1.bin -c "MX25L3273E"
flashrom  on Linux 4.19.0-13-amd64 (x86_64)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Macronix flash chip "MX25L3273E" (4096 kB, SPI) on ch341a_spi.
Reading flash... done.
jensd@deb10:~$ sudo flashrom --programmer ch341a_spi -r backup2.bin -c "MX25L3273E"
flashrom  on Linux 4.19.0-13-amd64 (x86_64)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Macronix flash chip "MX25L3273E" (4096 kB, SPI) on ch341a_spi.
Reading flash... done.

Same here again is to read the contents twice and save it in two different files. Once done, it’s time for step 7 and we can compare the checksum of the files to see if they are matching:

jensd@deb10:~$ md5sum backup1.bin
83bcd273cf7a5fd9a1075b823c83a0e2  backup1.bin
jensd@deb10:~$ md5sum backup2.bin
83bcd273cf7a5fd9a1075b823c83a0e2  backup2.bin

Like on Windows, using this method we can be sure that the programmer can communicate properly with the chip and we reduce the chance for corruption. All seems to be good in the above output. If you see a different hash, you first need to fix this before proceeding.

backup1.bin and backup2.bin can be saved for later as they are a proper backup of the current contents of you BIOS chip.

The next step is to write the backup, dump or modded file using flashrom. This time we use the -w option and specify the input file:

jensd@deb10:~$ sudo flashrom --programmer ch341a_spi -w bios.bin -c "MX25L3273E"
flashrom  on Linux 4.19.0-13-amd64 (x86_64)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Macronix flash chip "MX25L3273E" (4096 kB, SPI) on ch341a_spi.
Reading old flash chip contents... done.
Erasing and writing flash chip...
Warning: Chip content is identical to the requested image.
Erase/write done.

Optionally here as well is to read the contents again and to compare the MD5 checksum with the file we used as input (bios.bin).

In the example above, I wrote back the earlier backed up file, so flashrom was smart enough to detect this and give me a warning about it.

Hopefully this article can help some people that, just like I was, feel bad because their expensive piece of hardware completely stopped working just because the contents of one tiny IC got corrupted.

<p>The post BIOS or SPI programming on Windows or Linux first appeared on NVR IPCAMERA SECURITY.</p>