$300 offered to developer

Started by 5D3shooter, November 11, 2013, 05:24:06 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

hjfilmspeed

Sorry if this is off topic i will gladly move it

"obviously what's needed is not a $300 payment, but a $3000 insurance in case anything goes wrong upon trying the bootflag removal."
Says it best.

Removing it will be possible. But, like the current alphas, it has to be somewhat as full proof as possible so even idiots like me have a lower risk of bricking a 3k cam. In fact installing it was dangerous and i made many idiotic mistakes installing it (yeah i know im a firmware looser) yet my cam is safe. dont know how. I even tried following the steps to uninstall the stable 2.3 ml for 5d2 on the nightly 5d3 version to see if i could uninstall, which was essentially re installing the bootflag again, which made my 3k 5d3 go bonkers and lock up. I pulled batt right away and some how i have a working camera..... i saw stars then passed out. when i woke up i was shooting raw video =)

dont know how that didnt kill my camera. its a classic example that people dont read everything they should. i have to say its because ML developers have carefully and patiently constructed these amazing full proof builds that my cam is still alive. so while i would love the remove bootflag for selling purposes, 300 doesnt seem enough to rush the development. I feel like its and elaborate puzzle in which all of it peaces need to be stable before that final piece is placed.

painya

@hjfilmspeed
I bet there are people who have made much worse mistakes than you have and are still shooting RAW video. Maybe their experience is the key to this issue, and how much a 5d can take.
Good footage doesn't make a story any better.

hjfilmspeed

Well Im not going to push it ha ha. I personally feel more comfortable waiting for the stable release of the firmware. Im sure the developers will eventually work something out but i definitely dont think it should be rushed. I know that these cams are strong but the code is so delicate. and its wise to have a respectful fear of that. Its way more detailed then people assume and there are thousand of combinations of code that could lead to a bug or a cash. I just dont feel we should rush them or pressure them by money. sorry im a party pooper on this one.

mva

Quote from: hjfilmspeed on November 13, 2013, 05:21:31 AM
I personally feel more comfortable waiting for the stable release of the firmware. Im sure the developers will eventually work something out

What makes you so sure that a safe way of resetting the bootflag (i.e., one that can be released to the public by ML) is possible? If it isn't, there will never be a stable release that includes a way of resetting the bootflag.

engardeknave

Get back in the free speech zone. [fires mace]

hjfilmspeed

the mods have to do this so topics dont get berried.

And Im sure they will find a way to disable boot disk safely. But more power to the dev that gets it to work safely, gets 300 bucks and doesnt break there 5d3. Its good to remember to help the devs not push them.

I have a lot of respect for the devs and the mods.

mva

Quote from: chris_overseas on November 12, 2013, 01:00:29 AM
Interesting. I was wondering about the signing process but if it isn't public knowledge then that would explain why I couldn't find anything about it! I take it that means there are only certain people who have the knowledge to make a valid fir :( 

Could anyone offer a brief, non-technical description/explanation of what the signing process is and who decides whether or not to make it public?

dmilligan

Quote from: mva on November 13, 2013, 08:32:35 PM
Could anyone offer a brief, non-technical description/explanation of what the signing process is and who decides whether or not to make it public?

this is probably OT, but here's my best understanding:

As do most all other companies, canon uses a cryptographic means to verify that the fir file has come from them. This is known as code signing. You can read more about the specifics here. Basically a cryptographic hash is made of the code to be executed and 'signed' using private keys known only to canon. The camera verifies that the code it's about run in the firmware update process, is actually from canon and valid, if it isn't it refuses to run it (if we change something in the fir file a little bit, the hash would be different and the signing will fail, it will be apparent to the camera that the fir file has been tampered with). This whole process is actually designed to thwart attempts like ML, but ML has somehow managed to defeat this measure and figure out the keys (I think by analyzing firmware dumps, see here: https://groups.google.com/forum/?hl=en%7C7D#!msg/ml-devel/ASabsRbv9vQ/IKsMn3PPqPQJ). These keys are the intellectual property of canon, and so they can't be made public or risk lawsuits from canon and ML getting shutdown. That means only a privileged few know the keys (basically anyone who is smart enough to dump and analyze the firmware and figure out the keys) and they can't be shared.

Not all cameras actually verify the code signatures, it's mostly only the newer ones (I read this somewhere on the wikia, but I can't find it now, there is actually a list of cameras and info about which ones check and which ones don't).

More info here:
http://magiclantern.wikia.com/wiki/Firmware_file
http://magiclantern.wikia.com/wiki/DryOS_boot_process
http://magiclantern.wikia.com/wiki/GPL_Tools/ARM_console

maxotics

Thanks dmilligan, very interesting!  I'd just like to point out that it's probably not a good reason to say the keys are the intellectual property of Canon.  It's actually near impossible (if not impossible) to figure out a private key assuming it is of suitable strength (key length).  The whole idea of these keys is that they CANNOT be figured out so the public key can float freely.  So they either figured out the key because it was low strength OR someone at Canon slipped it to them.  I'd wager that if these are strong keys, the latter is what happened.  So the real risk of releasing these keys to any developer is that it might force Canon's hand into finding and prosecuting the person who released confidential information (which I don't think they want to do, presently). 

This is pertinent to the thread because the OP's request is essentially asking that any proof that a potentially stolen key was not used to unlock the camera.  I think that valid.  I hope I'm not going off-topic, but Alex's concerns that some development may lead to bricked cameras should not be dismissed lightly.  Should ML ever brick many of these cameras Canon would have no choice but to change the keys on all cameras leaving the factory.  I can't see them fixing any of the bricked cameras, or servicing ones that ran ML.   That they're letting cameras leave the factory with a broken, or hackable key probably already makes them very nervous, because, in a sense, it can be argued that the behavior implies that they approve of ML.

In short, the senior devs have made the right decision in limiting access.  But Alex's cautionary words should haunt everyone just the same.


Marsu42

Quote from: dmilligan on November 13, 2013, 10:29:46 PM
This whole process is actually designed to thwart attempts like ML, but ML has somehow managed to defeat this measure and figure out the keys (I think by analyzing firmware dumps, see here: https://groups.google.com/forum/?hl=en%7C7D#!msg/ml-devel/ASabsRbv9vQ/IKsMn3PPqPQJ).

Oh my, reading this link Canon seems to employ symmetric XOR encryption which is as weak as it gets, obviously they have a heart for ML and don't use strong asymmetric cryptography for fw verification :-)

Quote from: maxotics on November 13, 2013, 10:46:37 PMThe whole idea of these keys is that they CANNOT be figured out so the public key can float freely.  So they either figured out the key because it was low strength OR someone at Canon slipped it to them.

Edit: Here's an interesting link I just randomly google'd which implies Canon did experiment with stronger encryption, but it seems they really decided against it ... so Canon didn't *directly* slip the keys to ML, but didn't hinder brute-forcing them: http://chdk.setepontos.com/index.php?topic=5328.0

Quote from: maxotics on November 13, 2013, 10:46:37 PM
In short, the senior devs have made the right decision in limiting access.  But Alex's cautionary words should haunt everyone just the same.

I agree, I cannot imagine an xor encryption key can be copyrighted, but it is a sound decision not to wake sleeping dogs and help someone else hack the 1dx or brick series of cameras, resulting in Canon service costs, resulting in them getting annoyed by ML.

Edit: Yes, this is ot, but still interesting :-) and vaguely relates to the bootflag issue and why Canon allows ML to work at all.

dmilligan

If source code can be IP then a cryptographic key can definitely be IP. This brings to mind a certain incident a few years back, the details are a little hazy but I think it was the keys for HDCP or something like that, they got posted all over the internet and the particular company suffered from the http://en.wikipedia.org/wiki/Streisand_effect

dmilligan

additionally, DRM related things actually have more protection under the law than plain old copyright (The DMCA makes it a criminal matter, not just a civil one). A cryptographic key used for code signing (no matter the underlying algorithm, in fact that's the whole point, it doesn't matter if the DRM is easily thwarted, it's still illegal to circumvent it) definitely falls in that category.

mva

Thanks dmilligan, maxotics, and Marsu42! Great stuff! Over my head to a considerable degree, but fascinating and enlightening. To my mind it's very on-topic (not surprisingly, since I asked the question) because a huge part of what has been frustrating me at any rate about this bootflag issue (and I suspect some others as well) is the almost complete lack of information that has been forthcoming from A1ex and others about the nature of the problem and prospects for a solution since June, and near complete silence about why there's been no information. The situation, summed up by Audionut in August, has been:

Quote from: Audionut on August 17, 2013, 11:18:00 PM
The developer says thay it's not safe to remove the bootflag.  That's all there is to it.

That, indeed, is all there has been to it. But these posts of yours are helping me begin to make a bit more sense of it.

maxotics

Quote from: dmilligan on November 13, 2013, 11:30:53 PM
A cryptographic key used for code signing (no matter the underlying algorithm, in fact that's the whole point, it doesn't matter if the DRM is easily thwarted, it's still illegal to circumvent it) definitely falls in that category.

Absolutely, Canon is not obliged to use the strongest crytography available.  If you "break the seal" you're on your own.

Marsu42

Quote from: dmilligan on November 13, 2013, 11:30:53 PM
additionally, DRM related things actually have more protection under the law than plain old copyright (The DMCA makes it a criminal matter

It might not be the same in every part of the world, but alas, you are correct, at least Germany has followed suit in 2003 and it's illegal to remove an encryption even if it's trivial xor, except for security research that is. However I just looked at the 6d fw update download in Germany and it never says anywhere that you are forbidden to decrypt the fw (or re it, for that matter) - but I might have missed the small print somewhere.

Quote from: dmilligan on November 13, 2013, 11:15:34 PMIf source code can be IP then a cryptographic key can definitely be IP.

Thanks for the link - but has this been seen through in international courts (see https://en.wikipedia.org/wiki/AACS_encryption_key_controversy)? It is breaking the encryption that is illegal, but if Canon protects their fw with "123" or "password" or "Canon" the question is if the sharing itself of this key as IP is illegal in any case, or only if in connection with this purpose, or only if you actually use it for decryption ... I'm no lawyer as you might have guessed, but common sense seems to dictate that outlawing a word or number is not entirely without problems like in the aacs case.

Bottom line is: If Canon was set upon it, they wouldn't rely on questionable legalities but simply use asymmetric cryptography for new cameras and ML would be dead in the water. Since they don't do that, we can safely assume they don't want to and thus it would be surprising if they started to cause problems for ML with the bootflag.

mva

Quote from: dmilligan on November 13, 2013, 10:29:46 PM
Not all cameras actually verify the code signatures, it's mostly only the newer ones (I read this somewhere on the wikia, but I can't find it now, there is actually a list of cameras and info about which ones check and which ones don't).

It would be interesting to see that list.

So are there relatively safe ways of disabling the bootflag on any of these other newer cameras which verify the code signatures besides the 5D3, e.g. with suitable disableboot.fir files? It has been my understanding that only the 5D3 lacks a safe way of disabling the bootflag. And if it is just the 5D3, is it more likely that that's so because there are special problems with the 5D3 case (i.e., aside from the fact that the camera is much more expensive, which makes testing riskier), or just because A1ex hasn't gotten around to it yet?

And if the main barrier to progress on this issue is the 5D3's $3K price tag, how can we ever get past this? Will we need to take up a collection to buy A1ex a used 5D3 for testing? :)

5D3shooter

Could always just buy a 5D3 with cash from a big retailer with a great return policy  ;)  "I just took it out of the box and put the battery in.. AND NOTHING!"

lol.. only kidding guys

maxotics

Quote from: 5D3shooter on November 14, 2013, 08:46:37 AM
Could always just buy a 5D3 with cash from a big retailer with a great return policy  ;)  "I just took it out of the box and put the battery in.. AND NOTHING!"

lol.. only kidding guys

What do you mean, when our wives go shopping they do it all the time :) 

5D3shooter


1%

Solution is to run the obvious code from don't click me (some risk) or leave the boot flag enabled and don't put in a bootable disk. 99% chance the next buyer will put ML on it (5D3 has 0 reason to not record raw) or will never notice if they don't insert a bootable disk. The canon service center could care less about ML or not. Spend the $300 on a lens or for someone to port the stubs/etc. Boot loader code for 1.2.1 and 1.2.3 is probably unchanged so if coutts had ported the previous more or less should focus on the dump/update.

mva

Thanks 1%, but that's a solution for dealing with the lack of a solution to the problem of providing a safe way to disable the bootflag. :)

melia

Don't know if this is a right place but I will add an extra 150 $ whoever fixes the RAW video out for both ML Controller and DSLR controller  apps on 7D.

1%

Quoteproblem of providing a safe way to disable the bootflag.

Well no 5DIII so I can't do much here.


QuoteRAW video out for both ML Controller and DSLR controller  apps on 7D.

What do you mean raw video out? The LV over USB? Last I recall it only froze while recording, I'll look at it when I get back to see what does that but now no more DSLR controller for me as GPS went bye bye before I left. 2 GPS stolen in 2 months... at least they didn't break the windows.

melia

Quote from: 1% on December 01, 2013, 11:13:01 PM

What do you mean raw video out? The LV over USB?

Yep just like it does when on h264.. LV works in Droid APP...  but freezes if your try to enable raw.

melia