Lorex LNB8005B-C and Dahua firmware (Solved with instructions)

pozzello said:
appreciate the efort, but ya lost me at "make sure you enable PUT (Write=Y overwrite=Y) "
where/how do I do that?...
Click to expand...
I use the OpenTFTPServerMT tool that is on the site here, under the Bin folder there is OpenTFTPServerMT.ini and within it you need to change:

[TFTP-OPTIONS]
timeout=300
read=Y

to

[TFTP-OPTIONS]
timeout=300
read=Y
write=Y
overwrite=Y

to enable uploading to the tftp server from the camera
 
OK, i can try a different TFTP server if that helps receive uploads from the cam,
but perhaps I should be trying to get the files off the working/unmolested Lorex cam,
in which case the 280-specific addresses in your script may not be correct or helpful?...

I just tried again with the oldest firmware I could find having "IPC-HFW4830E-S" in the check file:
General_IPC-HX5X3X-Rhea_Eng_N_Stream3_V2.460.0000.15.R.20170907
same results, appears to download all the files, tries to boot kernel, loops after a minute or so...
 
I'm not sure which version the signed bootloader started with but if I'm able to get a copy off my lorex I'll try another camera with the 2.460 firmware.

I would try another TFTP server perhaps, but the script may not work for you either with the stock camera as the stock lorex firmware I have doesn't have upload enabled on TFTP only download, seems Dahua implemented it at some point in their firmware chain but I'm not sure which version. The addresses thought are consistent across firmware though from what I can see as both the stock lorex firmware and the 2.80 firmware use the same addresses.

I'm still plugging away to get the firmware off of the stock lorex without tftp upload, right now it's looking like i will have to use memory display to output the memory contents to console. I'm going to attempt to pipe the ncat console into a dump file, then run the memory display through the commands.txt to see if I can get the contents that way. It will be very slow and may not work but if I'm able to get the bootloader that way I can at least try resetting the signed bootloader and if that works I can upload a newer firmware and try to find one that isn't signed but allows tftp uploads.
 
sounds like more trouble than it's worth, at least for me, so please don't waste your time on my account... thanx, Paul.
 
The whole commands.txt file format didn't work well, only captured some of the data. Tomorrow I'm aiming to try another method of capturing the contents. It's not really a problem as I need it for myself as well and I want to have a backup image of the firmware.

Once I have the raw dump I could then look at how to make it into an image for the web interface so it wouldn't need a serial console to update.
 
OK, just as I was about to give up, I figured out something that was not clear (to me) before:

After executing the commands in the commands.txt file, my bootloader was always asking for file "success.txt." via tftp.

As I was faithfully closing out the TFTP server when i saw that ".FLASHING_DONE_STOP_TFTP_NOW", my tftpserver was never around to answer the
request for file "success.txt". It would try a few times, then apparently give up, which I thought was normal, but it turns out,
IT REALLY WANTS TO GET THE SUCCESS.TXT FILE!.

I created a blank file by that name in the 'root directory and let the camera grab it after all the other commands completed.

Lo and behold, the cam did NOT reboot 60 seconds later! I almost fell out of my chair! waited a few more minutes just to be sure,
then fired up the Dahua config tool and "Viola!!" What previously appeared as an LNB8005-C now show sup as "IP CAMERA"
( I had uploaded a 'General' build, not Dahua-branded.)

I have yet to get into the UI and see how it's working, but at least the mystery of why I couldn't seem to TFTP a working firmware is behind me...

thanx to Corellon for your tips and persistance/patience on this! It's Miller Time! Paul

1586835392324.png1586835392324.png
 
  • Like
Reactions: VorlonFrog and Corellon
Wow that is so interesting, I've never had to actually send a success.txt file or a failure.txt file, wonder if was something in that specific loader build? I will have to keep it in mind as it always to me was just a status prompt to say if it failed or succeeded.

Thanks for the info
 
Ok I I have (I think) pulled a complete dump of the stock firmware, I still need to "extract" it from the console logs but by enabling logging of the serial console and running the below memory display commands I can extract the firmware in hex format and split into the proper files.
sf read 0x02000000 0x0000000000000000 40000;md 0x02000000 10000;echo MinBoot.bin
sf read 0x02000000 0x0000000000080000 40000;md 0x02000000 10000;echo U-Boot.bin
sf read 0x02000000 0x00000000000c0000 20000;md 0x02000000 8000;echo hwid.bin
sf read 0x02000000 0x00000000000e0000 10000;md 0x02000000 4000;echo partition.bin
sf read 0x02000000 0x00000000000f0000 180000;md 0x02000000 60000;echo Kernel.bin
sf read 0x02000000 0x0000000000270000 150000;md 0x02000000 54000;echo romfs.bin
sf read 0x02000000 0x00000000003c0000 680000;md 0x02000000 1A0000;echo web.bin
sf read 0x02000000 0x0000000000a40000 1030000;md 0x02000000 40C000;echo user.bin
sf read 0x02000000 0x0000000001a70000 30000;md 0x02000000 C000;echo updateflag.bin
sf read 0x02000000 0x0000000001aa0000 70000;md 0x02000000 1C000;echo config.bin
sf read 0x02000000 0x0000000001b10000 10000;md 0x02000000 4000;echo product.bin
sf read 0x02000000 0x0000000001b20000 20000;md 0x02000000 8000;echo custom.bin
sf read 0x02000000 0x0000000001b40000 e0000;md 0x02000000 38000;echo backupker.bin
sf read 0x02000000 0x0000000001c20000 50000;md 0x02000000 14000;echo backupfs.bin
sf read 0x02000000 0x0000000001c70000 100000;md 0x02000000 40000;echo data.bin
sf read 0x02000000 0x0000000001d70000 290000;md 0x02000000 A4000;echo user1.bin
Trickiest part was that sf read takes memory length in hex format by bytes (8bit), but md displays by dword (32bit) so had to divide each by 4 to get the correct sizing. There is md.b which displays and counts in bytes but takes 4x as long since it reads and outputs per byte too.

Edit: Learning curve.... Take the putty.log file and change it to putty.csv and import with space as the deliminator. You get 5 columns of value, the first is the offset and the next 4 are the data (in hex), turns out though that md puts out the dword hex reversed, so byte 4 is byte 1, byte 3 is byte 2, etc. I had to transpose the data in excel using the below formula to revert it back.

=TEXTJOIN("",1,MID(B4,{7,5,3,1},2))
 
Last edited:
I'm at a bit of a loss now... Sf write and SF protect don't seem to work, they just take me back to the syntex help explanation. I'm wondering if those commands are disabled, if they are I'm at a dead end
 
So I may have declared success too soon, and now am pretty well hosed.

After what appeared to be a successful conversion from Lorex to Dahua, I tftp'd the latest version i could find for 4830EP-S cams:
DH_IPC-HX5X3X-Rhea_MultiLang_NP_Stream3_V2.800.0000014.0.R.191203

It seemed to run fine on the bench, with serial connections attached, powered by 12v adapter (not PoE).
I reset to default in the web UI, re-configured it for my network and video setting preferences, etc, all good.
Then I powered it down, closed it back up and plugged into a PoE switch. It did NOT appear. crap.

Re-TFTP'd, boots and found in the UI again. OK. back on the PoE switch and dead again. PoE kills it somehow,
or something on my 'normal' network, maybe... Weird.

Back on the bench again, opened up with serial connection to see what's happening, and It's boot-looping again. WTF.
Can't seem to get anything to take this time. Repeated tftp transfers leave it boot-looping. Didn't this work before? arg.

In desperation, I tried the 'cfgRestore' command. BAD IDEA. Previously 'printenv' command showed
"Environment size: 1340/131068 bytes", but now I have "Environment size: 1048/131068 bytes".
dammit. Missing apparently important things like HWID and others.

I can manually 'editenv <var>' to add the missing environment variables back at the u-boot shell, but haven't
found a way to do it in the 'commands' file, nor any way to save these back so they don't need to be reset on every boot.
There's a command to set and save the HWID only, not the other variables that I'm missing...

ideas?
 
Everything is stored in the partition, if you can find out what partition is corrupted it can be restored, have you tired a factory reset? sometimes the lorex config seems to boot loop.

Another cause which might be the case but I would do as the last resort is I've heard some talk of the kernel checking the boot loader and if it's not updated going into a boot loop but I can't confirm that or readily find the source I thought I read it from.

Does SF write work for your shell? If it does I can provide images of the different partitions you can use and upload

There is also a saveenv command that will save the environment variables back to flash in theory (I haven't attempted)
hwid will also set the hwid information and save to flash (again theory)
 
Last edited:
once i realized i was using the non-scriptable 'editenv' command rather than the simpler 'setenv' command, I was able to re-create the env with the following command file
(provided for example only - don;t apply this to your! cam)

echo "setting env vars"
setenv bootdelay 3
setenv baudrate 115200
setenv ipaddr 192.168.1.108
setenv autoload yes
setenv gatewayip 192.168.1.1
setenv netmask 255.255.255.0
setenv dh_keyboard 1
setenv sysbackup 1
setenv logserver 127.0.0.1
setenv loglevel 4
setenv autosip 192.168.254.254
setenv autolip 192.168.1.108
setenv autogw 192.168.1.1
setenv autonm 255.255.255.0
setenv pd tftp '0x02000000 pd-x.squashfs.img; flwrite'
setenv ethact 'ambarella mac'
setenv BSN 3B04645PAA00640
setenv serverip 192.168.1.1
setenv da 'tftp 0x2000000 dhboot.bin.img; flwrite; tftp dhboot-min.bin.img;flwrite'
setenv dr 'tftp 0x2000000 romfs-x.squashfs.img; flwrite'
setenv dk 'tftp 0x2000000 kernel.img; flwrite'
setenv du 'tftp 0x2000000 user-x.squashfs.img; flwrite'
setenv dw 'tftp 0x2000000 web-x.squashfs.img; flwrite'
setenv dc 'tftp 0x2000000 custom-x.squashfs.img; flwrite'
setenv dt 'tftp 0x2000000 data-x.squashfs.img; flwrite'
setenv dp 'tftp 0x02000000 partition-x.cramfs.img;flwrite'
setenv up 'tftp 0x2000000 update.img; flwrite'
setenv tk 'tftp 0x200100 hawthorn.dts.dtb;tftp 0x2000000 uImage;bootm 0x2000000'
setenv bootcmd 'sf read 0x200100 0x8000 0x8000;sf read 0x2000000 0xf0000 0x180000;bootm 0x2000000'
setenv bootargs 'console ttyS0,115200 mem 118M root /dev/mtdblock5 rootfstype squashfs init /linuxrc'
setenv HWID 'IPC-HFW4830EP-S:01:02:03:50:21:00:01:00:00:00:04:2D0:00:00:00:00:00:01:00:00:200'
setenv hwidEx '00:02:00:00:00:00:00:00:00:00:00:00:00:00:00:00'
setenv devalias 'IPC-HFW4830E-S'
setenv ID 'ND011705005350'
setenv ethaddr 00:40:7F:8E:D2:8E
setenv appauto 1
setenv stdin serial
setenv stdout serial
setenv stderr serial
setenv filesize DF
setenv fileaddr 5000000
echo "printing env vars"
printenv

there's also a 'saveenv' command, but u-boot seems to do that automatically once it successfully completes the command script, so the env vars remained even after reboot.

then re-flashed to old 2.460 vi tftpd, factory reset from UI, upgraded to latest 2.800 R14 via WEBUI (which also updated the bootloader) and it's ALIVE again. whew.

re-assembled and working on my 'regular' network, unlike last time, but haven't dared trying PoE again...
 
Glad to here it's working for you, Do you find an image quality difference between stock Lorex and 2.800? for me the camera is more green tinged at night and alot more grain. i'm still at a loss of how to get sf write to work, I'm starting to suspect it's been disabled :S without that I'm at a loss of how to revert the boot loader back to something earlier then 2.800
 
maybe 'run da' with the bootloader .img files from an earlier Dahua release,
like General_IPC-HX5(4)XXX_Eng_N_Stream3_V2.420.0005.0.R.20141205 (attached)

Why put so much effort into retaining the Lorex bootloader and/or image?...

So far only confirmed it works now (even on PoE, yea!) Haven't compared image/quality to stock, but
I'll install this cam next to the one I have up already for a day or two to compare Lorex vs Ex-Lorex in a real-world test... :-)
 

Attachments

It's mostly about having an unsigned boot loader, even 2.622 has a signed boot loader so you can't modify the file system (like enable telnet) or downgrade a version (Lowest I can go now is 2.800.0, I can't go to 2.622 or 2.420)

Even run da doesn't work because flwrite checks the signature and fails if it's not signed and is not equal to or higher then the version already flashed. At least I know with the rest of my camera's not update via the web interface and I'll retain some flexibility until I can figure out the one camera.
 
Thought I would post an update here, I have updated 4 more camera's (Minus bootloaders) directly from the Lorex firmware to 2.800.14 without issue, S.O.P. was start fresh from stock, update to 2.800.14, do a complete factory reset and setup from from there.

I tried some other versions of 2.800 but so far 14 has been the one with the least issues (occasionally while recording the web server is unresponsive) as others would lock up, stop sending the video feed, report incorrect framerates to blue iris or otherwise mess up the recording issues.

I have managed to get the quality of the recordings to be fairly decent again, the first camera must have had something wrong in the upgrade path as after I reset it to factory default (including network), reflashed the firmware through TFTP, reset to factory default again and then setup it behaved much better.
 
  • Like
Reactions: jeremyamoore
Huge headache getting my stock Lorex LNB8005-C (HWID=IPC-HFW4830EP-S) updated, but here's what finally worked for me to get from Lorex v2.460:

1. Download DH_IPC-HX5X3X-Rhea_EngSpnFrn_N_Stream3_V2.460.0000000.16.R.20170904.bin firmware (link)
2. Extract the bin file to the TFTP root folder
3. TFTP using the following command.txt:
run dr
run dk
run du
run dw
run dp
run dc
run pd
tftp 0x2000000 pd-x.squashfs.img; flwrite
tftp 0x2000000 .FLASHING_DONE_STOP_TFTP_NOW
sleep 5
Click to expand...
4. Find the updated device (may no longer be 192.168.1.108) using Dahua config tool
5. Login and update to DH_IPC-HX5X3X-Rhea_MultiLang_NP_Stream3_V2.800.0000014.0.R.191203.bin using the web console.

I could not update to 2.800 directly from stock Lorex firmware. Not sure it it's the size of the partitions or if I just screwed something up during one of my many attempts at different commands and firmware.
 
  • Like
Reactions: Natrinicle
sorens said:
Not sure it it's the size of the partitions
Click to expand...
They do change the partition layout between some firmware versions.
But the update process should handle that OK.

You might be interested in this :

Smartening up the Lorex LNB8005C 8MP mini bullet.

Something I do for fun and a little mental exercise is watch out for 'spares and repairs' IP surveillance items on eBay. These can provide an interesting insight into how the different manufacturers do things, and is a bit self-funding if fixed-up items can be re-sold. I recently bought for a...
ipcamtalk.com ipcamtalk.com

What Lorex firmware version did you start with?
 
I just re-flashed another ebay-special LNB8005c to dahua firmware, pretty much exactly as @sorens describes
(minus the extra line "tftp 0x2000000 pd-x.squashfs.img; flwrite ", which is a dupe of the 'run pd' command, but no harm there)

nice to get
1) I-frame interval control! (the Lorex firmware defaulted to 2x the frame rate, but now i can set it to whatever)
2) a 4th profile option for day/night
3) works in non-ie browsers without a plugin. yea!
4) working ONVIF via ODM. yea!
5) more 'smart' features that I don't use, as I run BI for that stuff (IVS & Face Detection, to be specific)
6) more substream resolution options and 'clipping feature' for substream 2
7) more options in video/overlay for 'font attribute' and 'custom overlay'
8) 'online upgrade' option that can't work on my network as cams can't reach the internet...
9) more options in video/path for playback & video that can't work as the cam has no SD card.
10) more pages under Network for '802.1x' and 'Access Platform' (which defaulted to ON, but is now disabled)

seem to lose:
1) snapshot options in the video/snapshot page. Lorex allows selecting snapshot from main or substream, Dahua defaults to main stream only.

totally worth the effort, for this cam, to convert it into the IPC-HFW4830E-S it really wants to be (minus the sd card)...:)
 
Last edited:
  • Like
Reactions: alastairstevenson
You must log in or register to reply here.
Top Bottom