CHDK PTP interface - page 124 - General Discussion and Assistance - CHDK Forum  
« previous next »
Pages: 1 ... 119 120 121 122 123 [124] 125   Go Down

CHDK PTP interface

  • 1241 Replies
  • 491348 Views
*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #1230 on: 07 / February / 2022, 17:08:53 »
Advertisements
Quote from: reyalp on 06 / February / 2022, 19:13:30
Interesting Canon issued a fix for https://chdk.setepontos.com/index.php?topic=13872.0 and left this ;)
No CVE - no headache, I guess. They did make a step toward securing this backdoor, so current models are not in "danger". Or at least publicly not.
Logged
*

Offline coon

  • *
  • 1
Re: CHDK PTP interface
« Reply #1231 on: 07 / February / 2022, 17:16:04 »
Hello, I am working on a Magic Lantern port for EOS RP and I am also doing some investigations on PTP. I have added these PTP codes to ptpcam recently and I am happy they are helping.

@srsa_4c nice findings about the execute event proc inner workings! RP does not register PTP_OC_CANON_ExecuteEventProc 0x9052 function by default. However, the decompiled code tells that PTP_OC_CANON_InitiateEventProc0 0x9050 and PTP_OC_CANON_InitiateEventProc1 0x905c do register the function, as you already mentioned but I don't know what the difference of them is. Both functions do call the same subroutine with the same arguments. The only difference is, that some some buffer on the stack is initialized with 1 or 0. I wasn't brave enough to call these functions on camera. Have you already tried this? Do you know what the difference between the functions is?

However, I've tried to register PTP_OC_CANON_ExecuteEventProc 0x9052 manually, which worked but the camera crashed when trying to call a function, so I think the initate functions do some necessary initialization to make it work properly.

I also don't know what the difference between PTP_OC_CANON_TerminateEventProc_051 0x9051 and PTP_OC_CANON_TerminateEventProc_05D 0x905d is. Those are probably the counterparts for the initiate pairs.
« Last Edit: 07 / February / 2022, 17:17:40 by coon »
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #1232 on: 07 / February / 2022, 17:37:52 »
Quote from: coon on 07 / February / 2022, 17:16:04
the decompiled code tells that PTP_OC_CANON_InitiateEventProc0 0x9050 and PTP_OC_CANON_InitiateEventProc1 0x905c do register the function, as you already mentioned but I don't know what the difference of them is. Both functions do call the same subroutine with the same arguments. The only difference is, that some some buffer on the stack is initialized with 1 or 0. I wasn't brave enough to call these functions on camera. Have you already tried this? Do you know what the difference between the functions is?
No, I have not tried going after the changes they made to the registration function(s). I've seen that some magic sentences are involved (I'd prefer them not be published as is) and 0x9050/0x905c now has a data phase. Before DIGIC 8, the 0x9050/0x905c handlers were one and the same (as far as i've seen).

Quote
However, I've tried to register PTP_OC_CANON_ExecuteEventProc 0x9052 manually, which worked but the camera crashed when trying to call a function, so I think the initate functions do some necessary initialization to make it work properly.
If that is so then they really did put in some effort. Perhaps those CVEs were the motivation.
Quote
I also don't know what the difference between PTP_OC_CANON_TerminateEventProc_051 0x9051 and PTP_OC_CANON_TerminateEventProc_05D 0x905d is. Those are probably the counterparts for the initiate pairs.
Yes, they again used to be equal. They are still equal in sx740.
Logged
*

Offline reyalp

  • ******
  • 14082
Re: CHDK PTP interface
« Reply #1233 on: 08 / February / 2022, 02:21:39 »
A few observations:
1) The patch has been applied in https://github.com/petabyt/sequoia-ptpy, so is no longer required

2) As expected, these operations work over wifi (tested on elph130)

3) The long arg handling appears to fail with multiple long args (tested on elph130 and elph180). If I do

./demo.py Printf S'Hello %s' S'World'

The UART output is
Code: [Select]
Hello Hello %s
So the first argument gets passed twice. My chdkptp implementation based on srsa_4c's behaves the same (in fact, I hadn't tried demo.py until I ran into this)

Using chdkptp =call_event_proc("Printf", "Hello %s","World") gives the expected output.
Logged
Don't forget what the H stands for.
*

Offline petabyte

  • *
  • 9
    • Personal site
Re: CHDK PTP interface
« Reply #1234 on: 08 / February / 2022, 12:10:01 »
srsa_4c thanks for posting your findings, I've implemented it in my mlinstall tool: https://github.com/petabyt/mlinstall/
Do you know of any quick evprocs with parameters to test it on?
« Last Edit: 08 / February / 2022, 12:21:46 by petabyte »
Logged
*

Offline reyalp

  • ******
  • 14082
Re: CHDK PTP interface
« Reply #1235 on: 08 / February / 2022, 12:54:10 »
Quote from: petabyte on 08 / February / 2022, 12:10:01
srsa_4c thanks for posting your findings, I've implemented it in my mlinstall tool: https://github.com/petabyt/mlinstall/
Do you know of any quick evprocs with parameters to test it on?
FWIW, I used the following for P&S. I think these not useful on EOS, just posting since I I also needed test cases...
no parameters: System.Create - registers other useful ones, returns 0 on success
numeric parameter: Peek32 - registered by above, can check return value against ROM dump
arbitrary parameters: Printf - can use UART redirection to verify results


Another unrelated FWIW, the 9050 905c etc opcodes are also present on some Digic DV cams, such as xf605
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #1236 on: 08 / February / 2022, 15:32:36 »
Quote from: reyalp on 08 / February / 2022, 02:21:39
3) The long arg handling appears to fail with multiple long args (tested on elph130 and elph180).
Fails here also, thanks for noticing. I have a custom eventproc for testing, but I did not try multiple long args. I was happy that memcpy succeeded and considered the case done. I'll try finding the missing piece.
Quote from: petabyte on 08 / February / 2022, 12:10:01
Do you know of any quick evprocs with parameters to test it on?
I used memcpy due to its usefulness.
Quote from: reyalp on 08 / February / 2022, 12:54:10
Another unrelated FWIW, the 9050 905c etc opcodes are also present on some Digic DV cams, such as xf605
Nice... I wonder if they used the same API and whether the eventprocs (if any) include known ones.
Quote from: coon on 07 / February / 2022, 17:16:04
The only difference is, that some some buffer on the stack is initialized with 1 or 0.
On sx740, that seems to be an argument passed to an underlying function, its value appears to influence the way the challenge is evaluated.
Logged
*

Offline reyalp

  • ******
  • 14082
Re: Native ExecuteEventProc over PTP
« Reply #1237 on: 09 / February / 2022, 02:19:41 »
Quote from: srsa_4c on 06 / February / 2022, 17:50:24
IsEventProcRunning 0x9057

Self-explanatory name, but I did not try calling it. Can return up to 3 params.
I tested this a bit on elph130. it returns:
0 - if not running and no pending result / last call was not async
1 - if running
If async, the first call after it finishes running returns two or three values:
2, the function return value, and remote data length if remote data was used.

It appears you get a PTP "device busy" code (0x2019) if you do things out of sequence like
- Call Execute with return data before calling GetReturnData to get return data from a previous call
- Call Execute before an async is finished
- Call GetReturnData when there is no pending data, including while an async is running
- Call GetReturnData before calling IsRunning, if the previous call was async

I managed to hang the PTP connection a few times playing with these sequences, but that may be due to chdkptp's poor handling of errors /stalls in operations with data.

On elph130 and elph180, the return data buffer size is 4K.
Attached is a patch with eventprocs I used for testing.

Quote from: srsa_4c on 08 / February / 2022, 15:32:36
Nice... I wonder if they used the same API and whether the eventprocs (if any) include known ones.
notes

edit: Feb 13, 2022
Updated patch compatible with thumb2 cams.
« Last Edit: 13 / February / 2022, 22:41:50 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #1238 on: 12 / February / 2022, 17:52:03 »
Quote from: reyalp on 08 / February / 2022, 02:21:39
3) The long arg handling appears to fail with multiple long args
Thanks to a different firmware and reyalp's help, I could fix this. I updated the original "announcement". A patch for my script in petabyte's ptp-tool is attached to show the fix.
Logged
*

Offline reyalp

  • ******
  • 14082
Re: CHDK PTP interface
« Reply #1239 on: 13 / February / 2022, 04:00:02 »
Quote from: srsa_4c on 12 / February / 2022, 17:52:03
Thanks to a different firmware and reyalp's help, I could fix this. I updated the original "announcement". A patch for my script in petabyte's ptp-tool is attached to show the fix.
Nice work, with the new information long args are working in my chdkptp code. I've added "proper" support in chdkptp r1118-1120. Documentation can be found in chdkptp/lua/ptpevp.lua before con_methods:ptpevp_call. This should be usable with any cam that supports the API, regardless of whether CHDK is installed.

Briefly

con:ptpevp_initiate() calls 0x9050 x3

con:ptpevp_call(name,arg1,...argN,{options}) calls an eventproc with the given parameters, and by default returns the function return value, followed by return data if requested.

Numbers, strings and chdkptp lbufs are accepted as arguments. Note that string/lbuf arguments must be explicitly null terminated if the camera expects a C string for the argument.

options controls async, return data and various debugging option.
radata='string' specifies return data should be used and returned as a Lua string.
async=true specifies an async call
wait=true polls IsRunning until an async call finishes
verbose=true to be used to print details about each transaction

By default, if rdata is enabled (and wait is true, if async), the data is fetched and returned. This can be disabled by setting getrdata=false

other functions
con:ptpevp_wait - wait for async to finish, and get data if it returned data
chdku.ptpevp_prepare - generates an lbuf of the data to be sent with Execute

some examples can be found in lua/tests/ptpevp.lua
Logged
Don't forget what the H stands for.
Pages: 1 ... 119 120 121 122 123 [124] 125   Go Up
« previous next »
 

Related Topics