Wireless investigations - page 4 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 2 3 [4] 5 6 7 8   Go Down

Wireless investigations

  • 72 Replies
  • 34982 Views
*

Offline ahull

  • *****
  • 634
Re: Wireless investigations
« Reply #30 on: 07 / December / 2013, 09:45:00 »
Advertisements
Quote from: reyalp on 07 / December / 2013, 02:33:54
Quote from: ahull on 07 / December / 2013, 00:29:22
I presumed that CHDK already used read() and write(), but I also assumed that CHDK limits its access to the SD card only (files on A/)
There are several different IO APIs available. open()/read()/write() are the lowest level. Above that are Open()/Read()/Write() which wrap the corresponding lower level functions with some FsIoNotify stuff. The other main one we use is the _Fut functions, which act roughly like C stdio: fopen(), fread() etc. These automatically take care of things like the uncached memory. I believe the Fut functions are limited to A/, not sure about the Open() etc.

I'll have a play with Open() etc and the _FUT APIs too..

Quote
Quote
I am also assuming that stdin stdout and stderr for lua are entirely separate entities from stdin stdout and stderr on the VxTask that is running chdk, is this the case?
They aren't implemented in CHDK Lua, the standard file handles are created closed.

Good to know, thanks.

Quote
Quote
Since one of my objectives is to try to talk to the OS console without using the serial port I may also try tracking down the existing console buffers and see if I can inject data into, and read from them. Any thoughts on this would be appreciated.
There are several console and uart related tasks, but I haven't looked at them closely.

I'm currently taking a quick run through the VxWorks Programmers Guide. looking for things that might be of interest. I suspect I may be rewarded by gaining an understanding the interprocess messaging system. 
Logged
*

Offline ahull

  • *****
  • 634
Re: Wireless investigations
« Reply #31 on: 08 / December / 2013, 06:01:13 »
I did a little more probing around with the Ixus Wireless SD430 this afternoon.

As well http:// it seems the Ixus Wireless implements the VxWorks ftpLib - there are a large number of the associated strings in the ROM. This would make sense for quick and easy implementation of camera to camera transfers.

More details of the lib here..

If I ever manage to get a valid IP on the darned thing, I suspect this is going to be one of my first hacking targets.

I fired up Kismet and did a bit of network sniffing to see what the camera does when you ask it to pair..

If I ask it to connect to a WA-1 adapter, I get this response...

INFO: Detected new probe network "WA-1-000060950", BSSID 00:00:85:7D:8F:16, encryption no, channel 0, 11.00 mbit

If I look in the romdump I find the WA-1..  string in a couple of locations..

Code: [Select]
WA-1-000060950
0.0.0.0
255.255.0.0
WA-1
Dongle
WA-1-000060950
0.0.0.0
255.255.0.0
WA-1
Dongle
WA-1-000060950
0.0.0.0
255.255.0.0
WA-1
Dongle
WA-1-000060950
0.0.0.0
255.255.0.0
WA-1
Dongle


Ver.004.003
Canon DIGITAL IXUS WIRELESS
WA-1-000060950

I see no specific mention of the BSSID (but there are a number of other SSID references)
Code: [Select]
SSID
ESSID is so long %s
--- 1.2.2.5 set ESSID (return WIC_INVSTAT) ---
--- 1.2.2.6 get ESSID (return WIC_INVSTAT) ---
--- 1.2.3.1 Current BSSID (return WIC_INVSTAT) ---
--- 1.2.2.1 Initial ESSID = [(NULL)] (return WIC_OK) ---
--- 1.2.2.2 set ESSID = [My Essid] (return WIC_OK) ---
--- 1.2.2.3(1) set ESSID = [12345678901234567890123456789012] (return WIC_OK) ---
--- 1.2.2.3(2) set ESSID = [321098765432109876543210987654321] (return WIC_OK) ---
--- 1.2.3.x set BSSID = 00:01:0a:0b:0c:0d (return WIC_OK) ---
--- 1.2.3.3 set BSSID = 0f:ee:dd:cc:bb:aa:11 (return WIC_OK) ---
--- 1.2.3.3 set BSSID = ff:ff:ff:ff:ff:ff (return WIC_OK) ---
--- 1.2.2.4 set ESSID = %s (return WIC_OK) ---
--- 1.2.2.5 set ESSID = %s (return WIC_INVSTAT) ---
--- 1.2.3.2 get cur BSSID (return WIC_OK) ---
[wt] ESSID length error %s (len=%d)
Error WIC_SET_BSSID
NULL_ESSID
WIC_SET_ESSID
[dispatch] *** WRONG WIPASSID ***
        WiPASSID: %02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X
SSID=Wireless Parameter Test #0
    [Role] [WiPASSID]                       [SvcCap] [Adh/Inf] [Auth] [Crypt]
BSSID=%02x:%02x:%02x:%02x:%02x:%02x
ESSID
ESSID
ESSID
ESSID
ESSID
ESSID
ESSID
ESSID

« Last Edit: 10 / December / 2013, 00:55:41 by ahull »
Logged
*

Offline ahull

  • *****
  • 634
Re: Wireless investigations
« Reply #32 on: 08 / December / 2013, 06:41:51 »
Alternatively if I use the camera Setup menu instead  to connect to a "Computer" - no mention of whether this is a Mac or PC, I get this sort of response in Kismet..

Code: [Select]
INFO: Detected new ad-hoc network "WirelessParamAutoSetup", BSSID 02:28:48:D8:1C:D8, encryption yes, channel 5, 11.00 mbit

INFO: Detected new ad-hoc network "WirelessParamAutoSetup", BSSID 02:29:59:53:2D:53, encryption yes, channel 5, 11.00 mbit

EDIT: If only I had my RasPi with me I could probably start making a stab at emulating the WA-1, as it is however it looks like I am going to have to drill in to that ad-hoc network response.
« Last Edit: 10 / December / 2013, 00:52:14 by ahull »
Logged
*

Offline ahull

  • *****
  • 634
Re: Wireless investigations
« Reply #33 on: 10 / December / 2013, 06:31:43 »
FWIW Uart redirection in DryOs looks pretty simple -- http://chdk.setepontos.com/index.php?topic=8040.0
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: Wireless investigations
« Reply #34 on: 10 / December / 2013, 18:17:32 »
Quote from: ahull on 10 / December / 2013, 06:31:43
FWIW Uart redirection in DryOs looks pretty simple -- http://chdk.setepontos.com/index.php?topic=8040.0
It is, but only for output. The OpenConsole and CloseConsole calls are misleading in that example, the output is the same without them.

For VxWorks, this forgotten patch could be a basis for some kind of console IO redirection.
I'm working on a finsig_vxworks patch to find the routines used in the boot.c part.

Pipes were mentioned before, it looks like the related libraries are missing (only checked the ixus30 firmware, the libraries are only included in the debug firmware, not the main one).
Logged
*

Offline reyalp

  • ******
  • 14082
Re: Wireless investigations
« Reply #35 on: 10 / December / 2013, 23:22:23 »
Quote from: ahull on 10 / December / 2013, 06:31:43
FWIW Uart redirection in DryOs looks pretty simple -- http://chdk.setepontos.com/index.php?topic=8040.0
Yes, I use this quite frequently http://chdk.wikia.com/wiki/Debugging#UART_redirection_.28DryOS.29

That only allows redirecting output though.
Logged
Don't forget what the H stands for.
*

Offline ahull

  • *****
  • 634
Re: Wireless investigations
« Reply #36 on: 11 / December / 2013, 08:43:40 »
Quote from: srsa_4c on 10 / December / 2013, 18:17:32
Quote from: ahull on 10 / December / 2013, 06:31:43
FWIW Uart redirection in DryOs looks pretty simple -- http://chdk.setepontos.com/index.php?topic=8040.0
It is, but only for output. The OpenConsole and CloseConsole calls are misleading in that example, the output is the same without them.

For VxWorks, this forgotten patch could be a basis for some kind of console IO redirection.
I'm working on a finsig_vxworks patch to find the routines used in the boot.c part.

Pipes were mentioned before, it looks like the related libraries are missing (only checked the ixus30 firmware, the libraries are only included in the debug firmware, not the main one).

In the SD430, there are some references to pipes, and it could be that partial support is built in. i.e. pre-configures pipes may exist, but the routines to create new ones may not.. I haven't dug any further.

I see the following strings in my Ixus Wireless SD430 firmware dump...
Code: [Select]
/pipe/id%03d%c
pipe0
pipe1
wpipe0
wpipe1
cat: write error: Broken pipe

Logged
*

Offline Hardware_Hacker

  • ****
  • 322
Re: Wireless investigations
« Reply #37 on: 23 / December / 2013, 22:15:45 »
Hi All,

Demo of PeNetwork Manager connecting to a Wi-Fi Ixus 240.

Note that a PAIR (cameras #1 #2) of  Ixus 240's will Inter-Connect very easily
and then transfer files from #1 to #2 and/or #2 to 1.

The main "Demo" points:-

1/ Much easier "Wi-Fi Camera" Network Managment.

2/ No Installation is required.

3/ Reliably Runs in Xp, Win-7, Win-8, Win-Blue and Win-PE versions.

4/ Win-Xp PE is recommended as everything required for CHDK Wi-Fi Development
   will Simply, Reliably and Repeatably, run from a [Xp-PE style] CdRom in a RAM Drive.
   
5/ The LibUSB Files, etc., will need to be manualy added to the Win-Xp PE.

6/ Legacy and Serial cameras can also be supported by manualy adding UsbScan.sys, SerialScan.sys
   and TWO Canon PtP-Dll's to the Win-Xp PE. The Cameras will then become a Wia/Twain "Scanner".

7/ Legacy (Serial) cameras can also be connected by Canons Legacy Remote Software in Win-Xp PE.

8/ The "Other" Canon Legacy cameras can be used in PtP Mode via LibUSB if desired/supported.

Ref #1:-

http://chdk.setepontos.com/index.php?topic=10724.msg105584#msg105584

 reyalp's Wireless investigations #0 << on: 23/September/2013 >>

"If you had control of your own UPnP "control point", this could probably be simplified."

"The connection process contains a GUID and name, but these don't appear to need to be the same as what windows used when the connection was set up."

"If you had control of your own UPnP "control point", this could probably be simplified."

Ref #2:-

PeNetwork Manager 0.58.1 by Holger Kotsch

http://holger.winbuilder.net/

Note for Ixus 140:-

a/ very similar to non Wi-Fi Ixus 115 camera.

Notes for Ixus 240:-

a/ very similar to Wi-Fi Ixus 140 camera i.e. "Wi-Fi Rom Code".

b/ very similar to Wi-Fi Ixus 125 camera i.e. "CHDK Rom Code".

c/ very similar to TouchScreen Ixus 310 camera i.e. "CHDK Rom Code".

Ref #3:-

"Other" Legacy cameras, Wia/Twain, "Scanner" & UsbScan.sys archive on request.

Ref #4:-

Canons Legacy Remote Software and SerialScan.sys stuff is not in my archive.   

H-H
« Last Edit: 23 / December / 2013, 22:17:58 by Hardware_Hacker »
Logged
*

Offline reyalp

  • ******
  • 14082
Re: Wireless investigations
« Reply #38 on: 24 / December / 2013, 00:50:01 »
Hi H-H,

I'm afraid I don't understand how PeNetwork Manager will help us. My problem is getting the camera in a state where it will accept PTP/IP connections, without starting the normal PTP/IP UI manually on the camera.

Thanks to srsa's console work, I've made a bit of progress.

Using http://chdk.setepontos.com/index.php?topic=11029.msg108239#msg108239
I was able to get the camera to connect to a network specified from lua script. It obtains an IP and is pingable, but so far I have not been able to get it to accept PTP/IP commands.

I used the following
Code: [Select]
=return call_event_proc('RegComEventProc')
=call_event_proc_task('NellConnect')
=return cam_con_gets()
ESSID:
=return cam_con_puts('ssid of my AP\n')
=return cam_con_gets()
ssid of my AP
ConnectionType( 0:Infra 1:adhoc )
Select->
=return cam_con_puts('0\n')
=return cam_con_gets()
0
SecurityType:
0: NONE SECURITY
1: WEP
2: WPAPSK/TKIP
3: WPAPSK/AES
4: WPA2PSK/TKIP
5: WPA2PSK/AES
Select->
=return cam_con_puts('2\n')
=return cam_con_gets()
2
NetworkKey:
=return cam_con_puts('*****\n')
=return cam_con_gets()
*****
Addressing( 0:dhcp 1:autoIP 2:manual )
Select->'
=return cam_con_puts('0\n')
At this point I assume one could use socket functions to make your own transport, but it would really be much more convenient to be able to use the existing PTP stuff...

edit:
After running the above, dryshell ifconfig -a shows the expected network settings

I tried the startCameraServiceProvide eventproc thinking it might start PTP/IP, but it didn't seem to.

edit:
Initial post was missing call_event_proc('RegComEventProc')
« Last Edit: 24 / December / 2013, 02:05:03 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 14082
Re: Wireless investigations
« Reply #39 on: 24 / December / 2013, 02:59:19 »
I converted the above to a standalone script, to avoid conflicts with USB and PTP/IP. This allows the camera to connect to an AP and respond to ping while in record mode.

Still haven't gotten PTP/IP working.

edit:
Adding
evproc('SelectFunc_Create')
evproc('RegPTPIPCmd')
evproc('ConnectPtpIPService',0)
causes the camera to listen on the PTP/IP port, but I haven't been able to establish a connection.

Running nmap on the camera in this state crashed it.
« Last Edit: 24 / December / 2013, 03:24:51 by reyalp »
Logged
Don't forget what the H stands for.
Pages: 1 2 3 [4] 5 6 7 8   Go Up
« previous next »
 

Related Topics