Smartening up the Lorex LNB8005C 8MP mini bullet.

alastairstevenson

Staff member
Oct 28, 2014
16,064
6,885
Scotland
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 pittance a Lorex LNB8005C 8MP mini-bullet which the seller described as 'Just stopped working. No link detect or PoE activity'.
I've not previously had my hands on a Lorex IP camera.
Sure enough, it appeared dead when powered either by 12V or PoE.
Luckily - some electronic fault-finding identified that a shorted ceramic capacitor was killing the first-level (12v to 5v) power convertor.
I fixed that and the camera came to life!
See this post :


A look around the web GUI showed a pretty bare-bones level of functionality.
No smart events, just motion. ONVIF didn't work. Limited video parameter configuration.
This was the firmware version :

System_5.jpg

I remembered this interesting and helpful thread :

with contributions from @Corellon @pozzello @hope__silent silent where the Lorex firmware was replaced by Dahua firmware to good effect.
So I thought I'd give it a try.
The thread gave some useful pointers to firmware that could be used, so I downloaded these candidates :

DH_IPC-HX5X3X-Rhea_MultiLang_NP_Stream3_V2.800.0000010.0.R.190807.bin
General_IPC-HX5(4)XXX_Eng_N_Stream3_V2.420.0005.0.R.20141205.bin
General_IPC-HX5X3X-Rhea_Eng_NP_Stream3_V2.800.0000010.0.R.190807.bin

And extracted the components.
It's known that the dahua firmware is packaged as a slighly modified zip file, with the first 2 bytes holding 'DH' instead of the usual 'PK' (Phil Katz RIP - remember him? A big loss to the coding community Phil Katz - Wikipedia)
If the DH is replaced by PK then the 'Install' update task list can be usefully extracted.
Code:
alastair@PC-I5 ~/cctv/other/Lorex/Lorex LNB8005-CP/misc_firmware/tmp $ ll
total 50496
drwxrwxr-x 2 alastair alastair     4096 Nov 26 16:00 ./
drwxrwxr-x 5 alastair alastair     4096 Nov 26 15:58 ../
-rw-rw-r-- 1 alastair alastair 25846976 Nov 26 15:59 DH_IPC-HX5X3X-Rhea_MultiLang_NP_Stream3_V2.800.0000010.0.R.190807.bin
-rw-rw-r-- 1 alastair alastair 25846976 Nov 26 16:00 modded_fw.bin
alastair@PC-I5 ~/cctv/other/Lorex/Lorex LNB8005-CP/misc_firmware/tmp $ hd -n 64 DH_IPC-HX5X3X-Rhea_MultiLang_NP_Stream3_V2.800.0000010.0.R.190807.bin
00000000  44 48 03 04 14 00 00 00  08 00 2c 56 07 4f bf c0  |DH........,V.O..|
00000010  e4 87 0b 01 00 00 fa 02  00 00 07 00 1c 00 49 6e  |..............In|
00000020  73 74 61 6c 6c 55 54 09  00 03 34 3c 4a 5d 37 3c  |stallUT...4<J]7<|
00000030  4a 5d 75 78 0b 00 01 04  71 fe 0f 00 04 71 fe 0f  |J]ux....q....q..|
00000040
alastair@PC-I5 ~/cctv/other/Lorex/Lorex LNB8005-CP/misc_firmware/tmp $ hd -n 64 modded_fw.bin
00000000  50 4b 03 04 14 00 00 00  08 00 2c 56 07 4f bf c0  |PK........,V.O..|
00000010  e4 87 0b 01 00 00 fa 02  00 00 07 00 1c 00 49 6e  |..............In|
00000020  73 74 61 6c 6c 55 54 09  00 03 34 3c 4a 5d 37 3c  |stallUT...4<J]7<|
00000030  4a 5d 75 78 0b 00 01 04  71 fe 0f 00 04 71 fe 0f  |J]ux....q....q..|
00000040
alastair@PC-I5 ~/cctv/other/Lorex/Lorex LNB8005-CP/misc_firmware/tmp $
alastair@PC-I5 ~/cctv/other/Lorex/Lorex LNB8005-CP/misc_firmware/tmp $ unzip modded_fw.bin
Archive:  modded_fw.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
  inflating: dhboot-min-halfstart.bin.img
extracting: sign.img           
alastair@PC-I5 ~/cctv/other/Lorex/Lorex LNB8005-CP/misc_firmware/tmp $
alastair@PC-I5 ~/cctv/other/Lorex/Lorex LNB8005-CP/misc_firmware/tmp $ cat Install
{
   "Commands" : [
      "burn dhboot-min.bin.img bootloader",
      "burn dhboot.bin.img bootloader",
      "burn kernel.img kernel",
      "burn partition-x.cramfs.img partition",
      "burn romfs-x.squashfs.img rootfs",
      "burn pd-x.squashfs.img pd",
      "burn user-x.squashfs.img user",
      "burn custom-x.squashfs.img custom",
      "burn web-x.squashfs.img web",
      "burn user1-x.squashfs.img user1",
      "burn blob.img blob",
      "burn dhboot-min-halfstart.bin.img bootloader",
      "burn mcu.bin.img mcu"
   ],
   "Devices" : [
      [ "SD6XXX", "1.00" ],
      [ "IPC-HX3XXX", "1.00" ],
      [ "IPC-HX4XXX", "1.00" ],
      [ "IPC-HX5XXX", "1.00" ],
      [ "IPC-HX8XXX", "1.00" ]
   ],
   "Vendor" : "General"
}
/IPC_RestoreDefault
alastair@PC-I5 ~/cctv/other/Lorex/Lorex LNB8005-CP/misc_firmware/tmp $

There are multiple threads explaining how the Dahua bootloader can be used to update the flash partitions so won't repeat them here.
One useful item of information that I haven't seen is an explanation of how the 'flwrite' commands in the bootloader macros know which flash offset to write the data to.
The firmware components are packaged in standard uImage format, and the 'Load Address' field specifies the flash offset that each file should be written to.
For example :
Code:
alastair@PC-I5 ~/cctv/other/Lorex/Lorex LNB8005-CP/misc_firmware/tmp $ dumpimage -l romfs-x.squashfs.img
Image Name:   romfs
Created:      Wed Aug  7 03:47:31 2019
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    2873528 Bytes = 2806.18 KiB = 2.74 MiB
Load Address: 01b80000
Entry Point:  01fd0000
alastair@PC-I5 ~/cctv/other/Lorex/Lorex LNB8005-CP/misc_firmware/tmp $

So when I hooked up the serial console to a USB to TTL serial USB adaptor I was ready to give the Lorex to dahua conversion a go.
Not wanting to risk creating a real brick, I didn't do any bootloader updates.

The next post has a transcript of the activity.
 
Last edited:
Code:
U-Boot 2010.06-svn4707 (Jun 30 2017 - 16:13:32)
I2C:   ready
DRAM:  118 MiB
gBootLogPtr:00b80008.
spinor flash ID is 0x1940ef
partition file version 2
rootfstype squashfs root /dev/mtdblock5
gParameter[0]:node=bootargs, parameter=console=ttyS0,115200 mem=130M root=/dev/mtdblock5 rootfstype=squashfs init=/linuxrc.
TEXT_BASE:01000000
Net:   Detected MACID:00:40:7f:b8:64:06
PHY:0x001cc816,addr:0x00
s3l phy RTL8201 init

MMC:   sdmmc init
Hit any key to stop autoboot:  0
>******************
Unknown command '******************' - try 'help'
>
>printenv
bootargs=console=ttyS0,115200 mem=118M root=/dev/mtdblock5 rootfstype=squashfs init=/linuxrc
bootcmd=sf read 0x2000000 0xf0000 0x180000;bootm 0x2000000
bootdelay=3
baudrate=115200
ipaddr=192.168.1.108
serverip=192.168.1.1
autoload=yes
gatewayip=192.168.1.1
netmask=255.255.255.0
da=tftp 0x02000000 dhboot.bin.img; flwrite;tftp dhboot-min.bin.img;flwrite
dr=tftp 0x02000000 romfs-x.squashfs.img; flwrite
dk=tftp 0x02000000 kernel.img; flwrite
du=tftp 0x02000000 user-x.squashfs.img; flwrite
dw=tftp 0x02000000 web-x.squashfs.img; flwrite
dp=tftp 0x02000000 partition-x.cramfs.img;flwrite
dc=tftp 0x02000000 custom-x.squashfs.img; flwrite
up=tftp 0x02000000 update.img; flwrite
tk=tftp 0x02000000 uImage; bootm
sysbackup=1
logserver=127.0.0.1
loglevel=4
autosip=192.168.254.254
autolip=192.168.1.108
autogw=192.168.1.1
autonm=255.255.255.0
pd=tftp 0x02000000 pd-x.squashfs.img; flwrite
ethact=ambarella mac
BSN=3K03ABCPAA04995
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
hwidEx=00:02:00:00:00:00:00:00:00:00:00:00:00:00:00:00
devalias=IPC-HFW4830E-S
ID=ND021711062399
ethaddr=00:40:7F:B8:64:06
filesize=262040
fileaddr=2000000
appauto=1
dh_keyboard=0
stdin=serial
stdout=serial
stderr=serial

Environment size: 1233/131068 bytes
>
>setenv serverip 192.168.1.99
>
>run dk
Using ambarella mac device
TFTP from server 192.168.1.99; our IP address is 192.168.1.108
Download Filename 'kernel.img'.
Download to address: 0x2000000
Downloading: #################################################
done
Bytes transferred = 1575384 (1809d8 hex)

## Checking Image at 02000000 ...
   Legacy image found
   Image Name:   kernel
   Created:      2019-08-07   2:40:43 UTC
   Image Type:   ARM Linux Firmware (uncompressed)
   Data Size:    1575320 Bytes = 1.5 MiB
   Load Address: 01040000
   Entry Point:  01200000
   Verifying Checksum ... OK
Programing start at: 0x01040000
SPI probe: 32768 KiB W25Q256FV at 0:1 is now current device
write : 100%
done
>
>
>run dp
Using ambarella mac device
TFTP from server 192.168.1.99; our IP address is 192.168.1.108
Download Filename 'partition-x.cramfs.img'.
Download to address: 0x2000000
Downloading: #################################################
done
Bytes transferred = 10488 (28f8 hex)

## Checking Image at 02000000 ...
   Legacy image found
   Image Name:   partition
   Created:      2019-08-07   2:40:43 UTC
   Image Type:   ARM Linux Standalone Program (uncompressed)
   Data Size:    10424 Bytes = 10.2 KiB
   Load Address: 000e0000
   Entry Point:  000f0000
   Verifying Checksum ... OK
Programing start at: 0x000e0000
write : 100%
done
>
>
>run dr
Using ambarella mac device
TFTP from server 192.168.1.99; our IP address is 192.168.1.108
Download Filename 'romfs-x.squashfs.img'.
Download to address: 0x2000000
Downloading: #################################################
done
Bytes transferred = 2873592 (2bd8f8 hex)

## Checking Image at 02000000 ...
   Legacy image found
   Image Name:   romfs
   Created:      2019-08-07   2:47:31 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2873528 Bytes = 2.7 MiB
   Load Address: 01b80000
   Entry Point:  01fd0000
   Verifying Checksum ... OK
Programing start at: 0x01b80000
SPI probe: 32768 KiB W25Q256FV at 0:1 is now current device
write : 100%
done
>
>
>run pd
Using ambarella mac device
TFTP from server 192.168.1.99; our IP address is 192.168.1.108
Download Filename 'pd-x.squashfs.img'.
Download to address: 0x2000000
Downloading: #################################################
done
Bytes transferred = 84216 (148f8 hex)

## Checking Image at 02000000 ...
   Legacy image found
   Image Name:   pd
   Created:      2019-08-07   2:49:19 UTC
   Image Type:   ARM Linux Standalone Program (uncompressed)
   Data Size:    84152 Bytes = 82.2 KiB
   Load Address: 01880000
   Entry Point:  018a0000
   Verifying Checksum ... OK
Programing start at: 0x01880000
SPI probe: 32768 KiB W25Q256FV at 0:1 is now current device
write : 100%
done
>
>
>run du
Using ambarella mac device
TFTP from server 192.168.1.99; our IP address is 192.168.1.108
Download Filename 'user-x.squashfs.img'.
Download to address: 0x2000000
Downloading: #################################################
done
Bytes transferred = 15362296 (ea68f8 hex)

## Checking Image at 02000000 ...
   Legacy image found
   Image Name:   user
   Created:      2019-08-07   2:47:22 UTC
   Image Type:   ARM Linux Standalone Program (uncompressed)
   Data Size:    15362232 Bytes = 14.7 MiB
   Load Address: 000f0000
   Entry Point:  01000000
   Verifying Checksum ... OK
Programing start at: 0x000f0000
write : 100%
done
>
>
>run dc
Using ambarella mac device
TFTP from server 192.168.1.99; our IP address is 192.168.1.108
Download Filename 'custom-x.squashfs.img'.
Download to address: 0x2000000
Downloading: #################################################
done
Bytes transferred = 751864 (b78f8 hex)

## Checking Image at 02000000 ...
   Legacy image found
   Image Name:   custom
   Created:      2019-08-07   2:49:22 UTC
   Image Type:   ARM Linux Standalone Program (uncompressed)
   Data Size:    751800 Bytes = 734.2 KiB
   Load Address: 018a0000
   Entry Point:  01970000
   Verifying Checksum ... OK
Programing start at: 0x018a0000
SPI probe: 32768 KiB W25Q256FV at 0:1 is now current device
write : 100%
done
>
>
>run dw
Using ambarella mac device
TFTP from server 192.168.1.99; our IP address is 192.168.1.108
Download Filename 'web-x.squashfs.img'.
Download to address: 0x2000000
Downloading: #################################################
done
Bytes transferred = 5064952 (4d48f8 hex)

## Checking Image at 02000000 ...
   Legacy image found
   Image Name:   web
   Created:      2019-08-07   2:46:10 UTC
   Image Type:   ARM Linux Standalone Program (uncompressed)
   Data Size:    5064888 Bytes = 4.8 MiB
   Load Address: 01200000
   Entry Point:  01880000
   Verifying Checksum ... OK
Programing start at: 0x01200000
SPI probe: 32768 KiB W25Q256FV at 0:1 is now current device
write : 100%
done
>
>
>
A couple of things to note :
I almost started off using the older General_IPC-HX5(4)XXX_Eng_N_Stream3_V2.420.0005.0.R.20141205.bin firmware until I noticed that the components used the UBIFS file system, not the Squashfs file system implied by the existing bootloader 'run' commands.
And there are partitions mentioned in the Install task list for which there are no 'run' commands.
I'd speculate that the lack of these may be a consequence of jumping straight to the DH_IPC-HX5X3X-Rhea_MultiLang_NP_Stream3_V2.800.0000010.0.R.190807.bin firmware with no intermediate staps.
I'm going to do a web GUI update to the same version of firmware as I applied using tftp and see if that updates those partitions.
What it will do, though, is update the bootloader, which I deliberately didn't do on the tftp update.


And the result?
A total transformation. It's really smartened up.
The camera is now Dahua branded as a Dahua model with a rich set of new features.
There is a Smart Plan that enables IVS video analysis.
ONVIF works.
And there is a proper set of video parameter settings.
And it now has multiple browser support without needing a plugin.
And plenty more.
A very good result.


Some web GUI screenshots :

upd_1.jpgupd_2.jpgupd_3.jpgupd_4.jpgupd_5.jpgupd_6.jpgupd_7.jpg

Comments, questions, ideas, suggestions welcome.
 
Hi Alastair,

In your poking around, have you gained any insight into the HWID matching that goes on when attempting firmware updates?

I ask wrt the Lorex E891ab, which has a HWID of "IPC-HFW1841EN-PV-0280B-CAYENNE".
(see Lorex E891AB (aka IPC-HFW1841EN-PV))

No matching Dahua firmware found for this (yet), but i did find these for "IPC-HFW3841EN-PV-0280B-CAYENNE" here:
and newer

I know the 0280B part refers to lens variation (vs 0360B and 0600B, etc) and I SUSPECT the 'Cayenne' moniker may be a reference to builds Dahua has provided to certain OEM's like Lorex....

Anyways, i tried setting the cam's HWID environment variable to match the 3841 (s/1/3) in hope it could then take the 3841 fw, but changing that single byte caused the cam not to boot. Once i restored the cam's HWID, it was OK again. Changing the 'devalias' env varible seems to have no effect, as that's just a display string. Without any Lorex firmware as backup, I'm reluctant to simply apply the firmware via tftpd, as I don't have anything known good to replace it with should it not work...

Any ideas regarding the (mis-matched) HWID?
Any way to extract/copy the Lorex firmware from a working unit before mucking about?
 
In your poking around, have you gained any insight into the HWID matching that goes on when attempting firmware updates?
No more than the matching up that occurs between the HWID as defined in the camera environment variable, and the values held in the HWID file of the firmware distribution.

No matching Dahua firmware found for this (yet),
I had a look round the Dahuasecurity download site but didn't see an exact match either.

Any way to extract/copy the Lorex firmware from a working unit before mucking about?
Excluding hardware approaches such as reading the flash chip using a test clip, this depends on what Lorex have left available in the bootloader.
For the subject of the thread starter, the original Lorex serial console provided a root shell, so it's easy enough to copy out the flash partitions.
The device was very open.

After the early Dahua firmware (..10..) was applied, the 'dsh' restricted shell appeared, so I dumped the flash with the memory dump command that still existed in the bootloader.
Then after the newest Dahua firmware (..15..) was applied, the bootloader update removed the memory dump capability, and added lots of encryption and signing, so it ended up quite well locked down.
 
Just hit and trial
Thanks for that - but no matching HWID, so presumably would be rejected :
Code:
{
"hwid" : [
"IPC-HDBW3841R-ZAS:01:02:05:8F:41:00:01:10:01:01:04:320:03:00:00:00:00:01:00:00:200",
"IPC-HDBW3841R-ZS:01:02:05:8F:41:00:01:10:00:00:04:320:00:00:00:00:00:01:00:00:200",
"IPC-HFW3841EP-AS:01:02:02:8F:41:00:01:10:03:01:04:320:03:00:00:00:00:01:00:00:200",
"IPC-HFW3841EP-SA:01:02:02:8F:41:00:01:10:01:00:04:320:00:00:00:00:00:01:00:00:200",
"IPC-HFW3841T-ZAS-27135:01:02:02:8F:41:00:01:10:01:01:04:320:03:00:00:00:00:01:00:00:200",
"IPC-HFW3841T-ZS-27135:01:02:02:8F:41:00:01:10:00:00:04:320:00:00:00:00:00:01:00:00:200",
"IPC-HDW3841TM-AS:01:02:00:8F:41:00:01:10:01:00:04:320:00:00:00:00:00:01:00:00:200",
"IPC-HDW3841EM-AS:01:02:00:8F:41:00:01:10:01:00:04:320:00:00:00:00:00:01:00:00:200",
"IPC-HDW3841T-ZAS-27135:01:02:00:8F:41:00:01:10:01:00:04:320:00:00:00:00:00:01:00:00:200",
"IPC-HDBW3841E-S:01:02:00:8F:41:00:01:10:00:00:04:320:00:00:00:00:00:01:00:00:200",
"IPC-HDBW3841E-AS:01:02:00:8F:41:00:01:10:01:01:04:320:03:00:00:00:00:01:00:00:200",
"IPC-HFW3841EN-PV-0280B-cayenne:01:02:02:8F:41:00:01:10:01:01:04:3E8:00:00:00:04:00:01:00:00:200",
"IPC-HDW3849HP-AS-PV:01:02:00:8F:41:00:01:10:03:03:04:3E8:03:00:00:00:00:01:00:00:200",
"IPC-HFW3849T1P-AS-PV:01:02:02:8F:41:00:01:10:03:03:04:3E8:03:00:00:00:00:01:00:00:200",
"IPC-HDW3841HN-AS-PV:01:02:00:8F:41:00:01:10:03:03:04:3E8:03:00:00:00:00:01:00:00:200",
"IPC-HDW3841HN-AS-PV-CAYENNE:01:02:02:8F:41:00:01:10:01:01:04:3E8:00:00:00:04:00:01:00:00:200"
]
}
 
yes, Ubaid, thanx. I'm aware of that firmware, but reluctant to try applying it, given the discrepancy in the HWID (3841 vs 1841)...
Are you implying this firmware will work on this hardware ? (lorex E891ab) The concern was that if it does NOT work, there's no STOCK Lorex firmware available to go back to...
of course, that's all moot if this IS the firmware provided to Lorex by Dahua for that hardware...

(looks like my response and Alastairs crossed in the interwebs...)
 
  • Like
Reactions: alastairstevenson
Thanks for that - but no matching HWID, so presumably would be rejected :
Code:
{
"hwid" : [
"IPC-HDBW3841R-ZAS:01:02:05:8F:41:00:01:10:01:01:04:320:03:00:00:00:00:01:00:00:200",
"IPC-HDBW3841R-ZS:01:02:05:8F:41:00:01:10:00:00:04:320:00:00:00:00:00:01:00:00:200",
"IPC-HFW3841EP-AS:01:02:02:8F:41:00:01:10:03:01:04:320:03:00:00:00:00:01:00:00:200",
"IPC-HFW3841EP-SA:01:02:02:8F:41:00:01:10:01:00:04:320:00:00:00:00:00:01:00:00:200",
"IPC-HFW3841T-ZAS-27135:01:02:02:8F:41:00:01:10:01:01:04:320:03:00:00:00:00:01:00:00:200",
"IPC-HFW3841T-ZS-27135:01:02:02:8F:41:00:01:10:00:00:04:320:00:00:00:00:00:01:00:00:200",
"IPC-HDW3841TM-AS:01:02:00:8F:41:00:01:10:01:00:04:320:00:00:00:00:00:01:00:00:200",
"IPC-HDW3841EM-AS:01:02:00:8F:41:00:01:10:01:00:04:320:00:00:00:00:00:01:00:00:200",
"IPC-HDW3841T-ZAS-27135:01:02:00:8F:41:00:01:10:01:00:04:320:00:00:00:00:00:01:00:00:200",
"IPC-HDBW3841E-S:01:02:00:8F:41:00:01:10:00:00:04:320:00:00:00:00:00:01:00:00:200",
"IPC-HDBW3841E-AS:01:02:00:8F:41:00:01:10:01:01:04:320:03:00:00:00:00:01:00:00:200",
"IPC-HFW3841EN-PV-0280B-cayenne:01:02:02:8F:41:00:01:10:01:01:04:3E8:00:00:00:04:00:01:00:00:200",
"IPC-HDW3849HP-AS-PV:01:02:00:8F:41:00:01:10:03:03:04:3E8:03:00:00:00:00:01:00:00:200",
"IPC-HFW3849T1P-AS-PV:01:02:02:8F:41:00:01:10:03:03:04:3E8:03:00:00:00:00:01:00:00:200",
"IPC-HDW3841HN-AS-PV:01:02:00:8F:41:00:01:10:03:03:04:3E8:03:00:00:00:00:01:00:00:200",
"IPC-HDW3841HN-AS-PV-CAYENNE:01:02:02:8F:41:00:01:10:01:01:04:3E8:00:00:00:04:00:01:00:00:200"
]
}
i doubt last one IPC-HDW3841HN-AS-PV-CAYENNE:01:02:02:8F:41:00:01:10:01:01:04:3E8:00:00:00:04:00:01:00:00:200"
 
yes, Ubaid, thanx. I'm aware of that firmware, but reluctant to try applying it, given the discrepancy in the HWID (3841 vs 1841)...
Are you implying this firmware will work on this hardware ? (lorex E891ab) The concern was that if it does NOT work, there's no STOCK Lorex firmware available to go back to...
of course, that's all moot if this IS the firmware provided to Lorex by Dahua for that hardware...

(looks like my response and Alastairs crossed in the interwebs...)

you can backup a flash if you can to try hit n trial
 
actually, THIS one was most promising:
"IPC-HFW3841EN-PV-0280B-cayenne:01:02:02:8F:41:00:01:10:01:01:04:3E8:00:00:00:04:00:01:00:00:200",

the HWID matches exactly, other than 3841 vs 1841, but the digits we assume represent specific features do differ from the Lorex E891ab, which lists:

HWID=IPC-HFW1841EN-PV-0280B-CAYENNE:01:02:02:72:2C:00:01:0F:01:01:00:3A5:00:00:00:00:00:01:00:02:200

thanx anyways!
 

Attachments

  • lorex version.PNG
    lorex version.PNG
    25.2 KB · Views: 30
Ok , I got it from you last picture.. its 1am here in Pakistan .. downloading the relevant version now .. also downloading the same version as you showed me on picture..
 
Yes! that looks promising.

i see this in the check.img file:

IPC-HFW1841EN-PV-0280B-CAYENNE:01:02:02:72:2C:00:01:0F:01:01:00:3A5:00:00:00:00:00:01:00:02:200"

will give t a try. thank-you so much. please get some ZZZZ's :)
 

Attachments

  • 1609791175313.png
    1609791175313.png
    24.3 KB · Views: 15
  • Like
Reactions: alastairstevenson
Yes! that looks promising.

i see this in the check.img file:

IPC-HFW1841EN-PV-0280B-CAYENNE:01:02:02:72:2C:00:01:0F:01:01:00:3A5:00:00:00:00:00:01:00:02:200"

will give t a try. thank-you so much. please get some ZZZZ's :)

this one is same as you showed me .. the latest i found is coming next post !!