Wireless investigations

ahull

Re: Wireless investigations

« Reply #10 on: 25 / November / 2013, 11:53:13 »

Advertisements

I've not had a chance to look at any of this for ages, but finally this evening I took a few minutes to compare the discoveries above with the romdump of the old Ixus Wireless (SD430) and they do seem to have quite a lot in common, at least superficially.

First of all If I look for ComWi I see a couple of likely looking .c files

Code: [Select]

 grep ComWi PRIMARY.BIN.SD430.strings.txt 
 24270c ComWirelessService.c
 2459dc ComWiPass.c

We look to have a similar RegComEventProc arangement.

Code: [Select]

 grep RegComEventProc PRIMARY.BIN.SD430.strings.txt 
 34e6e4 RegComEventProc

We have similar "Pairing" stuff.

Code: [Select]

 grep PAIR PRIMARY.BIN.SD430.strings.txt 
 3699f0 DONGLEPAIRINGDATA
 369a18 CAMERAPAIRINGDATA

The dongle in question above is the rather odd WA-1 wireless adapter which was included with the camera, which sadly I don't have, and which is not strictly necessary as you can set it up to use an access point. More details in the manual - page 18 - Page 99.

..and we also have some sort of wireless related state machine...

Code: [Select]

 grep -B4 -A4 -i "State Machine" PRIMARY.BIN.SD430.strings.txt 
 2cc570 Tmp Key Data Buffer.
 2ccb9c [WPA] Required Essid session is existed
 2ccbc8 [WPA] Different Essid session is existed
 2ccbf4 Session Information Buffer.
 2cd0d0 State Machine Panic!!
 2cdb39 [Notice] WPA Supplicant Module Terminated
 2cdcd4 [ Running Normal Process(UI:0x%04X) ]
 2cdcfc Essid [%s] is MicFailure HoldOff Time
 2cdd24 [wpaUserMsgHandler]WPA_FATAL

Edit: It also seems to have a separate network log...

Code: [Select]

 3a10a4 Network log

I'll do a bit more digging when I next get a chance. Meantime I think I need to set up an XP VM to grab some USB setup traffic. Time to blow the dust off my old XP CD.... assuming I can find it.

« Last Edit: 25 / November / 2013, 12:21:24 by ahull »

Logged

ahull

Re: Wireless investigations

« Reply #11 on: 02 / December / 2013, 02:50:45 »

A slightly tedious development, it seems that the latest Windows (XP?) version of the Canon tools do not let you configure the Ixus Wireless (SD430) camera for use with a wireless access point, however the Mac OSX version does.

Needless to say, in order to find this out, I had to install a VM, with Windows XP (free and legal version available here), and jump through the necessary hoops to get it all working on Linux, then install .Net 3.5, Silverlight and all of the dependencies needed to then install the Canon utilities.

On the plus side, I can now sniff USB traffic from the XP host to the camera... I just can't sniff the setup traffic I was hoping for.

Until I can get access to OSX, I am kind of dead in the water (unless anybody here has any suggestions).

It is entirely possible that the utilities for Windows 7 or Windows 8 will allow configuration of the AP settings, but I don't know.

Does anybody have this working with this particular camera, or can anybody with a later model verify that their software is compatible with the Ixus/IXY wireless - SD430. If someone can verify it works with later versions of Windoze, I'll pursue that route, otherwise I suspect I need to borrow a Mac.

« Last Edit: 02 / December / 2013, 02:55:24 by ahull »

Logged

ahull

Re: Wireless investigations

« Reply #12 on: 02 / December / 2013, 05:50:08 »

I know this is old ground, but how easy would it be to access a camera shell using chdkptp?

There are a bunch of debug functions and some sort of internal wireless test menu I would like to play with..

Also is there any documentation regarding how to figure out how to call things directly, namely this lot?

Code: [Select]

ffa4f5f4 StartDiscovery
ffa4f604 ChangeWirelessSetting
ffa4f61c StopWirelessWithUSBMode
ffa4f634 StartWirelessWithUSBMode
ffa4f650 StopWirelessService
ffa4f664 StartWirelessService
ffa4f67c DisconnectIPService
ffa4f690 ConnectIPService
ffa4f6a4 RefreshUSBMode
ffa4f6b4 SetUSBToDCPMode
ffa4f6fc SetWirelessInfo
ffa4f70c NotifyDisconnectPictBridge
ffa4f728 NotifyConnectPictBridge
ffa4f740 EnableNotificationPTP
ffa4f758 DisableNotificationPTP
ffa4f770 SetUSBToPTPMode
ffa4f818 Force Quit PTP Mode
ffa4fa98 WaitTransferComplete

Logged

reyalp

11924

Re: Wireless investigations

« Reply #13 on: 02 / December / 2013, 15:49:01 »

Quote from: ahull on 02 / December / 2013, 05:50:08

I know this is old ground, but how easy would it be to access a camera shell using chdkptp?

I don't know any way to send input to the camera shell without using the UART. This ought to be possible, but will take some reverse engineering to figure out. It should be simpler on the vxworks because the driver architecture is documented, something similar to console log hack might be pretty easy.

Quote

There are a bunch of debug functions and some sort of internal wireless test menu I would like to play with..

Also is there any documentation regarding how to figure out how to call things directly, namely this lot?

Code: [Select]
ffa4f5f4 StartDiscovery ffa4f604 ChangeWirelessSetting ffa4f61c StopWirelessWithUSBMode ffa4f634 StartWirelessWithUSBMode ffa4f650 StopWirelessService ffa4f664 StartWirelessService ffa4f67c DisconnectIPService ffa4f690 ConnectIPService ffa4f6a4 RefreshUSBMode ffa4f6b4 SetUSBToDCPMode ffa4f6fc SetWirelessInfo ffa4f70c NotifyDisconnectPictBridge ffa4f728 NotifyConnectPictBridge ffa4f740 EnableNotificationPTP ffa4f758 DisableNotificationPTP ffa4f770 SetUSBToPTPMode ffa4f818 Force Quit PTP Mode ffa4fa98 WaitTransferComplete

Many of these are eventprocs you could call with call_event_proc over chdkptp, but on elph130 the ones that configure network settings require UART console input to enter things like the SSID, password etc.

The other thing to watch out for is that (as I noted in earlier posts) having a USB PTP connection active affects the behavior of the wireless stuff, because PTP/IP uses some of the same code.

I haven't made much progress since my last post, I still haven't found a way to start up the wireless stuff without going through the Canon UI on the camera or having a USB connection active.

Logged

Don't forget what the H stands for.

ahull

Re: Wireless investigations

« Reply #14 on: 03 / December / 2013, 00:25:56 »

Thanks... useful information.

It seems to me therefore that if we want to be able to control and configure wireless via chdk, then we either need some way to emulate the serial input, or figure out how and where the camera stores this information, so we can manipulate it directly.

Both of these directions look as though they would be rewarding in other ways. If I can find the time this week, I will take a look at them, I may need some assistance however, so be prepared for a barrage of questions

.

EDIT: Note to self... serial port in VxWorks take the form of /tyCx looking through the strings for the SD430 I see the following likely looking strings..

3d28 gfff/tyCo/
c894 /tyCo/0

This article on serial port (and stdin/stdout) redirection might also be of interest.

EDIT: This may also be of interest..

« Last Edit: 03 / December / 2013, 02:12:56 by ahull »

Logged

reyalp

11924

Re: Wireless investigations

« Reply #15 on: 03 / December / 2013, 01:38:00 »

Quote from: ahull on 03 / December / 2013, 00:25:56

It seems to me therefore that if we want to be able to control and configure wireless via chdk, then we either need some way to emulate the serial input, or figure out how and where the camera stores this information, so we can manipulate it directly.

For the elph130, my hope is to (initially at least) just connections already configured with the canon UI. So you could just activate stored connection #1, #2 etc. On modern cameras, these can be set up without any special software, so it would be a fairly usable solution.

I have found where the saved connections are stored in RAM (via the PairingDataOutput function), it might be possible modify these at run time.

The eventprocs that read connection info from the console generally fill structures that are passed to lower level functions, so another option would be to reverse engineer those and fill them out ourselves. But having a way to feed input to the canon console would be useful for a lot of other stuff.

edit:
an example of an eventproc that gets settings from the console on elph130 is join_network FF07D984

« Last Edit: 03 / December / 2013, 01:51:51 by reyalp »

Logged

Don't forget what the H stands for.

ahull

Re: Wireless investigations

« Reply #16 on: 03 / December / 2013, 09:48:25 »

More serial related SD430 brain dump... some interesting strings..

Code: [Select]

   11a30 UartDriver.c
  11ba8 UartSio
 2820b4 DeleteVcomUart
 2820c4 CreateVcomUart
 28220c VcomUart
 6e9337 Quarta
 7e1288 UART loopback switch ON...
 7e12a8 UART loopback switch OFF...

Code: [Select]

  1c948 LvComp.c
 282084 VCOMM
 2820b4 DeleteVcomUart
 2820c4 CreateVcomUart
 28220c VcomUart

 3a0c70 loop
 434fc6 SOFTWARE_LOOPBACK
 435a0b LOOPBACK

Logged

ahull

Re: Wireless investigations

« Reply #17 on: 03 / December / 2013, 12:37:55 »

For perhaps no good reason that springs to mind, I decided to see what strings the Ixus Wireless SD430 and Ixus 140 (Elph 130) had in common, not expecting there to be very many.

To my surprise, given the difference in ages of the two cameras, I (with the help of "grep" of course) came up with a list in excess of 4000 (I did remove quite a lot of junk, but by no means all of it).

Perhaps unsurprisingly quite a few "wireless" related strings match too.

For example...

Code: [Select]

WIC_CRYPTO_OFF
WIC_CRYPTO_ON
WIC_ERROR
WIC_INVPARM
WIC_INVSTAT
WIC_NOTSUP
WIC_OK
WIC_PRIVACY_ON
WIC_SET_AUTHMODE
WIC_SET_CIPHER
WIC_SET_ESSID
WIC_SET_GPCIPHER
WIC_SET_MODE
WIC_SET_RANGE

Note: There are quite a few wireless strings that differ too obviously.

I have attached the whole list for your amusement.

common-sorted-uniq.txt (44.32 kB - downloaded 6 times.)

« Last Edit: 03 / December / 2013, 12:54:35 by ahull »

Logged

ahull

Re: Wireless investigations

« Reply #18 on: 03 / December / 2013, 12:58:03 »

There are quite a few similar Serial console - UART references in both too..

Code: [Select]

$ grep -i "uart" PRIMARY.BIN.Ixus140.strings 
A/uartr.req
UartLog
RedirectUART.c
StartRedirectUART
StopRedirectUART
StartRedirectUART Failed ExitTask
startRedirectUARTTask
UART loopback switch ON...
UART loopback switch OFF...

$ grep -i "uart" PRIMARY.BIN.SD430.txt 
UartDriver.c
UartSio
DeleteVcomUart
CreateVcomUart
VcomUart
Quarta
UART loopback switch ON...
UART loopback switch OFF...

Logged

ahull

Re: Wireless investigations

« Reply #19 on: 04 / December / 2013, 08:02:15 »

Useful hint for VxWorks (it pays dividends to read the manual sometimes)...

File descriptors.

In UNIX and Windows, fds are unique to each process. In VxWorks, fds are global entities, accessible by any task, except for standard input, standard output, and standard error (0, 1, and 2), which can be task specific.

.. the way I read this, if we can find out the file descriptors we can interact with the internal processes...

Furthermore we have already demonstrated that we can read the serial port fd (and I have just confirmed this on the IxusWireless SD430), with some test code based on previous work here and here..

Demo code below, opens the serial port (fds 8 in my test) ( code is mainly my rambling comments)..

Code: [Select]

--
-- Fun with native function calls - http://chdk.wikia.com/wiki/Lua/Lua_Reference/Native_Function_Calls
-- Mainly tinkering and brain dumps... but with the ultimate objectives of 
-- A) Control of the VxWorks default root shell redirected from the serial port
-- B) Accessing those functions which currently are probably hidden behind that shell, but are needed to setup wireless.
--

FIOBAUDRATE=4 -- vxworks IOCTL number, found on google

-- function addresses from stubs_entry.S

-- a530 values
-- fptr_open=0xffec8b34
-- fptr_ioctl=0xffec8630
-- fptr_close=0xffec84f0

-- SD430 values
-- fptr_open=0xffc1aef0
-- fptr_ioctl=0xffc1a9ec
-- fptr_close=0xffc1a8ac
--

-- Test routine, defines the pointers, and attempt to excersise the serial port on /tyCo/0
fptr_open=0xffc1aef0
fptr_ioctl=0xffc1a9ec
fptr_close=0xffc1a8ac

-- open the file console device r/w
console=call_func_ptr(fptr_open,"/tyCo/0",2,0)
print('open returned file handle',console) -- >= 0 indicates open works
if console < 0 then
  error('open failed')
end
-- call the ioctl
status=call_func_ptr(fptr_ioctl,console,FIOBAUDRATE,9600)
print('ioctl returned',status) -- 0 probably means success
-- close the console
call_func_ptr(fptr_close,console)

-- Example from Chris Stubbs --  http://chris-stubbs.co.uk/wp/?author=1
--    fd=call_func_ptr(0xffec8b34,”/tyCo/0″,0,0) –fptr_open (Opens the UART on fd)
--    print(“fd:”,fd) –fd>0 if the UART was opened successfuly
--    status=call_func_ptr(0xffec8630,fd,4,600) –fptr_ioctl(4=FIOBAUDRATE,600=baud)
--    status=call_func_ptr(0xffec8630,fd,3,0) –FIOSETOPTIONS,3=OPT_RAW,0=OFF (Stops VxWorks messing with null bytes and line returns)
--    print(“status:”,status) –0 probably means success
--    call_func_ptr(0xffec84f0,fd) –Closes down fd

-- Basic I/O functions - These would need to be identified per camera, or an algorithm defined to find them based on offset and size.
-- For now we just grep through the stubs_entry*.S for the camera.  

-- Valid VxWorks 
--creat( )
--Creates a file.
--delete( )
--Deletes a file.
--open( )
--Opens a file. (Optionally, creates a file.)
--close( )
--Closes a file.
--read( )
--Reads a previously created or opened file.
--write( )
--Writes to a previously created or opened file.
--ioctl( )
--Performs special control functions on files.

« Last Edit: 04 / December / 2013, 08:05:59 by ahull »

Logged