News:

Registered a URL and setup a forum as the IPCam stuff really needed its own site vs my irregular blog posts about IPCam hacking at http://www.computersolutions.cn/blog

Author Topic: GET and POST  (Read 19224 times)

  • No avatar
  • *****
August 04, 2011, 01:47:20 pm
it's not really well coded as I never learned C (but Cobol, Fortran, you name them Dinos) but it's working

added to the post with .exe

  • *****
August 04, 2011, 02:47:38 pm
I fixed one compile error and added the help for -s and --settings (source attached). However, this program as well as the shell procedure in the wiki, produce a checksum that differs from what the camera itself produced. I haven't figured it out yet, but this process isn't going to work reliably until we figure it out.

The original params.bin that I obtained via backup has a checksum of 00003c04 (see below) but the forstarn program yields a checksum of 00003c05 (see below), as does the shell procedure in the wiki (see post above for August 02, 2011, 06:36:00 pm). Look at this same post and you'll also see that when that one byte was changed, the camera and the shell procedure computed the same checksum - 00003c00. So, our formula sometimes, but not always yields the same checksum as the camera!

Obviously, if the camera computes 00003c04, we must also compute 00003c04 or a restore will fail. Some elusive difference exits between the camera's checksum formula and ours.

Code: [Select]
ecomer@pennyroyal:~/src/w_fostarn$ hd -n 128 params.bin
00000000  bd 9a 0c 44 04 3c 00 00  e8 14 00 00 30 30 42 38  |...D.<......00B8|
00000010  30 30 30 30 36 38 44 32  00 15 16 02 24 00 00 04  |000068D2....$...|
00000020  12 30 30 32 62 78 61 66  00 00 00 00 00 00 00 00  |.002bxaf........|
00000030  00 00 00 00 00 00 61 64  6d 69 6e 00 00 00 00 00  |......admin.....|
00000040  00 00 00 31 32 33 34 35  36 00 00 00 00 00 00 00  |...123456.......|
00000050  02 76 69 73 69 74 6f 72  00 00 00 00 00 00 76 69  |.visitor......vi|
00000060  73 69 74 6f 72 00 00 00  00 00 00 01 00 00 00 00  |sitor...........|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000080
ecomer@pennyroyal:~/src/w_fostarn$ cc fostarn.c ^C
ecomer@pennyroyal:~/src/w_fostarn$ ./a.out -s params.bin
***      REMEMBER! ALWAYS KEEP A BACKUP OF YOUR ORIGINAL FIRMWARE       ***
*** I AM NOT RESPONSIBLE FOR YOU TURNING YOUR CAMERA INTO A PAPERWEIGHT ***
***              USE OF THIS SOFTWARE IS AT YOUR OWN RISK               ***
***                                                                     ***
***           If you don't agree to this, press 'Ctrl+C' now.           ***

File_CRC: 0X3C05
ecomer@pennyroyal:~/src/w_fostarn$ hd -n 128 params.bin
00000000  bd 9a 0c 44 05 3c 00 00  e8 14 00 00 30 30 42 38  |...D.<......00B8|
00000010  30 30 30 30 36 38 44 32  00 15 16 02 24 00 00 04  |000068D2....$...|
00000020  12 30 30 32 62 78 61 66  00 00 00 00 00 00 00 00  |.002bxaf........|
00000030  00 00 00 00 00 00 61 64  6d 69 6e 00 00 00 00 00  |......admin.....|
00000040  00 00 00 31 32 33 34 35  36 00 00 00 00 00 00 00  |...123456.......|
00000050  02 76 69 73 69 74 6f 72  00 00 00 00 00 00 76 69  |.visitor......vi|
00000060  73 69 74 6f 72 00 00 00  00 00 00 01 00 00 00 00  |sitor...........|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000080
ecomer@pennyroyal:~/src/w_fostarn$

  • *****
August 04, 2011, 02:55:19 pm
UPDATE: I tried restoring the modified params.bin e/w the 00003c05 checksum. I assumed that it would fail. It was accepted! Very, very odd! If the camera computed 00003c04 then why would it accept 00003c05??

The good news is that the program will work.

  • No avatar
  • *****
August 04, 2011, 03:22:27 pm
Hi,

I only tested it with 2 setting files I saved from my cam. I nulled the existing checksum and let the program insert a new one. In both cases it was calculated correctly.

Interesting, didn't get a compiler error ... maybe different gcc versions as allways

edit: no, forgot to reinsert the permissions for *nix
« Last Edit: August 04, 2011, 03:43:36 pm by schufti »

  • *****
August 04, 2011, 04:35:03 pm
I downloaded a params.bin from a camera that got wiped a while back. I used a hex editor to edit the binary data such that the DDNS server info matched a known good camera. Next I corrected the checksum. I then restored the modified params.bin into the wiped camera. The result was that the DDNS access messages on the console change from cannot find to cannot access. I suspect that the password from the other camera is no good for this camera. Since the password is all numeric it may be computed from the factory defined alias. Another mystery to solve.

I am curious about other cameras that utilize a factory DDNS. Any ideas?

  • No avatar
  • *****
August 05, 2011, 02:49:11 am
Hi,
in general I wouldn't mind not using the factory ddns, I allways missed the option to disable it.
If I want ddns, I use an account of my liking...

Do the factory ddns and manufactorer of the cam match? Or is it ddns from different company?
Did you bear in mind that even the ddns username (ID) is stored in the parameters? It would be blank now in your wiped cam if you didn't hack it in ...

One would have to sniff the packets to see how the "login" is working. They all seem to call some .cgi for login. I don't think the pw is stored in the parameters (if they use a pw at all). If so, they either have a "secret" hardcoded pw in the camera binary or they compute the pw from the mac, serial, user or ??? On my apexis even the username seemed to be not related to the serial.

  • *****
August 05, 2011, 01:01:32 pm
What interests me the most about the built-in factory DDNS is wondering how it works. The EasyN camera uses a different DDNS than does the WansView. The DDNS addresses and password is stored in the settings area (params.bin). If you do a DEL -all, this gets destroyed and cannot be restored except through the restore params process, which lead me here. I posted some WansView output in the forum at:
http://www.openipcam.com/forum/index.php/topic,173.0.html

My Easyn camera came preconfigured to use a DDNS entry assigned to its alias of hrnc – hrnc.easyb.hk. Using tcpdump, the traffic during bootup is:
Code: [Select]
69 23.556997 00:a8:f7:00:a7:7a Broadcast ARP Who has 192.168.1.1?  Tell 192.168.1.126
70 24.087185 192.168.1.126 224.0.0.251 MDNS Standard query ANY ipcamera_00A8F700A77A.local, "QU" question ANY ipcamera(id:00A8F700A77A, alias:IPCAM)._http._tcp.local, "QU" question
71 24.336967 192.168.1.126 224.0.0.251 MDNS Standard query ANY ipcamera_00A8F700A77A.local, "QM" question ANY ipcamera(id:00A8F700A77A, alias:IPCAM)._http._tcp.local, "QM" question
72 24.590219 192.168.1.126 224.0.0.251 MDNS Standard query ANY ipcamera_00A8F700A77A.local, "QM" question ANY ipcamera(id:00A8F700A77A, alias:IPCAM)._http._tcp.local, "QM" question
73 24.837984 192.168.1.126 224.0.0.251 MDNS Standard query response A, cache flush 192.168.1.126 PTR, cache flush ipcamera_00A8F700A77A.local SRV, cache flush 0 0 81 ipcamera_00A8F700A77A.local TXT, cache flush PTR _http._tcp.local PTR ipcamera(id:00A8F700A77A, alias:IPCAM)._http._tcp.local
74 25.837320 192.168.1.126 224.0.0.251 MDNS Standard query response A, cache flush 192.168.1.126 PTR, cache flush ipcamera_00A8F700A77A.local SRV, cache flush 0 0 81 ipcamera_00A8F700A77A.local TXT, cache flush PTR _http._tcp.local PTR ipcamera(id:00A8F700A77A, alias:IPCAM)._http._tcp.local
151 27.837260 192.168.1.126 224.0.0.251 MDNS Standard query response A, cache flush 192.168.1.126 PTR, cache flush ipcamera_00A8F700A77A.local SRV, cache flush 0 0 81 ipcamera_00A8F700A77A.local TXT, cache flush PTR _http._tcp.local PTR ipcamera(id:00A8F700A77A, alias:IPCAM)._http._tcp.local

This is the console output during the same time period:
Code: [Select]
ecomer@pennyroyal:~$ foscom /dev/ttyUSB0
foscom v1.7

port is        : /dev/ttyUSB0
flowcontrol    : none
baudrate is    : 115200
parity is      : none
databits are   : 8
escape is      : Ctl-a
noinit is      : no
noreset is     : no
send_cmd is    : xms
receive_cmd is : rz -vv

Terminal ready



W90P745 Boot Loader [ Version 1.1 $Revision: 1 $ ] Rebuilt on May 11 2010
Memory Size is 0x1000000 Bytes, Flash Size is 0x400000 Bytes
Board designed by Winbond
Hardware support provided at Winbond
Copyright (c) Winbond Limited 2001 - 2006. All rights reserved.
Boot Loader Configuration:

MAC Address         : 00:A8:F7:00:A7:7A
IP Address          : 0.0.0.0
DHCP Client         : Enabled
CACHE               : Enabled
BL buffer base      : 0x00300000
BL buffer size      : 0x00100000
Baud Rate           : -1
USB Interface       : Disabled
Serial Number       : 0xFFFFFFFF


For help on the available commands type 'h'

Press ESC to enter debug mode ......
Cache enabled!
Processing image 1 ...
Processing image 2 ...
Processing image 3 ...
Processing image 4 ...
Processing image 5 ...
Processing image 6 ...
Processing image 7 ...
Unzip image 7 ...
Executing image 7 ...
Linux version 2.4.20-uc0 (root@maverick-linux) (gcc version 3.0) #1453 һ 12�� 6 08:30:46 CST 2010
Processor: Winbond W90N745 revision 1
Architecture: W90N745
On node 0 totalpages: 4096
zone(0): 0 pages.
zone(1): 4096 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/rom0 rw
Calibrating delay loop... 39.83 BogoMIPS
Memory: 16MB = 16MB total
Memory: 14320KB available (1481K code, 299K data, 40K init)
Dentry cache hash table entries: 2048 (order: 2, 16384 bytes)
Inode cache hash table entries: 1024 (order: 1, 8192 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
PTZ Driver has been installed successfully.
Winbond W90N745 Serial driver version 1.0 (2005-08-15) with no serial options enabled
ttyS00 at 0xfff80000 (irq = 9) is a W90N745
Winbond W90N7451 Serial driver version 1.0 (2005-08-15) with no serial options enabled
ttyS00 at 0xfff80100 (irq = 10) is a W90N7451
I2C Bus Driver has been installed successfully.
Blkmem copyright 1998,1999 D. Jeff Dionne
Blkmem copyright 1998 Kenneth Albanowski
Blkmem 1 disk images:
0: 7F0E0000-7F1EBFFF [VIRTUAL 7F0E0000-7F1EBFFF] (RO)
S29GL032N Flash Detected
01 eth0 initial ok!
which:0
PPP generic driver version 2.4.2
Linux video capture interface: v1.00
Winbond Audio Driver v1.0 Initialization successfully.
usb.c: registered new driver hub
add a static ohci host controller device
: USB OHCI at membase 0xfff05000, IRQ 15
hc_alloc_ohci
usb-ohci.c: AMD756 erratum 4 workaround
hc_reset
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 2 ports detected
usb.c: registered new driver audio
audio.c: v1.0.0:USB Audio Class driver
usb.c: registered new driver serial
usbserial.c: USB Serial Driver core v1.4

 _____     ____    _    ____
|__  /   _|  _ \  / \  / ___|
  / / | | | | | |/ _ \ \___ \
 / /| |_| | |_| / ___ \ ___) |
/____\__, |____/_/   \_\____/
     |___/
ZD1211B - version 2.24.0.0
usb.c: registered new driver zd1211b
main_usb.c: VIA Networking Wireless LAN USB Driver 1.20.04
usb.c: registered new driver vntwusb
usb.c: registered new driver rt73
dvm usb cam driver 0.0.0.1 by Maverick Gao in 2010-8-3
usb.c: registered new driver dvm
dvm usb cam driver 0.1 for sonix288 by Maverick Gao in 2009-4-20
usb.c: registered new driver dvm usb cam driver for sonix288
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 2048)
VFS: Mounted root (romfs filesystem) readonly.
Freeing init memory: 40K
BINFMT_FLAT: bad magic/rev (0x74202d74, need 0x4)
BINFMT_FLAT: bad magic/rev (0x74202d74, need 0x4)
Shell invoked to run file: /bin/init
Command: mount -t proc none /proc
Command: mount -t ramfs none /usr
Command: mount -t ramfs none /swap
Command: mount -t ramfs none /var/run
Command: mount -t ramfs none /etc
Command: mount -t ramfs none /flash
Command: mount -t ramfs none /home
Command: mount -t ramfs none /tmp
Command: mkdir /tmp/run
Command: camera&
[8]
Command: sh

Sash command shell (version 1.1.1)
/> no support
hub.c: connect-debounce failed, port 1 disabled
new USB device :80fb4004-fed740
hub.c: new USB device 1, assigned address 2
VIA Networking Wireless LAN USB Driver Ver. 1.20.04
Copyright (c) 2004 VIA Networking Technologies, Inc.
vntwusb_init--->eth1 initial ok!
insmod VNTWUSB SUCESSFUL...
new USB device :80fb4204-fed740
hub.c: new USB device 2, assigned address 3
probing sonix288 usb camera ...
dvm camera registered as video0
p1[7]:1,j 3,config->bNumInterfaces:4
usbaudio: device 3 audiocontrol interface 2 has 1 input and 0 output AudioStreaming interfaces
usbaudio: valid input sample rate 16000
usbaudio: device 3 interface 3 altsetting 1: format 0x00000010 sratelo 16000 sratehi 16000 attributes 0x01
usbaudio: valid input sample rate 48000
usbaudio: device 3 interface 3 altsetting 2: format 0x00000010 sratelo 48000 sratehi 48000 attributes 0x01
usbaudio: registered dsp 14,35
usbaudio: warning: found 1 of 0 logical channels.
usbaudio: assuming the channel found is the master channel (got a Philips camera?). Should be fine.
usbaudio: registered mixer 14,32
usb_audio_parsecontrol: usb_audio_state at 00ff3ba0
sw version is 4.22.2.36
aw version is 4.5.3.45

Wait for auto-negotiation complete...OK
100MB - FULL
video0 opened
1
1
1
1
1
1
unknown command
do_zoom_stop: write error 5
__pthread_initial_thread_bos:440000
manage pid:14
2
2
2
2
2
2
audio_dev.state not AU_STATE_RECORDING
wb_audio_start_record
inet_sr.c INET_rinput 321
action===1
options==33
inet_sr.c INET_setroute 75
*args===255.255.255.255
*args===netmask
*args===eth0
inet_sr.c INET_rinput 321
action===1
options==33
inet_sr.c INET_setroute 75
*args===default
*args===gw
*args===eth0
user.easyn.hk 808 /ip/
p2p login svr is 76.73.102.34:30000
p2p svr login ok 0 0 0
ntpc adjust ok
Aug  5 09:05:49 2011 bonjour: mDNSPlatformRawTime went backwards by 268513929 ticks; setting correction factor to -97061834
psd_ddns.c: update psd ddns ok
bonjour callback: service registered

Of particular interest are the lines near the end. The IP "76.73.102.34" doesn't show up in the tcpdump:
user.easyn.hk 808 /ip/
p2p login svr is 76.73.102.34:30000
p2p svr login ok 0 0 0
ntpc adjust ok
Aug  5 09:05:49 2011 bonjour: mDNSPlatformRawTime went backwards by 268513929 ticks; setting correction factor to -97061834
psd_ddns.c: update psd ddns ok
bonjour callback: service registered




Quote
schufti

In general I wouldn't mind not using the factory ddns, I always missed the option to disable it.
If I want ddns, I use an account of my liking...

Do the factory ddns and manufacturer of the cam match? Or is it ddns from different company?
Did you bear in mind that even the ddns username (ID) is stored in the parameters? It would be blank now in your wiped cam if you didn't hack it in ...

One would have to sniff the packets to see how the "login" is working. They all seem to call some .cgi for login. I don't think the pw is stored in the parameters (if they use a pw at all). If so, they either have a "secret" hard-coded pw in the camera binary or they compute the pw from the mac, serial, user or  On my apexis even the username seemed to be not related to the serial.
« Last Edit: August 05, 2011, 01:12:55 pm by celem »

  • *****
August 05, 2011, 02:13:53 pm
And, what also interests me is how the factory DDNS makes setup easier for newbies. With both the EasyN and the WansView cameras, the IP is delivered out-of-the-box as set to static and written on the bottom of the camera. In the case of WansView it is set to 192.168.0.178:80. In the case of EasyN it is set to 192.168.1.126:81. Also on the bottom of each camera is the URL via factory DDNS. In the case of the WansView it is their DDNS server prefixed with the alias, i.e., HY001103.nwsvr.com. In the case of the EasyN it is their DDNS server prefixed with some code, probably computed from the MAC, i.e., hrnc.easyn.hk. WansView hides the DDNS URL and password in the settings area while EasyN marks the URL and password on the camera bottom.

Thus the approach is, IF your LAN is compatible with the default static IP, then it is plug-and-play. Plug it in, the camera automatically updates the factory DDNS and now entering the URL printed on the camera bottom will access the camera. The DDNS is even updated with the correct port info, should you change the port. The fly in this ointment comes when your LAN mismatches the factory chosen static IP. Most routers belong to a LAN of either  192.168.0.xxx or 192.168.1.xxx. If your LAN is 0 while the camera is 1, then easy setup becomes difficult setup. Using DHCP would probably be better because discovering the current IP is easier than the 192.168.0.xxx/192.168.1.xxx mismatch. Of course, regardless of the solution, the user still must know how to open up and/or port forward the router.
« Last Edit: August 05, 2011, 02:16:13 pm by celem »

  • No avatar
  • *****
August 05, 2011, 06:02:52 pm
hmm, maybe because the catch phrase "ours are even more complicated to setup" isn't really catchy?. And once you bought and found out ....

  • *****
August 09, 2011, 02:46:48 pm
UPDATE:

On a whim, I contacted WansView's technical support with this request:
Quote
发送时间: 2011-08-05  03:47:11
收件人: service
抄送:
主题: NC541/W
By doing a factory settings restore, the DDNS 002bxaf.nwsvr.com is no longer functional. Do you have a method to restore functionality?

After several days of back and forth, due to the time difference, the quite helpful technician restored the factory DDNS functionality to my camera. Afterwards I asked her what she did and she said that she made changes in both my camera and on the nwsvr.com DDNS server.

In examining my camera after her "fix", I detected two obvious changes: (1) she switched the camera from DHCP to static address; (2) she set the factory DDNS' password in the settings area.

I have no idea how she changed the factory DDNS' password in the settings area while accessing over the web from China. Possibly she accessed a secret, factory backdoor? I do know that she used the Windows OCX/IE functionality to access. Possibly the IPCam902.ocx has hidden functionality.

I have tried to figure out the relationship of the the factory DDNS' password to either the alias or the ID. I have tried crc and checksums of each and cannot come up with an obvious relationship. In one email, she sent the attached image which appears to indicate that the relationship is between alias and ID.

« Last Edit: August 09, 2011, 02:54:29 pm by celem »

  • *****
August 09, 2011, 04:12:47 pm
Schufti.

Your uploaded webui "nc541w-0.0.4.18-webui.zip" is identified as version 0.0.4.18 yet it appears to be modified from 0.0.4.17. Possibly you renumbered 0.0.4.17 to 0.0.4.18 just to differentiate it. Are you aware that WansView released an official webui version 0.0.4.18? The real WansView version  0.0.4.18 incorporates a mobile login. It is also rather broken. When it boots lots error messages about missing image files are spit out, and the pan/tilt doesn't work correctly in push mode, moving just a bit for each click. In Microsoft IE mode pan/tilt works fine (I suspect that little QA checking is done in push mode).

  • No avatar
  • *****
August 09, 2011, 05:19:35 pm
Hi,
yes I changed the numbering just to set it apart from the latest official.

Maybe she just dl'd the settings, edited them and re-up'd them via the Webinterface.
No need for a hidden interface ....

I don't think it's related to either serial or alias. I'm sure the ddns user is different to both and the pw is depending on the user (002bxaf in your case) btw: did it change?

Maybe she didn't know how the original is calculated, so had to set a new one in the cam and on the server.

So, first thing to do: backup settings!  (I fortunately did it by dumping the whole rom in the first place, and only after doing a del -all realized how lucky I was...)

schufti

  • *****
August 09, 2011, 07:04:51 pm
I just successfully updated the factory ddns on another camera with:

Code: [Select]
http://192.168.1.178/set_smarteye_factory_params.cgi?se_ddns_pwd=10918810&se_ddns_user=002cbxb&se_ddns_name=002cbxb.nwsvr.com&mid=smarteye&pid-BSeries&se_ddns_port=80&se_ddns_interval=18000&se_ddns_svr=www.nwsvr.com
This must be how the technical support representative did it.

By the way, I give WansView high marks for the tech support. The person that I got was knowledgeable, helpful and persistent. What more can you ask for?

P.S.: The password is made up since I don't know how to compute it. Since the password is bogus, the console outputs:

Code: [Select]
update_smarteye_ddns: update ddns error: ERRIDS_SERVER_NOAUTH
« Last Edit: August 09, 2011, 07:09:51 pm by celem »