Any Camera Connect reverse engineering? - page 2 - General Discussion and Assistance - CHDK Forum supplierdeeply
« previous next »
Pages: 1 [2] 3   Go Down

Any Camera Connect reverse engineering?

  • 28 Replies
  • 2918 Views
*

Offline RaduP

  • *****
  • 926
Re: Any Camera Connect reverse engineering?
« Reply #10 on: 23 / December / 2023, 18:23:59 »
Advertisements
Oh, a few more things:


1. Can you check to make really sure you got the IP right for the cameras that won't accept connections?
2. Are they running chdk when you do the tests? If so, can you try without chdk?
3. If all else fails, can you install and try the Canon Camera Connect app, and see if it works?
Logged
*

Offline reyalp

  • ******
  • 14082
Re: Any Camera Connect reverse engineering?
« Reply #11 on: 24 / December / 2023, 04:03:08 »
Quote from: RaduP on 23 / December / 2023, 08:30:10
It's strange that on your G7X at least the port isn't open. Maybe run a portscan on the camera's IP and see if the port is open or not (or if there are other opened ports). I mean, the mobile app must connect somehow to it.
I didn't port scan yet, but packet capture shows the camera sends a bunch of mDNS and SSDP chatter. The normal "computer" connection flow also does this. My impression is the mDNS stuff was used in the computer option to support Mac, but the Mac side support was dropped many MacOS versions ago.

I haven't compared the traffic in detail, but one obvious difference is the SSDP MSEARCH is for "ST: urn:schemas-canon-com:service:MobileConnectedCameraService:1" rather than "upnp:rootdevice" as in the computer case. So I strongly suspect Canon's app previously sent a response for one of those like the "computer" flow does, and at some point they decided the firmware code didn't need to care about it.

Quote
1. Can you check to make really sure you got the IP right for the cameras that won't accept connections?
Yes, I'm very sure:
Code: [Select]
___> c -h=x.x.x.103
initializing command channel
initializing event channel
opening session
connected: Canon PowerShot G7 X, max packet size 0
con 1> dis
___> c -h=x.x.x.103
connect failed: 111 Connection refused
ERROR: connection failed
The first is going through the PC connect flow with my UPnP helper running.
The second is going through the mobile flow.
The "connection refused" is in response to an RST from the camera, as seen in tcpdump.

Additionally, SX710 exhibits the same behavior as G7 X and Elph 130.

Quote
As for the crashes while setting that prop, which PTP command did you use to set it? It must be set with #define PTP_OC_CANON_EOS_SetDevicePropValueEx   0x9110 using a special protocol, not #define PTP_OC_GetDevicePropValue       0x1015
Yes, I was trying to use regular SetDevicePropValue, and had some other bugs in my code  :-[
However, I'm not able to get CANON_EOS_SetDevicePropValueEx to do anything useful, so perhaps you can say more about the special protocol?

Looking at  https://julianschroden.com/post/2023-05-28-controlling-properties-using-ptp-ip-on-canon-eos-cameras/ it appears it should be a simple send data transaction, with 8 bytes of data consisting of two 32 bit values PropertyID, value.

Attempting this results in a General Error (0x2002) response code for values in the range 0-8.

However, looking at the firmware code (sx730 100d around fc151162) it appears to actually expect the parameters in the reverse order (value, PropertyID). This "succeeds" (returning 0x2001) for values I tried in the range 0-8 but has no visible effect on the camera and does not change the returned value of prop 0xd1b0. Edit: this was not entirely correct, it actually expected 3 words, see later post: https://chdk.setepontos.com/index.php?topic=14822.msg150158#msg150158

The fact that 0-8 wouldn't be valid property IDs gives me some confidence my understanding of the order is correct. (edit: Though https://github.com/raduprv/esp32_macro_rail/blob/master/src/macro_slider.cpp#L360C1-L361C41 looks like PropertyID, Value)

Code: [Select]
con 1> !local val = lbuf.new(8) val:set_u32(0,8,ptp.CANON.DPC.EOS_EVFOutputDevice) con:ptp_txn(ptp.CANON.OC.EOS_SetDevicePropValueEx,{data=val})
con 1> dptpgetprop 0xd1b0
DPC: 0xd1b0 CANON.EOS_EVFOutputDevice
datatype: 0x0002 u8
RW: 1
factory: 0x0 0
current: 0x0 0
form: 0 simple

Code: [Select]
___> !printf('ptp.CANON.OC.EOS_SetDevicePropValueEx = 0x%x, ptp.CANON.DPC.EOS_EVFOutputDevice = 0x%x\n',ptp.CANON.OC.EOS_SetDevicePropValueEx, ptp.CANON.DPC.EOS_EVFOutputDevice)
ptp.CANON.OC.EOS_SetDevicePropValueEx = 0x9110, ptp.CANON.DPC.EOS_EVFOutputDevice = 0xd1b0

Quote
2. Are they running chdk when you do the tests? If so, can you try without chdk?
Previous tests were with CHDK, but as expected, behavior is the same without.

Quote
3. If all else fails, can you install and try the Canon Camera Connect app, and see if it works?
Well I've gotten this far without agreeing to any Canon EULAs… ;)
« Last Edit: 25 / December / 2023, 22:08:39 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline RaduP

  • *****
  • 926
Re: Any Camera Connect reverse engineering?
« Reply #12 on: 24 / December / 2023, 06:40:24 »
Ok, I guess it sucks that those two cameras want the pairing magic stuff to happen before allowing connections. It's a good thing newer cameras don't need it.


Anyway, the stuff on the Julian's site isn't complete (for some cameras at least). This is how my code looks like:


For init:
Code: [Select]

      connect_ptpip(config.camera_ip);
      canon_set_property_value(0xd1b0,8);//shoot mode/live view
      canon_set_property_value(0xd11c,0x2);//destination to SD (rather than ram). Not needed for M3 but might be needed for others.
      send_ptp_command_no_arg(0x9114);//SetRemoteMode
      send_ptp_command_no_arg(0x9115);//SetEventMode


To shoot, I do this:
Code: [Select]

  while(send_ptp_command_no_arg(0x9128)==0x2019)//While StartImageCapture returns busy
  {
    delay(100);
    i++;
    if(i>30)
    {
      Serial.println("StartImageCapture still busy after 3 seconds, giving up...");
      break;
    }
  }


  send_ptp_command_no_arg(0x9129);//StopImageCapture


  //if the events buffer gets full, bad things happen (disconnects)
  if(!(cur_shot%5))
  flush_events_buffer();//this just reds from the events connection to empty it


Take a look at this too, it has code to extend the g7x lens: https://github.com/pastudan/ptpip-test/blob/master/test.js Maybe you can send the exact same data sent there and see if it works?


Oh, and did you try that 0xd1b0 prop on other cameras? Did you try with gphoto2 (the command line app)?


« Last Edit: 24 / December / 2023, 06:42:04 by RaduP »
Logged
*

Offline reyalp

  • ******
  • 14082
Re: Any Camera Connect reverse engineering?
« Reply #13 on: 24 / December / 2023, 15:32:14 »
Quote from: RaduP on 24 / December / 2023, 06:40:24
Ok, I guess it sucks that those two cameras want the pairing magic stuff to happen before allowing connections. It's a good thing newer cameras don't need it.
Yes. One thing I might be able to do to completely confirm is have my helper script send a response for urn:schemas-canon-com:service:MobileConnectedCameraService:1, though some work may be needed to figure out the correct response without a working example.

The mobile option has some potential advantages over PC mode even if the pairing stuff is required:
You can use the camera as an AP instead of having a separate access point (though it annoyingly seems to randomize the SSID and key every time), and it doesn't require you to send a GetObjectHandles (putting the camera in black screen PTP transfer mode https://chdk.setepontos.com/index.php?topic=14294.0) or similar to prevent the camera from timing out the network connection after connecting.. Edit: Oops, I forgot made chdkptp automatically work around this, in fact it does sit at the connecting screen until gets one of those, and the screen does go black when it does, and eventually times out with "connection failed" if not.

Quote
Anyway, the stuff on the Julian's site isn't complete (for some cameras at least). This is how my code looks like:


For init:
Code: [Select]

      connect_ptpip(config.camera_ip);
      canon_set_property_value(0xd1b0,8);//shoot mode/live view
      canon_set_property_value(0xd11c,0x2);//destination to SD (rather than ram). Not needed for M3 but might be needed for others.
      send_ptp_command_no_arg(0x9114);//SetRemoteMode
      send_ptp_command_no_arg(0x9115);//SetEventMode
What PTP response code do you get for the set_property_value calls?

Quote
Take a look at this too, it has code to extend the g7x lens: https://github.com/pastudan/ptpip-test/blob/master/test.js Maybe you can send the exact same data sent there and see if it works?
According the description, that's for G7 X mk2, which is an entirely different camera and presumably more similar to other newer models.

Quote
Oh, and did you try that 0xd1b0 prop on other cameras? Did you try with gphoto2 (the command line app)?
Not yet. Is there any visible effect on the camera when you set just that property?

Also interesting, G7 X lists list 0xd1b0 in DevicePropertiesSupported from GetDeviceInfo. Elph130, SX710 and SX730 do not, although at least SX730 does respond with the description I quoted earlier if queried with GetDevicePropDesc. According to the manuals, SX710 and S730 do support remote shooting with app, while Elph130 is strictly photo transfer and geotagging.
« Last Edit: 24 / December / 2023, 16:17:50 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline RaduP

  • *****
  • 926
Re: Any Camera Connect reverse engineering?
« Reply #14 on: 24 / December / 2023, 19:47:15 »
Quote
What PTP response code do you get for the set_property_value calls?
I get 2001 for 0xd1b0 and 2002 for 0xd11c
What do you get?


Quote
Not yet. Is there any visible effect on the camera when you set just that property?
On my camera no, because it's a mirrorless, but on a camera with retractable lenses I think it should pull out the lens.
Maybe you can try the gphoto2 command line client (both as wi-fi and usb) and try to get the cameras to shoot with it. See if it works, and if so maybe log what it sends or read the source code?
Logged
*

Offline reyalp

  • ******
  • 14082
Re: Any Camera Connect reverse engineering?
« Reply #15 on: 24 / December / 2023, 20:14:44 »
Looking at the gphoto2 code, I see they send size,PropertyID, value https://github.com/gphoto/libgphoto2/blob/master/camlibs/ptp2/ptp.c#L4102

Using that on SX730
Code: [Select]
!local val = lbuf.new(12) val:set_u32(0,12,ptp.CANON.DPC.EOS_EVFOutputDevice,8) con:ptp_txn(ptp.CANON.OC.EOS_SetDevicePropValueEx,{data=val})
returns 0x2001 and extends the lens. The display says "use target device"
Sending a value of 0 retracts the lens and prompts to send an image.

So, my reverse engineering was half right: the ID is in the second word of the data phase, but I didn't realize they included the size in the payload. Interesting it accepts sizes that are different from the actual payload 8)

Quote
I get 2001 for 0xd1b0 and 2002 for 0xd11c
What do you get?
When the property id is in the right place, I get 2001 for the 0xd1b0. When it was in the wrong place, I got 2002.

edit:
Some other observations. Cameras without Canon remote support like elph130 and elph180 return Operation Not Supported in response to trying to set 0xd1b0. Unsurprising since EOS_SetDevicePropValueEx isn't in their supported operation list (edit: this may allow detecting in the sig finder, since we identify most PTP handlers)

On SX730, 0xd1b0 works similarly over USB. The values 0 and 8 are reflected in the current value returned by GetDevicePropDesc, others in between are not and do not appear to do anything. On USB, 0 returns to playback mode without prompting to transfer an image.

It looks like to use this, shooting would have to be fully controlled through the API, on wireless, using a CHDK keyboard emulation based "shoot" kills the connection.
« Last Edit: 24 / December / 2023, 20:40:05 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline RaduP

  • *****
  • 926
Re: Any Camera Connect reverse engineering?
« Reply #16 on: 24 / December / 2023, 20:36:42 »
Ok, great! I cheated a bit and just stole the bytecode from that blog, but replaced the properties and session ID. Interestingly, I actually messed up replacing the session ID properly but it still worked.
So now, can you take photos with your SX730?


And how about the G7X?
Logged
*

Offline reyalp

  • ******
  • 14082
Re: Any Camera Connect reverse engineering?
« Reply #17 on: 24 / December / 2023, 21:07:22 »
Quote from: RaduP on 24 / December / 2023, 20:36:42
So now, can you take photos with your SX730?
Yes, connected by wifi, the following switched rec, took two images on SX730, and switched back to play.
Code: [Select]
con 1> !local val = lbuf.new(12) val:set_u32(0,12,ptp.CANON.DPC.EOS_EVFOutputDevice,8) con:ptp_txn(ptp.CANON.OC.EOS_SetDevicePropValueEx,{data=val})
con 1> !con:ptp_txn(0x9114)
con 1> !con:ptp_txn(0x9115)
con 1> !con:ptp_txn(0x9128)
con 1> !con:ptp_txn(0x9129)
con 1> !con:ptp_txn(0x9128)
con 1> !con:ptp_txn(0x9129)
con 1> !local val = lbuf.new(12) val:set_u32(0,12,ptp.CANON.DPC.EOS_EVFOutputDevice,0) con:ptp_txn(ptp.CANON.OC.EOS_SetDevicePropValueEx,{data=val})
Haven't tried G7 X yet, but I suspect it will be similar.
Logged
Don't forget what the H stands for.
*

Offline RaduP

  • *****
  • 926
Re: Any Camera Connect reverse engineering?
« Reply #18 on: 24 / December / 2023, 21:18:55 »
Ok, great. I hope the same is true for the SX710. It's good to know that my code works for other cameras, although I am a bit disappointed that in order to support older Canons I'd have to do the UPNP magic thing... But probably I won't do it, as for extreme macro older cameras are not as good as the 'new' ones.

I hope this new knowledge can be of use to CHDK. If you ever feel like playing with an ESP32 for remote controlling cameras, let me know, maybe we can work together.

Oh, and don't forget, if you want to take many pictures by wifi, you MUST empty the event connection buffer every once in a while or it will disconnect the camera.
Logged
*

Offline reyalp

  • ******
  • 14082
Re: Any Camera Connect reverse engineering?
« Reply #19 on: 25 / December / 2023, 21:20:48 »
Quote from: RaduP on 24 / December / 2023, 21:18:55
Ok, great. I hope the same is true for the SX710.
Turns out, neither G7 X nor SX710 respond to setting 0xd1b0. Response is 0x2001 success, but no effect on the camera, and the value seen by GetDevicePropDesc is unchanged. Same on USB.  :blink:
The rest of the calls in the shooting sequence also have no effect.

One possibility that occurred to me is that it might be due to connecting through the computer option, since AFAIK Canon only supports shooting through the mobile app on these cameras, but FWIW SX730 appears to work the same whether I connect with the computer or mobile option.

I also confirmed SX730 does require the UPnP stuff when connecting through the PC option, so that requirement appears to have only been dropped for mobile.

Quote
I hope this new knowledge can be of use to CHDK.
Definitely improved my understanding of this stuff and provided some additional avenues for exploration. Much appreciated.
Logged
Don't forget what the H stands for.
Pages: 1 [2] 3   Go Up
« previous next »
 

Related Topics