Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - visionrouge.net

#1
Camera-specific Development / Re: Canon EOS R5 / R6
September 09, 2020, 10:24:34 AM
Canon Just released a Firmware V1.1.1 for R5 and R6

Be aware of possible lock down on my hack finding last Sunday.
Even if I think it will be a very fast answer to roll out a firmware in only 3 days, that's still a possibility.

At least, it may be able to do a file comparison between V1.1.0 et V1.1.1 to see what changed is any.


#2
Camera-specific Development / Re: Canon EOS R5 / R6
September 07, 2020, 03:04:46 PM
I'm posting here as reference y best guess why my hack is working.
It may be useful for a possible software side app at one point.

Canon do a very simple calculation.
When camera is running, a counter is setup. When the counter reach a certain level, you have a warning logo.
If you keep recording, the Logo will become a shut down. This raise a flag that I will call "Fake Overheating flag"

At each of these step Canon is writing the exact time this occurs. Let's call it the "overheat start time".
This is done in an EEPROM that is kept even if you remove the battery. The writing occurs when you shut down with the power button. This is the mistake right there.

There are only one way of getting the camera to work again is to wait extra time.
Canon do a simple calculation between "actual time" and "overheat start time". This way, even if the camera is off without battery, they can keep the time running with the help of the RTC.
It's a way of doing coding something very fast.

They also put a conditional test on "Fake Overheating flag" to make sure changing the time during the overheat mode will not change this calculation. My best guess is that they modify the "overheat start time" with the same value the camera time is shifted in this condition only. So each tentative to play this way is not working.

But I have the impression that the new"overheat start time" is written ONLY when the camera is power down. The new real time is written immediately.
So by dropping the battery, you are avoiding the "overheat start time" to be written and only the last one is in the memory.

When the power is restored, there is the calculation to see if you have been waiting enough. But based on the old "overheat start time", not the one shifted by the time modification. BOOOOM.

So the "Fake Overheating flag" is now remove and the camera can start.
Even better, The camera is writing this new "Fake Overheating flag" value into the EEprom. So you can turn off the right way and it will restart without any problem.

You can now shift the time back, there is no check for a possible "overheat start time" cause we are not supposed to be in overheating mode.

So whatever card you are using, whatever R5 or R6, whatever firmware... it's working.
That was my idea at first when I noticed that the battery drop do not save all parameters. An yes, it works so beautifully.
#3
Camera-specific Development / Re: Canon EOS R5 / R6
September 07, 2020, 06:03:27 AM
Quote from: dellfonic on September 07, 2020, 05:29:26 AM
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. 8) 8) 8)
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.
#4
Camera-specific Development / Re: Canon EOS R5 / R6
September 07, 2020, 03:23:32 AM
Quote from: Dmytro_ua on September 06, 2020, 10:11:16 PM
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.
#5
Camera-specific Development / Re: Canon EOS R5 / R6
September 06, 2020, 04:14:57 PM
Quote from: horshack on September 06, 2020, 04:04:59 PM
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...
#6
Camera-specific Development / Re: Canon EOS R5 / R6
September 06, 2020, 09:33:42 AM
So, the camera DO a  simple time difference between the actual last overheat and the actual time, but as you drop the battery, the time change bit is not read.
The boot just read the time present in the RTC at this time.

I guess the software engineer have applied a filter to not do a time difference if the day/time is changed, but this is bypassed by this kind of boot.

It also shows the RTC do not run a overheat timer when camera is off.

The compilation of finding are online  https://www.visionrouge.net/canon-r5-overheating-hack-solved/ (please click on the advertising at the botom to offer me 5 cent, I may be able to buy a new SD card !)
(And getting updated right now with pictures and all)
I'm so excited to find such loophole.
We need more R5 test with regular card, but I don't think there are relationship between this and the drop power boot.

I love you all

#7
Camera-specific Development / Re: Canon EOS R5 / R6
September 06, 2020, 08:56:51 AM
I'm so happy!
Thanks for trying.

YES!!!!
Please quote my company for such! :) :) :) :) :)
#8
Camera-specific Development / Re: Canon EOS R5 / R6
September 06, 2020, 06:16:36 AM
Sorry that I can't modify my post.

Ok, here are new thouht after thinking a bit.

Something is bothering me is the recovery time.
Even without regular camera battery, or by pushing the time.
The recovery time is not reduced.

If it was just a flag to a memory that start to count, it will not be able to know how long the camera was actually off.
It have to be a counter, not just a date stamp difference.
This overheat counter IS inside this chip for sure. cause it can't hold 2 different date and the internal counter are quite limited.

Either the current overheat time is written inside a eeprom, and so compare on boot, either there is a timer that keep running even without battery.
After 2 hour of "fake cool down"; the camera is powering again and check the value of this counter. If it reached the end, you can go again. If not, you have to wait.
The second possibility is that the camera compare the time on boot and do a simple subtraction to know if the elapsed time is enough. The various test kind of shows that it is not working.

To make sure about the second possibility and twist it a bit
I would love someone to do a simple test.
Put the camera on overheat and lock (after 20mn recording video) and keep the battery door open with the scerw hack or use dumb battery the entire time
Change the date  or time to move it to the next day.
Now, try 2 different things:

Remove the camera battery with the drop system. Is restarting check the new day? (But not the flag?)

Or simple turn off the camera, remove the battery and start again. is the second restart is able to do the math between both time? (So the overheat time is stored on eeprom/a counter is runnin during no battery time)

Does it makes sense to test this?
#9
Camera-specific Development / Re: Canon EOS R5 / R6
September 06, 2020, 04:24:41 AM
Well, it may be a bit more complicated.
If you put some fact together:
-Removing the battery cell reset the fake overheat timer, reset the time and date and few shooting parameters, but keep others as custom functions. So a memory is also powered with this battery. This is very common and few RTC chip also have internal memory to do 2 functions in one (RTC+limited amount of parameters)
This RX8130 do not have a memory register. So it have to be another chip somewhere to do so.

-The amount of chip powered by the 3.3V cell have to be as limited as possible and more likely close to the cell area. This is to keep backup, the power usage should be as tiny as possible. It uses 300 Nano Ampere in sleep mode as reference.

-If it was only a countdown with an IRQ, removing the battery during during the recording and putting back should not affect the countdown. The counter should keep running as soon as the "power good" is restored. So again, it points out to another memory that hold the counter flag.

I still believe a solution as magic lantern is the best way to go.
Either the counter inside the RTC is used for the fake overheat warning, Either it's just a RTC for the time and date.
A chip with a memory along the power line coming from the cell battery is more likely to have a register that can be access and changed by a side software. This software is extremely simple and write time to time a 0 flag in the fake overheat register.

The fake overheat timer starts during the full power state and write a flag when a normal internal timer is reached. This is more likely than using a specific chip for that. Only because the flag is written at the end of the count that removing the battery during shooting allows to restart. So finding this flag and overwriting it will solve this.
I don't see a use of this RTC for overheating purpose as it have very limited alarm feature. (The overheating have 2 steps for example)
I really see a register powered by the 3.3V, so a unique chip alone, not part of any large IC, that holds the key.
That should be also easier to access as it's a dedicated chip, ore likely from a generic brand more than from Canon, so the way to access it should be in a pdf somehow.
#10
Camera-specific Development / Re: Canon EOS R5 / R6
September 05, 2020, 01:56:54 PM
I found crazy that the RTC is a dedicated chip place in the middle of nothing and so easy to access.
I have a simple question.
The RTC holds the time and day and can be access by the I2C bus. Either to program the time and the alarm and countdown.
But when a alarm is set up, Pin 6 is the IRQ line. Usually, the IRQ adk the processor to check what is happening by reading the I2C.

Is simply cutting the pin 6 signal enough for not triggering the IRQ signal and shoot forever? (and keep time of the day and date active?)

You need to have this pin a High level with a pull up resistor linked to pin 8 if it's not already the case (low level is IRQ Active)
#11
Camera-specific Development / Re: Canon R5
August 23, 2020, 04:25:42 AM
I'm wondering how hard it could be to run a very simple hack as magic lantern with only one simple task: Reset the overheating counter?
It seem they are writing it into eeprom as it kept from reset even without battery. Only removing the RTC coin cell reset it for now.