Jump to content

Canon EOS R5 so-called overheat timer defeated by a single screw in battery door


Recommended Posts

2 minutes ago, horshack said:

It's definitely a start. The file sizes are off though - it shows only 96K for the MP4 and put the remainder of the card's capacity in bucket labeled .mhk. Not sure if the extraction would successfully reconstruct the file.

I bet it will... ;- )

Link to post
Share on other sites
  • Replies 109
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Canon engineers reading this thread.

On Friday, I received a message from the lead developer at Magic Lantern. An interesting theory was being put forward by one of their open source contributors, which he believed could defeat the so-ca

A1ex is a legend I swear. That guy should replace the current CEO at canon

Posted Images

I don't understand why you would go through all that work to reconstruct the file. Why not record what you want, then record another short, bogus file and kill the battery. Forget about trying to reconstruct the file and just create a dummy file that you don't care about.

Link to post
Share on other sites
1 minute ago, ajay said:

create a dummy file that you don't care about.

As an outsider looking into this Canon fiasco I find it amusing how so many people are drawn into the drama that have no dog in the hunt.  (like me -- perfectly content with shooting 4k my humble $300 camera M43 camera)

I'll never spend 4K on a camera for video again, but I certainly used to.  And if I was dropping that sort of expense I'd expect it to work as advertised.  That said, I used to have to do some rather violent hardware hacks to get the HDV 0's and 1's out of my old XH-A1 at times...and I thought that camera was a bargain @$3.5K. 

It's always something with Canon, on that you can rely.

Link to post
Share on other sites
12 minutes ago, horshack said:

It's definitely a start. The file sizes are off though - it shows only 96K for the MP4 and put the remainder of the card's capacity in bucket labeled .mhk. Not sure if the extraction would successfully reconstruct the file.

It is possible the the MP4 is an older file ... if a low level format of the card was not done ... it may still appear if deleted and not overwritten by a subsequent

write operation. I assume your file is the .mhk

Link to post
Share on other sites
12 minutes ago, ajay said:

Why not record what you want, then record another short, bogus file and kill the battery. Forget about trying to reconstruct the file and just create a dummy file that you don't care about.

As I understand it, if you 'legit' stop recording the timer data is written so you can't bypass the cripple timer.

IMO this isn't about getting a 'workaround' work flow in the first instance and actually retrieving footage, this is about shaming Canon into acting by showing how much it could run for in the crippled modes. User / Magic Lantern etc workarounds should come later if Canon don't act. 

Link to post
Share on other sites

That would be great if there could be a work-around from Magic Lantern but the way ML works is by supplementing the existing firmware, not changing the existing firmware. Not that it isn't possible, but ML would have to create their own frame modes, codecs, etc. and it wouldn't be as easy as simply changing a timer option in the original code. Months and months (or more) of work.

That said, if they could pull it off it would be an amazing camera.

Link to post
Share on other sites
  • Administrators

The other ugly thing is that I have taken an absolute beating online with people questioning my reputation left right and centre for revealing this timer and behaviour from Canon.

Canon meanwhile, brand reputation virtually untouched, not two hoots from them, no statement, no recall and the EOS R5 continues to fly off shelves!!

BBC and CNN tech reporters should be all over it. Where are they?

Link to post
Share on other sites
4 minutes ago, Andrew Reid said:

The other ugly thing is that I have taken an absolute beating online with people questioning my reputation left right and centre for revealing this timer and behaviour from Canon.

Canon meanwhile, brand reputation virtually untouched, not two hoots from them, no statement, no recall and the EOS R5 continues to fly off shelves!!

BBC and CNN tech reporters should be all over it. Where are they?

It is also very quiet the position of all the other brands... Sony in the beginning did some marks before to launch the A7SIII (then we know what's the real) but organisation or group as Consumer Reports/Union are so quiet?

Link to post
Share on other sites
  • Administrators

Ah Sony are just another bunch of opportunists really, using the suffering of a rival to drum up some more sales - I'm no great fan of the A7S III.

I think this is a watershed moment, and I hope it encourages people to spend their money differently.

Maybe buy more from Sigma, who are family owned.

Let's put business ethics in the spotlight.

Let's see what really goes on behind closed doors and what they try to hide from their customers.

Link to post
Share on other sites
1 hour ago, ajay said:

I don't understand why you would go through all that work to reconstruct the file. Why not record what you want, then record another short, bogus file and kill the battery. Forget about trying to reconstruct the file and just create a dummy file that you don't care about.

exactly, Andrew, can you try this?

Link to post
Share on other sites
1 hour ago, docmoore said:

It is possible the the MP4 is an older file ... if a low level format of the card was not done ... it may still appear if deleted and not overwritten by a subsequent

write operation. I assume your file is the .mhk

It was with an in-camera low-level format, which doesn't actually wipe the entire card because it completes in just a few seconds. After I posted earlier I did another experiment where I completely wiped the card with 'dd' under Linux, then did an in-camera low-level format and repeated the test video w/battery pull. After that IsoBuster only found a single file, named Recovered File 1. mp3 with a size equal to the full capacity of the SD. Which means it's actually less encouraging than before, at least the idea of using an off-the-shelf program rather than engineering a custom solution.

Link to post
Share on other sites
14 minutes ago, Andrew Reid said:

Ah Sony are just another bunch of opportunists really, using the suffering of a rival to drum up some more sales - I'm no great fan of the A7S III.

I think this is a watershed moment, and I hope it encourages people to spend their money differently.

Maybe buy more from Sigma, who are family owned.

Let's put business ethics in the spotlight.

Let's see what really goes on behind closed doors and what they try to hide from their customers.

Andrew - You know Cannot was hacked by a data ransom organization. If Cannot doesn't pay them...could you imagine these hackers releasing all the internal confidential emails from R5 developers and managers and Cine team and marketing execs? Could we see all the dirty back room plotting and planning on how they were going to sham their customers?

Woah...that would be massively embarrassing for Cannot.

Link to post
Share on other sites
1 hour ago, ajay said:

I don't understand why you would go through all that work to reconstruct the file. Why not record what you want, then record another short, bogus file and kill the battery. Forget about trying to reconstruct the file and just create a dummy file that you don't care about.

It's definitely worth a shot but the evidence suggests that stopping a recording causes the current thermal management state to be written to NVRAM at that point. This is likely why J Marcus only got 5:00 back when pulling the battery - that's because the last NVRAM update was from the previous power-on session where the last video file was saved and the camera reported 5:00 available. So pulling the battery thereafter reverts back to whatever was last saved in NVRAM, which for him was 5:00

Link to post
Share on other sites

You will find the data on the card if you stop recording by pulling out the camera. It has the ending .DAT. You won't be able to play it with any video player.

By the way - are you guys sure we might get a MagicLantern hack? The Canon 1DX as a almost identical camera to the Canon 1DC was never hacked, was it?

Link to post
Share on other sites
  • Administrators
1 hour ago, Matthew19 said:

exactly, Andrew, can you try this?

 

2 hours ago, ajay said:

I don't understand why you would go through all that work to reconstruct the file. Why not record what you want, then record another short, bogus file and kill the battery. Forget about trying to reconstruct the file and just create a dummy file that you don't care about.

It is because the camera may write the last clip length and 'overheat' timer status to the cripple clock memory when you hit stop on the recording.

Going to test a few things around this aspect soon.

Link to post
Share on other sites
2 hours ago, horshack said:

It was with an in-camera low-level format, which doesn't actually wipe the entire card because it completes in just a few seconds. After I posted earlier I did another experiment where I completely wiped the card with 'dd' under Linux, then did an in-camera low-level format and repeated the test video w/battery pull. After that IsoBuster only found a single file, named Recovered File 1. mp3 with a size equal to the full capacity of the SD. Which means it's actually less encouraging than before, at least the idea of using an off-the-shelf program rather than engineering a custom solution.

Just ran a short clip on my 1DXIII pulled the battery and extracted the DAT file to my desktop. ISObuster attempted to convert it to mpg but the resulting file

was unplayable in VLC, unrecognized by FF:Works and Davinci Resolve Studio. The conversion in ISObuster was at 2.1MB/s ... so even if it were readable the length of time

to convert would be untenable.

Link to post
Share on other sites
1 minute ago, docmoore said:

Just ran a short clip on my 1DXIII pulled the battery and extracted the DAT file to my desktop. ISObuster attempted to convert it to mpg but the resulting file

was unplayable in VLC, unrecognized by FF:Works and Davinci Resolve Studio. The conversion in ISObuster was at 2.1MB/s ... so even if it were readable the length of time

to convert would be untenable.

Thanks. That probably saves me from buying ISObuster for this effort. Was the size of the file about what it should've been for how long the video was? If so then the file may have all the salvageable data recovered and just needs to have the tail of the MP4 container repaired as discussed earlier.

 I haven't been getting the .DAT but just realized it's because I'm using FAT32 whereas everyone else is likely using exFAT. It defaulted to FAT32 due to the smaller card I was using (32GB), which I chose to make the imaging/recovery experiments faster. If I switch the same card manually to exFAT then the .DAT file starts showing up after an interrupted recording on my Canon RP. I'll be focusing on exFAT in my ongoing work since that's what most are probably using.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...