Zosi camera - how to access

[zefie]

I happened to discover the file /app/bin/uuid.txt which appears to contain the device's UUID.

Mine was a variable "UID" in /data/config/SystemCfg.CFG
Of other interest I noticed a connection to amazonaws, when I blocked it, it went to a lenovo server. I ended up blocking all non-LAN traffic to it, since I don't know why or what it is sending.
Probably video data for "cloud services" but I could not find a way to disable that nor do I want my local video stream sent to Zosi's servers. All of this, regarding the connections, is assumption at this point, though.

 

[Jet86]

Of other interest I noticed a connection to amazonaws, when I blocked it, it went to a lenovo server. I ended up blocking all non-LAN traffic to it, since I don't know why or what it is sending.
Probably video data for "cloud services" but I could not find a way to disable that nor do I want my local video stream sent to Zosi's servers. All of this, regarding the connections, is assumption at this point, though.

I also happened to notice one of the files had configuration details for a WeChat account, which seems... interesting, to say the least.

I'll probably do the same (limit connections to only the LAN) - did you do this on device, or in your switch/router etc?

 

[zefie]

I also happened to notice one of the files had configuration details for a WeChat account, which seems... interesting, to say the least.

I'll probably do the same (limit connections to only the LAN) - did you do this on device, or in your switch/router etc?

I did it at the router level. The downfall is that NTP doesn't work, because I haven't found the specific server it is using (nor can I find a way to define it, its not listening to DHCP Option 42).

 

[Jet86]

I did it at the router level. The downfall is that NTP doesn't work, because I haven't found the specific server it is using (nor can I find a way to define it, its not listening to DHCP Option 42).

I'll see if I can find out what NTP server it's using, but could you block all ports except port 123?

 

[zefie]

I'll see if I can find out what NTP server it's using, but could you block all ports except port 123?

Maybe, I went with null/blackhole route, so it blocks all WAN traffic regardless of port or protocol.

Edit: I managed to get it to use my local router NTP, as it seems to respect DHCP Option 42 (NTP Server).
Time zone can be set in /data/config/SystemCfg.CFG (19 is GMT-4 according to /etc/TZ, 18 was GMT-3:30 so perhaps there is a pattern) but it does not seem to respect it in the timestamp, or the date command

Edit 2: How to timezone:
1) Get your /etc/TZ from a linux device, I got mine from OpenWRT, and it was EST5EDT,M3.2.0,M11.1.0 (Note: it does not understand named TZ (eg America/New_York) nor does it properly respect GMT-4)
2) create a file called /overlay/etc/timezone and save your timezone to it, on a single line.
3) Run mkdir -p /overlay/etc/init.d
4) Run cp /etc/init.d/S60ansjeripc /overlay/etc/init.d/S60ansjeripc
5) Edit /overlay/etc/init.d/S60ansjeripc and add the following on a new line after "start)"
export TZ=$(cat /etc/timezone)
cp /etc/timezone /overlay/etc/TZ
6) Run sync
7) Reboot camera

 

[Jet86]

Mine was a variable "UID" in /data/config/SystemCfg.CFG

I'm guessing you have a different model of Zosi camera to me, as mine doesn't have that file, and doesn't even have a /data directory...
The camera I've been messing around with is a Zosi ZG2615. I also have a couple of Zosi ZG2612.

I did it at the router level. The downfall is that NTP doesn't work, because I haven't found the specific server it is using (nor can I find a way to define it, its not listening to DHCP Option 42).

I know you managed to get it to use a different NTP server via DHCP, but just for reference (or for others who come across this thread) on my camera the /config/ntp_param.config file indicates it is using 1.cn.pool.ntp.org for NTP.

Time zone can be set in /data/config/SystemCfg.CFG (19 is GMT-4 according to /etc/TZ, 18 was GMT-3:30 so perhaps there is a pattern) but it does not seem to respect it in the timestamp, or the date command

Edit 2: How to timezone:
1) Get your /etc/TZ from a linux device, I got mine from OpenWRT, and it was EST5EDT,M3.2.0,M11.1.0 (Note: it does not understand named TZ (eg America/New_York) nor does it properly respect GMT-4)
2) create a file called /overlay/etc/timezone and save your timezone to it, on a single line.
3) Run mkdir -p /overlay/etc/init.d
4) Run cp /etc/init.d/S60ansjeripc /overlay/etc/init.d/S60ansjeripc
5) Edit /overlay/etc/init.d/S60ansjeripc and add the following on a new line after "start)"
export TZ=$(cat /etc/timezone)
cp /etc/timezone /overlay/etc/TZ
6) Run sync
7) Reboot camera

Unfortunately, this won't work for my cameras, as there is no /data directory (and therefore no /data/config/SystemCfg.CFG file), no /overlay directory and no /etc/init.d/S60ansjeripc file.

What I have managed to work out so far is the following:

• I can write files into /etc/init.d and these persist across reboots
• I created a file /etc/init.d/S99timezone which successfully overwrites /etc/TZ and successfully sets the timezone (confirmed by writing it back to a log file using cat). However something later in the startup process appears to overwrite /etc/TZ back to GMT-8
• I edited the file /app/start.sh and added some lines at the end which successfully overwrites /etc/TZ and successfully sets the timezone (again confirmed by writing it back to a log file using cat). However something still later in the startup process appears to overwrite /etc/TZ back to GMT-8

So I think the next steps for me are to somehow try and work out what is overwriting the timezone and when, although I'm not sure at this stage how I'm going to do that...

I'm thinking I may be able to still use a script in /etc/init.d or still use the end of /app/start.sh but insert a wait timer.

I may also play around with /etc/inittab and see if I can get it to overwrite /etc/TZ at an appropriate time...

 

[rogueautomata]

An update for anyone following along:

The Good News
I've now managed to change the timezone on the cameras, so that they show the correct time on the timestamp. After gaining access via telnet with the above credentials, you need to edit the single line in /etc/TZ to the timezone you wish to use in POSIX format (using vi). Once you've saved the file, the timestamp on the video feed updates almost immediately.

The Bad News
Unfortunately this does not survive a reboot. It seems that when the camera boots up it must initialise files such as /etc/TZ with pre-determined parameters. Obviously not all files are re-initialised at every boot (network settings such as the camera's IP address survives a reboot), so the question now is whether I (or anyone else) can find how and where the /etc/TZ file is initialised, and whether that can be modified...

A Side Note
A bunch of Zosi apps and documentation refer to needing the device's UUID to perform certain actions, and claim that the UUID should be on a printed sticker on the device (which is not the case for any of my Zosi cameras). In digging around on the camera's filesystem, I happened to discover the file /app/bin/uuid.txt which appears to contain the device's UUID.

On my C190, the UID the apps ask for is in /config/SystemCfg.CFG under "Deviceinfo" as UID. The uuid in /app/bin/uuid.txt isn't it, but the manual states that the UID should end with "111A" if that helps, so maybe look around for an ID like that- mine is 20 characters including the 111A part, so it's a really 16-character ID with 111A appended onto it. I'm guessing a different camera model might use something other than 111A but probably similar, maybe it's a model ID.

 

[Dr.Fiero]

Don't know if it'll make any difference to anyone in terms of hunting down info... But my NEW DVR scans, finds, and reports these Zosi cameras as actually being "Ansjer" ones.
I looked up Ansjer, and they're an OEM for a number of different brands.

 

[mat200]

check the configuration of TP-LINK C300HP-6 hope it might help you.

How does this help @petersmithing ?

 

[kd5mdk]

I also happened to notice one of the files had configuration details for a WeChat account, which seems... interesting, to say the least.

Interesting, but not necessarily nefarious. WeChat in China is beyond WhatsApp in Europe or email+Amazon in the US. Default customer support / payment / communications method.

 

[surfbase]

glad to share I have hacked my ZOSI Camera ZG2323M ... I'm only missing the exact URL to retrieve the video flows!
after my NVR ZR08LL has died, I was expecting to reuse my 6 ZOSI cameras with NX Witness . not easy, but thanks to above details and more from other sources, I was able to enter in the camera.

remind this is link to the ZOSI ZG2323M , it may differs with other models.

First step is to find IP address. Out of the box, never plugged into a NVR, the IPCAM comes with an address 192.168.138.x . My NVR has changed it to 192.168.147.x ... don't ask me why, I have no idea.
Once you have find the ip address of your cameras, with nmap, ipscan, or whatever ip scanner, you can connect to the camera via TELNET (port 23 is open)
# telnet 192.168.138.2
login: root
password: 123456asj or 123456asi
Welcome to HiLinux.
you are in!
The IPC is running Linux Busybox.
the folders are organized like this:
/ (root)
/app : specific for Zosi
/bin : standard busybox
/boot : (empty)
/config : specific for Zosi
/dev
/etc : some specific settings for Zosi network
/font
/home : some Zosi binaries here with extension .g711a
/komod : specific for Zosi
/lib
/mnt
/nfsroot : (empty)
/opt : some Zosi specific
/proc
/res : specific for Zosi
/root: only one script pm_callback
/run
/sbin : standard busybox
/share : (empty)
/sys
/tmp
/usr
/var

If you want to change the IP address, use ZOSI NVR if it works. Then remove the cameras from the NVR and switch it off. use your new NVR to add the Cameras from their IP addres.

Remember my NVR has died, I cannot tweak the cameras anymore with it. So I have decided to update the network configuration in each.
here are the files you need to update to match the new NVR network.
First, take a copy of the original, I'm use to do it by : cp xxxx.yy xxxx.yy.org By doing this, I can always refer to the original if I have a doubt.
Second updates ALL files listed below before rebooting or you can lose network connection to your camera.
1. /app/start.sh : update the lines for Ethernet connection (ifconfig eth0 192.168.0.2) and gateway (route add default gw 192.168.0.1 eth0)
2. /app/switchwifi.sh : update the line for Wireless connection (ifconfig wlan0 192.168.0.102)
3. /config/NetCfgParam.CFG : update the Rj45Info and WifiInfo parameters to reflect the as in /app files . You need to update IPAddr, Gateway, Dns , you shouldn't change NetMask , it should be the same as your local network. 255.255.255.0
4. /etc/hostapd.conf : optional, this is for a wireless Access point on your camera . be sure it does not conflict with any of your local defintion into ssid= . You can change ssid= and wpa_passphrase to something which fits your need.

Note : I did it in case the AP will be activated after reboot, which seems not to be the case with my cameras. In doubt...

5. /etc/resolv.conf : this is for the DNS, replace the value of nameserver by the DNS IP in your local network, like nameserver 192.168.0.1

Note : again I did it in case, even if I don't see clearly which usage it could have from an IP camera. In doubt....

6. /etc/wpa-psk.conf : this is critical to connect the camera to you wifi network. update ssid= with your wifi ssid and update the password psk= with your wifi pass key
check a last time all your network settings and reboot the camera by the command
# reboot
after a while, your camera is visible on your network, if you don't do a mistake. If you have done a mistake in network settings it could be almost impossible to find the IP address or regain access.

ok, the cams are on my (mesh) wifi network. Now it's time to add them to the new NVR.​

a port scan gives a few ports open,
TCP/23 (telnet)
TCP/554 (RTSP)

I did a try to auto discovery via ONVIF protocol without success.
The next option is to give manually the RTSP url of each camera.
According internet sources iSpy for Zosi cameras, Zosi rtsp urls end with one of ch0_0.264 , ucast/11, and more depending on your model. Unfortunately my exact model is not listed (ZG2323M).

At the stage I had to dig into the Zosi setup in the camera to find :
1. userassword
2. exact url
I did find two users, "admin" and "user" into /app/bin/config.xml

• username: admin password: admin
• username: user password: 123456

I did find a tag <url>screenlive</url> and video codec H265 and MP4, audio codec G711A , transfer mode UP with vport 50001 and aport 50002 which I guess stands for vport: video and aport: audio
I did a try with all within NX Witness using rtsp:/admin:admin@192.168.0.2/screenlive :
--> NX witness accepts the camera and add it to the list,but fails to render the video.
--> in NX server log, it says that the RTSP DESCRIBE response is too short. Other said, the url is not good.

another file of interest /app/bin/onvif_config.xml seems promising... but onvif:/admin:admin@192.168.0.2/onvif/device_service does not respond. this is the typical scan on ONVIF protocol I mentionned above.
inside this onvif_config.xml, I have found interesting information:

• forgot <server..> tags, it says running on port 8080, but a quick scan ( netstat -an in the busybox ) shows there is no listener on this port
• you can find the same 2 users as found into config.xml
• followed by <profile> tags in which an interesting <stream_uri> tag contains values mentionned by iSpy
  • ucast/11 for a video encoder H264 1920x1080 with audio encoder G711
  • ucast/12 for a video encoder H264 640x360 with audio encoder G711
• and onvif tags

<scope>onvif:/www.onvif.org/location/country/china</scope>
<scope>onvif:/www.onvif.org/type/video_encoder</scope>
<scope>onvif:/www.onvif.org/name/IP-Camera</scope>
<scope>onvif:/www.onvif.org/hardware/HI3518C</scope>

full of hope, I have tried many rtsp urls without success so far, like

• rtsp:/192.168.0.2/screenlive
• rtsp:/192.168.0.2/ucast/11
• rtsp;/192.168.0.2/ucast/11/screenlive

and more ... none where able to be registered properly with NX Witness, Shinobi, or any other NVR

last piece of information, I have seen the url of another IP camera , onvif compliant. it introduces the uuid in the url like this rtsp:/{ip}/{uuid}/channel0
I did a last try with the uuid of my camera found into /app/bin/uuid.txt
rtsp:/{ip}/{uuid}/screenlive
rtsp:/{ip}/{uuid}/ucast/11
etc
none of them are working.


I wonder if somebody has the right format of the url?
It could allow me to reuse my Zosi cameras. Otherwise I will need to purchase 6 new cameras, and probably not ZOSI, but one officially referenced with NX Witness.

PS: about the TZ issue mentionned in this forum, the boot process launch /app/IPCAMERA.exe whihc overwrite /etc/TZ . captured in the log [APP INFO] [ src/common/TimeProcess.c, Line: 320 ] Save time zone:echo GMT-8 > /etc/TZ

 

[surfbase]

glad to share I have hacked my ZOSI Camera ZG2323M ... I'm only missing the exact URL to retrieve the video flows!
after my NVR ZR08LL has died, I was expecting to reuse my 6 ZOSI cameras with NX Witness . not easy, but thanks to above details and more from other sources, I was able to enter in the camera.

remind this is link to the ZOSI ZG2323M , it may differs with other models.

First step is to find IP address. Out of the box, never plugged into a NVR, the IPCAM comes with an address 192.168.138.x . My NVR has changed it to 192.168.147.x ... don't ask me why, I have no idea.
Once you have find the ip address of your cameras, with nmap, ipscan, or whatever ip scanner, you can connect to the camera via TELNET (port 23 is open)
# telnet 192.168.138.2
login: root
password: 123456asj or 123456asi
Welcome to HiLinux.
you are in!
The IPC is running Linux Busybox.
the folders are organized like this:
/ (root)
/app : specific for Zosi
/bin : standard busybox
/boot : (empty)
/config : specific for Zosi
/dev
/etc : some specific settings for Zosi network
/font
/home : some Zosi binaries here with extension .g711a
/komod : specific for Zosi
/lib
/mnt
/nfsroot : (empty)
/opt : some Zosi specific
/proc
/res : specific for Zosi
/root: only one script pm_callback
/run
/sbin : standard busybox
/share : (empty)
/sys
/tmp
/usr
/var

If you want to change the IP address, use ZOSI NVR if it works. Then remove the cameras from the NVR and switch it off. use your new NVR to add the Cameras from their IP addres.

Remember my NVR has died, I cannot tweak the cameras anymore with it. So I have decided to update the network configuration in each.
here are the files you need to update to match the new NVR network.
First, take a copy of the original, I'm use to do it by : cp xxxx.yy xxxx.yy.org By doing this, I can always refer to the original if I have a doubt.
Second updates ALL files listed below before rebooting or you can lose network connection to your camera.
1. /app/start.sh : update the lines for Ethernet connection (ifconfig eth0 192.168.0.2) and gateway (route add default gw 192.168.0.1 eth0)
2. /app/switchwifi.sh : update the line for Wireless connection (ifconfig wlan0 192.168.0.102)
3. /config/NetCfgParam.CFG : update the Rj45Info and WifiInfo parameters to reflect the as in /app files . You need to update IPAddr, Gateway, Dns , you shouldn't change NetMask , it should be the same as your local network. 255.255.255.0
4. /etc/hostapd.conf : optional, this is for a wireless Access point on your camera . be sure it does not conflict with any of your local defintion into ssid= . You can change ssid= and wpa_passphrase to something which fits your need.

5. /etc/resolv.conf : this is for the DNS, replace the value of nameserver by the DNS IP in your local network, like nameserver 192.168.0.1

6. /etc/wpa-psk.conf : this is critical to connect the camera to you wifi network. update ssid= with your wifi ssid and update the password psk= with your wifi pass key
check a last time all your network settings and reboot the camera by the command
# reboot
after a while, your camera is visible on your network, if you don't do a mistake. If you have done a mistake in network settings it could be almost impossible to find the IP address or regain access.

ok, the cams are on my (mesh) wifi network. Now it's time to add them to the new NVR.​

a port scan gives a few ports open,
TCP/23 (telnet)
TCP/554 (RTSP)

I did a try to auto discovery via ONVIF protocol without success.
The next option is to give manually the RTSP url of each camera.
According internet sources iSpy for Zosi cameras, Zosi rtsp urls end with one of ch0_0.264 , ucast/11, and more depending on your model. Unfortunately my exact model is not listed (ZG2323M).

At the stage I had to dig into the Zosi setup in the camera to find :
1. userassword
2. exact url
I did find two users, "admin" and "user" into /app/bin/config.xml

• username: admin password: admin
• username: user password: 123456

I did find a tag <url>screenlive</url> and video codec H265 and MP4, audio codec G711A , transfer mode UP with vport 50001 and aport 50002 which I guess stands for vport: video and aport: audio
I did a try with all within NX Witness using rtsp:/admin:admin@192.168.0.2/screenlive :
--> NX witness accepts the camera and add it to the list,but fails to render the video.
--> in NX server log, it says that the RTSP DESCRIBE response is too short. Other said, the url is not good.

another file of interest /app/bin/onvif_config.xml seems promising... but onvif:/admin:admin@192.168.0.2/onvif/device_service does not respond. this is the typical scan on ONVIF protocol I mentionned above.
inside this onvif_config.xml, I have found interesting information:

• forgot <server..> tags, it says running on port 8080, but a quick scan ( netstat -an in the busybox ) shows there is no listener on this port
• you can find the same 2 users as found into config.xml
• followed by <profile> tags in which an interesting <stream_uri> tag contains values mentionned by iSpy
  • ucast/11 for a video encoder H264 1920x1080 with audio encoder G711
  • ucast/12 for a video encoder H264 640x360 with audio encoder G711
• and onvif tags

<scope>onvif:/www.onvif.org/location/country/china</scope>
<scope>onvif:/www.onvif.org/type/video_encoder</scope>
<scope>onvif:/www.onvif.org/name/IP-Camera</scope>
<scope>onvif:/www.onvif.org/hardware/HI3518C</scope>

full of hope, I have tried many rtsp urls without success so far, like

• rtsp:/192.168.0.2/screenlive
• rtsp:/192.168.0.2/ucast/11
• rtsp;/192.168.0.2/ucast/11/screenlive

and more ... none where able to be registered properly with NX Witness, Shinobi, or any other NVR

last piece of information, I have seen the url of another IP camera , onvif compliant. it introduces the uuid in the url like this rtsp:/{ip}/{uuid}/channel0
I did a last try with the uuid of my camera found into /app/bin/uuid.txt
rtsp:/{ip}/{uuid}/screenlive
rtsp:/{ip}/{uuid}/ucast/11
etc
none of them are working.


I wonder if somebody has the right format of the url? * SOLVED * rtsp:/admin:admin@192.168.0.2/video1 and video2
It could allow me to reuse my Zosi cameras. Otherwise I will need to purchase 6 new cameras, and probably not ZOSI, but one officially referenced with NX Witness.

PS: about the TZ issue mentionned in this forum, the boot process launch /app/IPCAMERA.exe whihc overwrite /etc/TZ . captured in the log [APP INFO] [ src/common/TimeProcess.c, Line: 320 ] Save time zone:echo GMT-8 > /etc/TZ

I have found the url by analyzing the binary files. It has cost me one camera, due to the trace I put, the telnet daemon did not restart at reboot. the RTSP flows are working but I can"t change anything on this cam now.

So, for ZOSI IPCam ZG2323M the url format is rtsp:/{ip address}/video1 for hi res channel , video2 for low res

Next steps for me,
1. solving the time reset at boot time
2. fixing the time zone

I hope the above will help somebody. Being the bad event of his/her NVR hard failure, or willing to move to another NVR.

As a reminder, my devices list was:

• NVR ZOSI ALL IN ONE ZR08LL
• 8 IP Cameras ZOSI ZG2323M connected via private ZOSI wifi

Before the crash of my NVR during an upgrade, I was looking at using my home Wifi (Mesh) because of many losses of connection from the farest cameras.
Now, the new setup uses my home Wifi for the cameras, keeping all of them connected.
The devices and softwares are now :

• Raspberri Pi5 running NX server, connected to the LAN via Ethernet
• 8 IP Cameras ZOSI ZG2323M connected to the NX server via Wifi Mesh
• NX Witness clients running on PC / MAC / Linux
• NX Witness mobile app.

 

[surfbase]

I'm guessing you have a different model of Zosi camera to me, as mine doesn't have that file, and doesn't even have a /data directory...
The camera I've been messing around with is a Zosi ZG2615. I also have a couple of Zosi ZG2612.



I know you managed to get it to use a different NTP server via DHCP, but just for reference (or for others who come across this thread) on my camera the /config/ntp_param.config file indicates it is using 1.cn.pool.ntp.org for NTP.



Unfortunately, this won't work for my cameras, as there is no /data directory (and therefore no /data/config/SystemCfg.CFG file), no /overlay directory and no /etc/init.d/S60ansjeripc file.

What I have managed to work out so far is the following:

• I can write files into /etc/init.d and these persist across reboots
• I created a file /etc/init.d/S99timezone which successfully overwrites /etc/TZ and successfully sets the timezone (confirmed by writing it back to a log file using cat). However something later in the startup process appears to overwrite /etc/TZ back to GMT-8
• I edited the file /app/start.sh and added some lines at the end which successfully overwrites /etc/TZ and successfully sets the timezone (again confirmed by writing it back to a log file using cat). However something still later in the startup process appears to overwrite /etc/TZ back to GMT-8

So I think the next steps for me are to somehow try and work out what is overwriting the timezone and when, although I'm not sure at this stage how I'm going to do that...

I'm thinking I may be able to still use a script in /etc/init.d or still use the end of /app/start.sh but insert a wait timer.

I may also play around with /etc/inittab and see if I can get it to overwrite /etc/TZ at an appropriate time...

It's overwritten by the last jobs launched in background by start.sh, to fix it give a delay before applying the change at end of start.sh. Personnally I put a "sleep 30" to wait for 30 seconds before patching /etc/TZ.

I have prepared also the camera to use ntp server from internet, fortunately the ntpd program exists in /usr/sbin.
if you are interested, you need ;
/etc/resolv.conf with a valid DNS address.
/etc/ntp.conf with valid time server
/etc/TZ with your timezone

define the address of your local DNS relay in your local LAN, or use 1.1.1.1 Cloudflare or 8.8.8.8 Google or any other from your ISP. The only constraint is to give IP address not name.
sample content of /etc/resolv.conf :

nameserver 192.168.0.1

sample content of /etc/ntp.conf :

server time1.google.com
server time2.google.com
server  127.0.0.1
fudge   127.0.0.1 stratum 10
# Drift file.
driftfile /etc/ntp/drift

create /etc/ntp/ directory:
mkdir /etc/ntp

create the empty file drift in it:
touch /etc/ntp/drift

set /etc/TZ with your timezone, mine is GMT-2

test your setup by

ntpd -q
date

if it works, you should see your exact date and time.
if date is ok but not the time, it's probably a mistake in /etc/TZ value.
if date is not ok, check and fix the 3 files: /etc/resolv.conf, /etc/ntp.conf and /etc/TZ

once you are satisfied, apply the below patch at end of the script /app/start.sh around the block of code launching jobs in the background.
(you don't need the lines starting with "#patch", there are guidelines for the explanation )

# patch start
# setup date thru ntp 
echo "GMT-2" > /etc/TZ
/usr/sbin/ntpd -q
# patch end

export PATH=$PATH:/app/bin
cd /app/bin
./applauncher &
sleep 1
./NewIPCam.exe &

# patch start
# /etc/TZ is overwritten by NewIPCam.exe, so redo setup later (sleep 30s )
sleep 30
echo "GMT-2" > /etc/TZ
/usr/sbin/ntpd
# patch end

I'm doing it twice because I want to avoid recording video before the date is updated. As the program NewIPCam.exe rewrite /etc/TZ, I do it again, after 30 seconds.

note:
The first call to ntpd fixes the date but quit immediately with option '-q'
The second call launches the ntpd daemon: ntpd will keep your time synchronized with the internet time servers you have defined in /etc/ntpd.conf