Canon EOS R5 / R6

[horshack]

Cool hack - it's the clearest proof the "overheating" is timer-based, if you ask me.

Well, this particular hack is easy enough to automate - I wouldn't be surprised if somebody comes up with a one-click version within the next few days or weeks (also mentioned on Twitter). Motivation is high in the R5/R6 user community - much higher than for porting ML on 5D4, EOS R and the like, in my opinion. So, while it's definitely a low-hanging fruit with high rewards, I don't see anyone paying for a slightly more polished version of this hack. A free one will very likely appear sooner or later, without our involvement.

BTW - I feel a lot safer knowing this hack was discovered by third parties - even if it was documented on our forum. There's no single person behind it - all of the previous iterations paved the way to this version of the hack ("standing on the shoulders of giants"), and I'm pretty sure it will be further refined by the community.

Now, back to my (covid-related) research

Automation of the time change would be simple - only requires an HTTP GET and PUT over WiFi to "http://<camera ip>:8080/ccapi/ver100/functions/datetime". See my Canomate CCAPI utility at Canomate HomePage and Canomate GitHub Repository for examples on usage. Canomate's SyncDateTime does this.

Automation of the battery pull word require scripting to a network-enabled power switch, like a TP-Link Kasa Smart Plug, connected to a dummy battery inside the camera.

Both could be implemented via a simple Smartphone app.

[visionrouge.net]

Automation of the time change would be simple - only requires an HTTP GET and PUT over WiFi to "http://<camera ip>:8080/ccapi/ver100/functions/datetime". See my Canomate CCAPI utility at Canomate HomePage and Canomate GitHub Repository for examples on usage. Canomate's "SyncDateTime" does this.

Automation of the battery pull word require scripting to a network-enabled power switch, like a TP-Link Kasa Smart Plug, connected to a dummy battery inside the camera.

Both could be implemented via a simple Smartphone app.

You can go further.
When overheating.
Put the time front one hour. Do a battery drop.
The overheat timer is gone, so you need to write this flag down by turning off the camera.
When done, you can now change back the real time. As the flag is gone, there is no more check on "how long it is before cooling"
If you know how long each step are taking and add the exact same amount of time, you may actually always record with the real time.

The reset sequence can include a go back in time sequence...

[kaco]

So, while it's definitely a low-hanging fruit with high rewards, I don't see anyone paying for a slightly more polished version of this hack. A free one will very likely appear sooner or later, without our involvement.

a1ex speaking from my experience, I think there are enough users who would be willing to pay for the development. For porting ML to 5Dm4 or even R5/R6. And this would be really the best time for the switch -- there's a lot of interest around R5/R6. And it's not just the timers...

I've been professionally shooting ML raw with 5D3 for years. The 5x3 48p is dated, but there are still not many other options. Blackmagic has BRAW (not raw), cropped sensors, and plastic bodies. Sigma FP is nice but quite limited and the fullHD line-skipped mode is "meh"... Even if I would be willing to spend 10k+ on a Cinema Camera, the C300mk3 is still S35 only. And the C500mk2 is way out of budget of independent filmmakers and high-end documentarists like me.

There really are not many options that are full-frame with raw, sharp full HD and at least 48p. Not to mention that amazing UI of ML.
Recent developments with cropped 4k raw and gray preview are nice, but not so easy to use in a real-world for some serious work.

Maybe it's just me, but I really think focusing on the high-end camera will make much more sense. People who use EOS M are lowe-end hobbyists who most of them already switched to some other cheap cameras. If you will be able to port ML to 5Dmk4 (which is 1500 eur used) every film student and indie artist will use it.

[Lars Steenhoff]

The Canon 5d4 is surpassed by the sigma fp at least for me, I sold the 5dmk3 for the sigma.

I would be most interested in the r5 with magic lantern, because evf and tilting screen and usable autofocus makes it a smaller package not needing extra an extra monitor or evf.

What I would use magic lantern for is writing lens metadata for manual focus lenses and the recording timer automated.

[Walter Schulz]

So, while it's definitely a low-hanging fruit with high rewards, I don't see anyone paying for a slightly more polished version of this hack. A free one will very likely appear sooner or later, without our involvement.

I wrote that way back in the days when ML was the only software offering a solution. Good old days, feels like yesterday ... wait ... It was kind of yesterday, wasn't it?

Totally agree! Doesn't make sense to put a price tag on some script.
But that wasn't my intention. ML going payware? Nope but I consider this a good starting point for something like Patreon.
Are there "enough" contributors like kaco wrote? Definitely don't know!

[horshack]

Here's a Canomate script for automatically changing the camera's clock to +1 day and then back.

Save the contents of the following to a file named DateTimeHack.txt:

Code Select Expand


PrintCameraInfo
SyncDateTime skewsecs=86400
PrintMessageToLog message="Pull battery NOW, wait a few seconds, put battery back in, wait 10 seconds, then press <ENTER>"
WaitForEnterKeyToContinue beep=1
SyncDateTime


To run the script: canomate.py --ip=<camera's IP address> --opfile=DateTimeHack.txt

Output:

Code Select Expand


canomate v0.02 - Automation Utility for Canon cameras (uses Canon Control API via WiFi)
Copyright (c) Horshack, System Time: 09/06/20 10:43:13, Py: 3.8.0, OS: Windows

PrintCameraInfo: Model: Canon EOS RP, S/N: XXXXXXXXXXXX, Firmware: 1.5.0
SyncDateTime: Changed camera time from "Sun, 06 Sep 2020 10:43:13 -0800 DST" to "Mon, 07 Sep 2020 10:43:13 -0800 DST"
PrintMessageToLog: Pull battery NOW, wait a few seconds, put battery back in, wait 10 seconds, then press <ENTER>
WaitForEnterKeyToContinue: Press <Enter> to continue...
SyncDateTime: Changed camera time from "Mon, 07 Sep 2020 10:43:15 -0800 DST" to "Sun, 06 Sep 2020 10:43:16 -0800 DST"
>>>> canomate session over (exit=0), logs at "C:\develop\canomate\canomate-appdata"


I tested this on my Canon RP.

I tried writing a quick JavaScript app that does this in a browser (so we can use portable devices like smartphones) but the Cross-Origin Resource Sharing (CORS) protections prevents the code from performing requests to the camera. Unfortunately the camera is not sending a permissible Access-Control-Allow-Origin in the HTTP header. A developer has already requested a change here: Could a CORS policy be implemented for the CCAPI?. This would have to be written as a Smartphone app instead. Shouldn't be too hard for an enterprising individual 

[names_are_hard]

CORS is a client side check.  You can disable / fake it with a browser plugin, or a proxy.
https://chrome.google.com/webstore/detail/allow-cors-access-control/lhobafahddgcelffkeicbaginigeejlf?hl=en

Not a great suggestion long-term as it will decrease your security if you forget and leave it active.  Might work for testing.

[horshack]

CORS is a client side check.  You can disable / fake it with a browser plugin, or a proxy.
https://chrome.google.com/webstore/detail/allow-cors-access-control/lhobafahddgcelffkeicbaginigeejlf?hl=en

Not a great suggestion long-term as it will decrease your security if you forget and leave it active.  Might work for testing.

Not viable for mobile solutions since extensions aren't allowed on those platforms. I'll be testing my Canomate with Pythonista later today.

[names_are_hard]

True for iPhone, but extensions are allowed on Android.  If you were determined you could also VPN through a MITM proxy to modify the response header to strip CORS, that would work on any phone supporting VPN.  I suspect not a very practical solution for the intended audience

[horshack]

True for iPhone, but extensions are allowed on Android.  If you were determined you could also VPN through a MITM proxy to modify the response header to strip CORS, that would work on any phone supporting VPN.  I suspect not a very practical solution for the intended audience

Thanks. I can look into Android since I run both iOS and Android. An internet-based MITM proxy wouldn't work since it wont have access to the local phone's IP (unless the port is forwarded through the router and that wont work when away from home network). Running MITM on the phone would work but then you're writing an app anyway to do it. Running MITM on a computer on the local network would work but again not viable when not on home network.

I just tried Canomate with pythonista and it worked on both my iPad and iPhone. Bit of a hassle getting the .py files onto the phone (uploaded them to my Google Drive, then downloaded from Google Drive to Files app, then opened in pythonista). Here's a screenshot from the phone.

[Dmytro_ua]

What I would use magic lantern for is writing lens metadata for manual focus lenses and the recording timer automated.

It would also be nice to know the real temperature if you disable a "safety timer".

[Lars Steenhoff]

Yes for sure, it would be good to know when the camera is really overheating based on the sensor and not on the timer.

[names_are_hard]

@horshack - a VPN will look like the same network, you get an additional network interface, with the phone and vpn endpoint being in the same subnet.  Everything is tunneled, so you will see this as one hop, you won't see ISP or phone provider in the middle.  Wireguard or OpenVPN are both free and available on most everything.  Wireguard is supposed to be easier to configure.  You can then configure the VPN to provide DNS, with that DNS server that you control routing whatever names you want to whatever IPs - so you can make the proxy transparent with the only config needed on the phone being the VPN.  Of course, you're trusting the VPN an awful lot!

It looks like your Python works and it's probably easier for people to use.

[dellfonic]

No need for dummy battery boys and girls, just recorded in 8K IPB until the overheating warning came on. Changed the day +1 and pulled the battery. Voila! Canon Cripple Clock obliterated! Great work ppl!

[EOSHD]

I certainly think there would be plenty of interest in ML for the EOS R5 and R6.

The overheating timer patch is the big thing, but the file sizes in 8K RAW aren't really practical and not many people need 8K... So would be good to see what else RAW-related might be hidden in that frame buffer... 4K RAW or 3K crop perhaps....the write speeds to CFexpress would very likely allow 10bit lossless RAW in 4K! And to enable ALL-I and DCI 4K on R6 would be tremendous! And temps monitor in real-time, to check for any dangerous ones on hot days.

Well done to all testers and contributors on here, it's amazing the progress already.

I think ML should invest some Patreon money in useful hardware, non-profit organisation but able to invest in their mission. I'd happily support any Patreon.

And of course I want to play Arkanoid on my EOS R5

[visionrouge.net]

It would also be nice to know the real temperature if you disable a "safety timer".

There is a next step on this hack. I should work, but need one beta tester to be sure.

Follow the previous procedure to push forward the day.
When you see that the "overheat logo" is gone; turn off the camera using power button.
At this time, the "overheat flag" is now written into memory.
Turn back on the power with the power button. The camera is now booting from a regular boot.
So if you have no warning here, the camera is absolute fine with temperature. This not a "special boot" anymore
And the beauty of it, you can now push back the day as the actual day.
So with this extra step, all your clip are even at the right time.

Can someone test this ? Thanks
I will update on visionrouge.net if so.

[horshack]

@horshack - a VPN will look like the same network, you get an additional network interface, with the phone and vpn endpoint being in the same subnet.  Everything is tunneled, so you will see this as one hop, you won't see ISP or phone provider in the middle.  Wireguard or OpenVPN are both free and available on most everything.  Wireguard is supposed to be easier to configure.  You can then configure the VPN to provide DNS, with that DNS server that you control routing whatever names you want to whatever IPs - so you can make the proxy transparent with the only config needed on the phone being the VPN.  Of course, you're trusting the VPN an awful lot!

It looks like your Python works and it's probably easier for people to use.

Thanks. That's probably a bit too much to ask of somebody as a way around the CORS. Btw, how does that create a path between an internet-based CORS proxy and the camera?

[horshack]

Yes for sure, it would be good to know when the camera is really overheating based on the sensor and not on the timer.

A poster on EOSHD got 75C (EXIF temp) after 38 minutes of 4K 120fps using @visionrouge.net's workaround. I think that's probably pushing it. It was hot enough to cause the R5's stills temp warning icon to show. He said the CFE was extremely hot when removed.

[dellfonic]

It works:

15 mins recording 8K ALL-I to CFExpress, overheating icon

Day +1, pulled battery

Inserted battery 30 secs later

No overheating icon

Turn off camera

Turn on camera, change date to current date, no overheating icon.

[visionrouge.net]

It works:

15 mins recording 8K ALL-I to CFExpress, overheating icon

Day +1, pulled battery

Inserted battery 30 secs later

No overheating icon

Turn off camera

Turn on camera, change date to current date, no overheating icon.

YES!
I love to be right.
thanks for testing, you will have your name on my wall of fame too!

I'm wondering how Canon feel about a 40+ photographer able to crack their software without even having the camera in hand.

[names_are_hard]

@horshack - I don't know what you mean by a CORS proxy.  CORS is a server value that is sent to the client by whatever route.  The client can choose to honour CORS policy.  Modifying the client means you can ignore the policy, controlling a proxy in the route means you can remove the CORS policy.  If you have VPN on a client, and camera connected to some machine also connected to the VPN, then client and camera are on the same network.  So I *think* the combination means you can remove the parts that are difficult.  But I've never used Canomate so I could easily be misunderstanding something.

Specifically, Wireguard uses TCP-over-UDP.  UDP for low latency, TCP for convenience.  The two endpoints need a route, they *think* they're talking TCP and are next to each other, but the TCP packets are encapsulated in UDP.  At TCP level the client-server looks one hop away, at UDP level it's whatever route your network / ISP / etc has.

[dellfonic]

YES!
I love to be right.
thanks for testing, you will have your name on my wall of fame too!

I'm wondering how Canon feel about a 40+ photographer able to crack their software without even having the camera in hand.

Ha, great work mate, I'm slightly annoyed with myself for not coming up with the solution as it's my natural inclination to bend and push any kind of deliberate cripple! Then again, I have leased it out for the last 3 weeks, so presumed all the tests had been exhausted.

[horshack]

@horshack - I don't know what you mean by a CORS proxy.  CORS is a server value that is sent to the client by whatever route.  The client can choose to honour CORS policy.  Modifying the client means you can ignore the policy, controlling a proxy in the route means you can remove the CORS policy.  If you have VPN on a client, and camera connected to some machine also connected to the VPN, then client and camera are on the same network.  So I *think* the combination means you can remove the parts that are difficult.  But I've never used Canomate so I could easily be misunderstanding something.

Specifically, Wireguard uses TCP-over-UDP.  UDP for low latency, TCP for convenience.  The two endpoints need a route, they *think* they're talking TCP and are next to each other, but the TCP packets are encapsulated in UDP.  At TCP level the client-server looks one hop away, at UDP level it's whatever route your network / ISP / etc has.

I'm not following you. The client in this case is the browser running my test javascript code issuing REST API requests to the camera's REST API server (CCAPI). There is no way to coerce the browser to accept cross-domain requests unless the HTTP header response from the server contains an Access-Control-Allow-Origin response that specifically allows the domain you're requesting from. The only way around that is either an extension running in the browser that hacks an Access-Control-Allow-Origin field in the response header (doesn't work on iOS because extensions aren't allowed) or by issuing the REST API request through a CORS proxy that issues the request to the intended target on your behalf (camera in this case) and returns a response that adds in the Access-Control-Allow-Origin field. I don't see how running a VPN factors into the equation as a solution.

Canomate doesn't have this issue because it runs as a Python app outside the browser. I tried implementing a REST API client as javascript instead for this specific date/time R5/R6 workaround as a lightweight alternative to running Canomate and also because it would be a portable solution that can run in a Smartphone browser.

[names_are_hard]

VPN allows controlling DNS.  So, you say blah.com is at 192.168.2.2, *that* is a MITM proxy, it requests the real page from camera.xxx, relays that response back to the client *but removes the CORS info*, and then the client doesn't see any CORS, so it does what you want.

[horshack]

VPN allows controlling DNS.  So, you say blah.com is at 192.168.2.2, *that* is a MITM proxy, it requests the real page from camera.xxx, relays that response back to the client *but removes the CORS info*, and then the client doesn't see any CORS, so it does what you want.

The only device is the smartphone running in the field. Where is proxy code running that has IP access to the camera?