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 - chris_overseas

#1
Quote from: c_joerg on September 18, 2020, 07:37:15 AM
I would be interested in a CameraInfo.xml from an R5 and R6, especially one that has already crashed.

Here's the CameraInfo.xml from my R5 (serial number removed):
<?xml version="1.0"?><Canon><CameraInfo><Serial>xxxxxxxxxxxx</Serial><FirmwareVer><Internal>0.4.0.5</Internal><Major>1.1.0</Major></FirmwareVer><ErrorList><Kind><ID>E70</ID><Count>1</Count><ErrorLog><BatTemperature>max:0 min:0</BatTemperature><FirstOccurTime>2020.09.06 17:49:38</FirstOccurTime><LastOccurTime>2020.09.06 17:49:38</LastOccurTime><Log><DateTime>2020.09.06 17:49:38</DateTime><Reason>DS-EID:101</Reason><BatTemperature>0</BatTemperature><LensID>000001eb</LensID><ReleaseCount>234</ReleaseCount></Log></ErrorLog></Kind></ErrorList><TotalShoot>3289</TotalShoot><TotalShutter>3</TotalShutter><PowerOnCount>537</PowerOnCount><TotalRunningTime>83180</TotalRunningTime></CameraInfo></Canon>
#2
Camera-specific Development / Re: Canon 5D Mark IV
September 17, 2020, 06:43:05 PM
Quote from: reddeercity on September 17, 2020, 08:59:10 AM
is there any one out there on the forum that have the source for the 5D Mark iv ?

The best place to start would be with my old BitBucket repository, it contains the most recent progress on the 5D4 along with a (somewhat inaccurate) todo list of sorts. The difficulty is that BitBucket deleted all their Hg repos, plus my home PC (where my copy of the repo lives) is currently in storage (I'm part way through a house move). To make things worse I'm also away travelling for the next few weeks with no ability to access my home PC in the meantime. Your best bet would be to find someone who backed up the BitBucket Hg repos and grab a copy of my code from what used to be https://bitbucket.org/chris_miller, and see how you go from there.
#3
Camera-specific Development / Re: Canon EOS R5 / R6
September 05, 2020, 06:36:05 AM
Very nice - I can confirm it works on the R5 too! I had been using an SDXC card with my previous attempts, worked fine when I tried it with an SDHC. Same combination to activate it, PLAY then SET.
#4
Thanks kitor, much appreciated. I tried various combinations of Play followed by buttons and dials, pulling the battery each time (not sure that's needed or not?) using your image. I also tried it with and without an image on the card in case that matters, and with the card write protected. Unfortunately still no luck on the R5, so either the way to trigger it isn't very obvious or scripting doesn't work at all :(
#5
Is there any chance someone could create a known-working 256MB SD card image that contains a sample (ROM dumper or otherwise) script, compress it and get that added to the first post? I for one would like to try it with the R5, to eliminate any possibility I messed up when trying to create my own scriptable card.

I'd also like to try this on a CFExpress card to eliminate any drive letter issues. I have one on order but unfortunately it might not arrive in time for my departure on a long trip next week. If it does get here before then I'll test and report back. The SD card slot shows up as "Card 2" in the Canon menus, if that helps (the 5D Mark IV also shows its SD slot as "Card 2").
#6
Camera-specific Development / Re: Canon EOS R5 / R6
September 02, 2020, 11:33:55 AM
Quote from: c_joerg on September 02, 2020, 11:06:42 AM
Sure the SD Card is not exfat?
You need FAT.

Yes, it's FAT
#7
Camera-specific Development / Re: Canon EOS R5 / R6
September 02, 2020, 08:51:08 AM
Quote from: a1ex on September 02, 2020, 07:14:30 AM
You could write our QEMU card image to the card, which will shrink the filesystem to 256MB (FAT16 iirc):

To verify it, test the card on any other ML-enabled camera. Once that works, make the card scriptable by following CHDK instructions (EosCard or whatever), then start the camera, go to PLAY mode and press SET. At least, that's what I did on M50.

I can also prepare a scriptable card image with Canon Basic dumper, if needed.

I have an R5 here and just tried to get this working without luck so far. I did the following:

  • Low level formatted a 128GB SD card in the R5
  • On my PC I then wrote the QEMU SD card image to it using Win32 Disk Imager, verified the card was showing as 256MB
  • Checked the card worked as expected in my 5D3
  • Used EOScard 1.40 to set the card as scriptable (by ticking SCRIPT, unticking EOS_DEVELOP and BOOTDISK, then choosing "Save")
  • Created a script.req file containing the string "for DC_scriptdisk"
  • Created an extend.m file containing Hello World
  • Created an extend.m file containing the dumper script
  • Put the card in the camera, powered up, pressed Play followed by Set (also tried Play followed by Q)
Unfortunately nothing happens. Have I made a mistake or are we out of luck? Maybe there's a different combination required to trigger the script?
#8
I agree - great idea but hard to plan for. Spain's currently easy for me (in fact I fly there tomorrow!) but in six years time there's a high chance I'll be living on the other side of the world which would make this much more difficult. Keep floating the idea and I'm sure once it's a year or so out there'll start being a few takers, hopefully myself included.
#9
For those who are interested, this looks like it will be a pretty powerful tool for reverse engineering hardware:

https://www.crowdsupply.com/1bitsquared/glasgow

I don't think the hardware is available yet but you can sign up at the link above, or make your own if you're feeling especially adventurous and don't want to wait...
#10
Quote from: liberatemycamera on June 11, 2020, 01:26:19 AM
EOS Utility doesn't seem to recognize my camera when I connect it to the computer....do I need to upgrade to 1.3.6 to be able to proceed?

I've hit that one before and it can be frustrating to figure out because there is no error or obvious reason why its not working. Try starting EOS Utility by running it as Administrator. Does it now detect your camera?
#11
Hi Ilia3101, looks like an interesting and promising project. Are you familiar with the dual pixel RAW mode of the newer Canon cameras? It seems like (multiple?) dual pixel images could be a good candidate to use as input to your algorithm.

Here are a few relevant links:

https://photographylife.com/what-is-dual-pixel-raw-in-the-canon-5d-mark-iv
https://www.magiclantern.fm/forum/index.php?topic=17695.msg172097#msg172097
https://a1ex.magiclantern.fm/bleeding-edge/5D4/5d4-dual-pixel.html
https://a1ex.magiclantern.fm/bleeding-edge/5D4/dual-pixel/5D4-lv-daf-raw.html
https://www.osapublishing.org/oe/abstract.cfm?uri=oe-24-12-12868
#12
Here's what I found so far when comparing to 1.2.3:

NSTUB(   0x27F78,  dm_names)
NSTUB(   0x2731C,  current_task)
NSTUB(   0x27208,  task_dispatch_hook)
NSTUB(   0x2852C,  task_max)

Where did the terminateShutdown_save_settings and terminateAbort_save_settings stubs come from, 1.3.4 I guess? I don't see those in 1.2.3.
#13
My time has been extremely limited for ML of late too but I'll try and help out with this as much as I can, I'm pretty familiar with stub hunting on the 5D3.
#15
This quote is an interesting one from a security PoV, and potentially problematic for ML going forwards:

"There is a PTP command for remote firmware update, which requires zero user interaction. This means that even if all of the implementation vulnerabilities are patched, an attacker can still infect the camera using a malicious firmware update file"

Of course this approach requires the secret AES key, but the attackers have demonstrated this isn't too difficult to obtain. The specific vulnerability covering this is https://nvd.nist.gov/vuln/detail/CVE-2019-5995. It's interesting they describe it as a "missing authorization" problem. That seems to imply the fix involves the addition of an authorization step (to the PTP negotiation or call?) rather than an overhaul of the encryption itself. If so then ML shouldn't be impacted, but I think that still remains to be seen.

As a side note, I need to take my 5DIV in for a service this week due to a sticky scroll-wheel. They normally update to the latest firmware as part of the service, so I'll find out soon enough where things stand on the 5DIV at least.

[edit: https://www.magiclantern.fm/forum/index.php?topic=17360.msg219613#msg219613 implies the patch isn't a problem as far as ML is concerned]
#16
Quote from: walter_schulz on August 11, 2019, 10:08:11 PM
Any word about the fix affecting the key currently used by ML devs?

I doubt this is a concern, the vulnerabilities found aren't related to the firmware encryption. I also wonder if it's even possible for Canon to update the AES key with a firmware update.

Quote from: walter_schulz on August 11, 2019, 10:08:11 PM
EDIT: And why aren't other D5 cams like 650D, 100D, M/M2, 700D *not* vulnerable (according to Canon)?

"Even though our camera model doesn't support Bluetooth, some Bluetooth-related commands were apparently left behind, and are still accessible to attackers. In this case, we found a classic Stack-Based Buffer Overflow" - maybe those cameras don't have the Bluetooth code in their firmware, or different versions of it that aren't vulnerable?
#17
Photo Mechanic might be worth a look though doesn't have any face recognition AFAIK. Also, Honeyview for image viewing.
#18
Quote from: KelvinK on April 04, 2019, 09:24:35 AM
No, I guess he just pressed "delete" instead of modify  :D Happened to me once.

Yes I can confirm that if you delete your own message it goes to a hidden "Hall of Shame" section, which is the same place all the spam ultimately ends up. It can be confusing initially when moderating to see seemingly good posts mixed in with the spam (apologies to a1ex who had to help clean things up that time I restored a bunch of seemingly good posts that had in fact been intentionally deleted!).

If anyone does accidentally delete something substantial, feel free to drop me a PM and I'll restore it for you.
#19
My 5D4 work-in-progress repo is here: https://bitbucket.org/chris_miller/ml-fork/commits/all

It's digic 6+ of course but has some similar challenges to the ones faced with digic 7 so may well still be helpful.
#20
Quote from: calle2010 on March 29, 2019, 09:24:09 AM
I'm a bit disappointed that I couldn't find a larger chunk of memory. I think logging will be very limited with only 6MB.

Don't be too disappointed by this, I had the same problem with the 5D4. I created a workaround using a ring buffer that gets periodically flushed and hence allows continuous logging. With this I managed to get 45MB+ log files with 8MB of buffer.

It is still a bit experimental and not yet merged into the ML repo, but if you're willing to get your hands dirty with the code you can try merging in the relevant parts from my repo. The initial commit was this one but there were a few more improvements and fixes added later, so you'll probably want to cherry pick those bits too if you want to give it a try. Note also that it was only hacked together for the 5D4, but should be trivial enough to use on other cameras.
#21
Camera-specific Development / Re: Canon 5D Mark IV
March 02, 2019, 06:57:33 PM
Some good progress today:

#22
Camera-specific Development / Re: Canon 5D Mark IV
February 28, 2019, 01:33:15 AM
I managed to get continuous logging working using a smaller buffer on the 5D4 (https://bitbucket.org/chris_miller/ml-fork/commits/branch/5d4-112). This gave me a 30MB log file recorded over 50 seconds worth of camera workout. The log is available here: http://www.redyeti.net/test/DEBUGMSG-5D4-big.7z

I've also made a few attempts to get MMIO logs but without success so far. I can generate MMIO logs in QEMU but I've had no luck with the real camera even after trying a few different memory areas for the MMIO log buffers - the camera always just hangs, reboots, or gives an Err 80 after a few seconds. I've still got other ideas to investigate/test to try and get this working, but any tips appreciated.

#23
Camera-specific Development / Re: Canon 5D Mark IV
February 20, 2019, 01:46:41 AM
I scanned for free memory regions (as per the 80D). The log file fills up extremely quickly on the 5D4 even with filtering, so I hacked the logging code a bit so the memory results overwrite the start of the log file instead of disappear off the end. Across 4 attempts I found these common unused areas:


42600000-42FFFFFF = 10MB
4B100000-4BCFFFFF = 12MB
5D100000-5D6FFFFF = 6MB
60B00000-614FFFFF = 10MB
7C500000-7D0FFFFF = 12MB


The areas aren't as big as the 80D unfortunately, nevertheless I managed to capture a few 12MB logs here using 0x7C500000: http://www.redyeti.net/test/5d4-112-logs-4.7z

I tried to get an MMIO log but my first/only attempt came up empty, will hopefully have time to try that again in a couple of days.
#24
Camera-specific Development / Re: Canon 5D Mark IV
February 17, 2019, 01:43:36 PM
Thanks a1ex, the updated BOOTF5D4.FIR and ROM dumper are both now working fine on 1.1.2. I'm happy to report that the bootflag being enabled on the 5D4 doesn't seem to introduce nearly as much lag as it does on the 5D3.

Logging on the physical camera with 1.1.2 works using the code from my 5d4-112 branch, as does the intervalometer. I'll generate more/better logs and chip away at the various other outstanding tasks (as per replies #397, #417, 80D thread #468) when I can, but my spare time is sadly very limited so anyone else willing to join in is most welcome to do so.
#25
Camera-specific Development / Re: Canon 5D Mark IV
February 17, 2019, 12:12:37 PM
I finally found some time to update the rest of the stubs for 1.1.2. I've hit a problem getting further though.

Quote from: a1ex on January 01, 2019, 12:00:03 AM
Please find the FIR to enable the boot flag on the 5D Mark IV:

BOOTF5D4.FIR (works on any*) firmware version; source code).

The above doesn't work on 1.1.2. When I try to run it I get "Firmware older than Ver 1.1.2 is on memory card. Delete old file and update using a later verison". a1ex, could you please create a BOOTF5D4.FIR with a higher version number for me to try?