I will pay the developer who provides a safe way to remove the 5D3 bootflag to the masses- $200 via paypal
My offer is until December 1st
Thanks
PS - I'm also offering a $100 to the developer who can break the 30min limit for non-raw video on the 5D3.. Can be movie restart but it must not drop frames between clips. In camera audio recording during this would also be preferred if possible.
December 1st deadline as well.
UPDATE : I urge anyone who would like to add to my rewards to post their pledge here. We all know that removing the bootflag has been a tough one, so lets make it worth their while! Dev, you will not release the files until you are paid up to ensure that everyone keeps their word on their pledge. THANKS!
I'll pitch in $100, also payable by Paypal, to a developer* for a safe way for the masses to reset the bootflag on the 5D3. Same deadline of Dec. 1.
* The developer can keep the money, put it toward a donation to ML or a charity, or anything else they choose.
Reward for 5D3 bootflag removal is up to $300!!!
Is there a reason this is important to you other than the two second delay?
Quote from: engardeknave on November 11, 2013, 07:52:45 AM
Is there a reason this is important to you other than the two second delay?
For me it's to have the ability to restore the camera to its original "unhacked" state for future resale. Others want the option of using Eye-Fi cards. And many others, I'm sure, simply don't feel comfortable making permanent changes to their 5D3s.
Quote from: engardeknave on November 11, 2013, 03:43:42 PM
Get to work.
Here is my shooter's guide for the EOS-M on this forum
http://www.magiclantern.fm/forum/index.php?topic=8825.msg82944#msg82944
I have done a tremendous about mount research into hybrid focus pixels and have posted it. I have written scripts. Here
http://www.magiclantern.fm/forum/index.php?topic=7908.msg70298#msg70298
I am about to post an open-source project that fixes Pink Dots in C#
So back to my question, what is being done about making ML a "real world" solution to RAW video? And I don't mean new features. I mean a plan and timeline to get to a stable version.
I dunno about removing the boot flag but i was planning on checking out movie restart since people were saying it stopped working. I don't think there is any way to make it seamless tho.
There are so few people to develop, that's part of the problem. As a handful of people how to we write code + documentation with the time available, then answer questions from people who didn't read the docs by choice.
If BM as a mid to large sized company is having problems with BMPCC, maybe its not so straightforward.
Quote from: 1% on November 11, 2013, 07:23:43 PM
There are so few people to develop, that's part of the problem. As a handful of people how to we write code + documentation with the time available, then answer questions from people who didn't read the docs by choice.
Absolutely 1%. If anyone knows how hard you, g3gg0, Andy and Alex work it's me ;) Although you would need to change your work priorities a little bit, nothing is possible, or worth doing, unless others start to put in the same care to create a stable build as you do in developing new features. We need more programmers and we need documentation and some sort of better recognition system.
5D3Shooter put up $200. Mva offered $100. The interest is there--the generosity of spirit. We offered you a lens a few weeks back. The question is, can enough people doing ML agree to work together to create a plan and timeline to bring the fruits of your labor to more people, I believe, would love to have it.
The question is, what would you want out of it, if you were to devote 10% of your time on creating a stable build? Or what does anyone want to take up the OP on his original offer? (Yes, BM has problems, pain is unavoidable in every pursuit. I still believe we can do a lot better).
Quote from: mva on November 11, 2013, 09:11:53 PMThe bootflag issue is one that concerns many if not most of those people, even many who feel they can live with it indefinitely.
Not to be misunderstood: I would also like to see this addressed because a) it's an psychological barrier to try ML...
... and b) to get to know why this is working on digic4-based cameras but not on 5d3/6d: If it's not for the lack of trying, I could imagine Canon intentionally changed their design so that the bootflag cannot be removed, and this would be mean they're at last taking semi-official note of ML, though not in a very commendable way.
Quote from: Marsu42 on November 11, 2013, 10:12:20 PM
I could imagine Canon intentionally changed their design so that the bootflag cannot be removed, and this would be mean they're at last taking semi-official note of ML, though not in a very commendable way.
Actually it's not this, it can be removed and quite easily (it's a single line of code), it's just that the developers are not sure what would happen to the camera if something went wrong with this call (possible permanently bricking the camera, or destroying important factory calibration settings that would be unrecoverable) and how to prevent such a thing. Nobody wants to be the developer that released code that permanently damaged somebody's $3k camera. No developer also probably wants to risk damaging their $3k camera to test such a thing.
Quote from: a1ex on June 02, 2013, 09:20:43 AM
I need to prepare a special FIR. Short answer: call("DisableBootDisk")
but you really have to double-check that you are not in LiveView (and people managed to go there during first install despite all my double-checks).
Quote from: nanomad on June 21, 2013, 09:46:52 PM
The thing is, we know what happens if you somehow manage to bypass the enable boot flag safety checks and corrupt the boot flag area. You'll have to re-flash canon stock firmware to go back to normality.
What we don't know is: what happens if the DisableBootDisk call fails on the 5D3?...Will a firmware upgrade fix it? Will it make the camera non-operational?
In the end, it's better safe than sorry.
Quote from: Marsu42 on November 11, 2013, 10:12:20 PM
... and b) to get to know why this is working on digic4-based cameras but not on 5d3/6d: If it's not for the lack of trying, I could imagine Canon intentionally changed their design so that the bootflag cannot be removed, and this would be mean they're at last taking semi-official note of ML, though not in a very commendable way.
For me the EnableBootDisk and DisableBootDisk routines on the 5D3 seem very similar to the earlier cameras' routines.
I asked before in different topics but maybe I missed the answer so could you tell me what is the difference on these new cameras in the way they handle the bootflag?
Or the first ML fw update how enables it? Is there any trick besides to call the EnableBootDisk?
If Canon wants to disable booting from the card then they can easily do it in many different ways but the routines are still there and I cannot see any sign of intentional change.
Quote from: Pelican on November 11, 2013, 11:16:58 PMIf Canon wants to disable booting from the card then they can easily do it in many different ways but the routines are still there and I cannot see any sign of intentional change.
This was just a wild guess since I didn't follow this issue, I have no intention to remove ML from my cameras. My guess that Canon wanted ML to work, but their service to detect it and thus disable the removal of the bootflag - alas, this obviously isn't it.
So thanks for digging up the comment from alex who is really missing here :-o ...
obviously what's needed is not a $300 payment, but a $3000 insurance in case anything goes wrong upon trying the bootflag removal. Well, I guess that's one advantage of using cheaper cameras and one more reason not to support the 1dx :->
Personally, I doubt anything will go wrong because Canon seems to use these for internal development, so they are bound to work rather than brick the camera - but don't quote me on this...
These are the most relevant (useful) posts I've seen on the topic so far:
http://www.magiclantern.fm/forum/index.php?topic=6035.msg44625#msg44625
http://www.magiclantern.fm/forum/index.php?topic=2602.msg28483#msg28483
http://www.magiclantern.fm/forum/index.php?topic=6035.msg78315#msg78315
http://www.magiclantern.fm/forum/index.php?topic=6035.msg78332#msg78332
So it would seem that calling "DisableBootDisk" is enough, however to do it safely the code should at least ensure that Liveview isn't running at the time the call is made.
I've just spent a couple of minutes digging around in the source. The bootflag_toggle() method in installer.c appears to disable the flag properly:
if (!lv && !sensor_cleaning && shooting_mode != SHOOTMODE_MOVIE)
call( "DisableBootDisk" ); // in movie mode, it causes ERR80 and then asks for a firmware update
There's also this code and comment in boot-hack.c
// do try to enable bootflag in LiveView, or during sensor cleaning (it will fail while writing to ROM)
// no check is done here, other than a large delay and doing this while in Canon menu
bmp_printf(FONT_LARGE, 50, 200, "EnableBootDisk");
call("EnableBootDisk");
I don't know of any reason why the 5D3 would be any different to the other cameras when it comes to making this call, I just don't think the work has been done to create a disablebootflag.fir for it yet. I don't know how to make such a .fir file myself (I'm going to try when I have some more time). Alternatively I could create an autoexec.bin that contained the code from bootflag_toggle() in it that gets triggered somewhere "sensible". Whether that is wise/safe to do I'm not at all sure...
On a related note, does anyone know how/if I can get the source to 5d3-113-bootflag.fir? Does it originate from bootflags.c, or perhaps by enabling CONFIG_DUMPER_BOOTFLAG (as in boot-hack.c)? Given time I can hopefully figure this out myself but if someone knows already and was willing to point me in the right direction that would be helpful. I want to understand what it does not just to look at the bootflag handling but also because I would like to get a dump of the 1.2.3 firmware and try to get a port to that underway.
Quote from: chris_overseas on November 12, 2013, 12:14:18 AM
I don't know of any reason why the 5D3 would be any different to the other cameras when it comes to making this call, I just don't think the work has been done to create a disablebootflag.fir for it yet. I don't know how to make such a .fir file myself (I'm going to try when I have some more time). Alternatively I could create an autoexec.bin that contained the code from bootflag_toggle() in it that gets triggered somewhere "sensible". Whether that is wise/safe to do I'm not at all sure...
On a related note, does anyone know how/if I can get the source to 5d3-113-bootflag.fir? Does it originate from bootflags.c, or perhaps by enabling CONFIG_DUMPER_BOOTFLAG (as in boot-hack.c)? Given time I can hopefully figure this out myself but if someone knows already and was willing to point me in the right direction that would be helpful. I want to understand what it does not just to look at the bootflag handling but also because I would like to get a dump of the 1.2.3 firmware and try to get a port to that underway.
Still not clear why we should worry about to call DisableBootDisk on 5D3 and should not worry on the older cameras.
Anyway, instead of create a modified autoexec.bin it would be more safe to create a disableboot.fir.
Unfortunately the signing method is not public for the new cameras so I cannot make this by myself and could not even check the code in the 5d3-113-bootflag.fir
BTW this guy claims to have done it : http://www.magiclantern.fm/forum/index.php?topic=6035.msg78315#msg78315
Quote from: Pelican on November 12, 2013, 12:46:44 AM
Still not clear why we should worry about to call DisableBootDisk on 5D3 and should not worry on the older cameras.
I haven't seen anything to suggest there is a special reason, it seems the work for the 5D3 just hasn't been done yet.
Quote from: Pelican on November 12, 2013, 12:46:44 AM
Anyway, instead of create a modified autoexec.bin it would be more safe to create a disableboot.fir.
Unfortunately the signing method is not public for the new cameras so I cannot make this by myself and could not even check the code in the 5d3-113-bootflag.fir
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 :( What about getting a dump of 1.2.3, does that also require decrypting 5D300123.FIR or can it be pulled off the camera?
Quote from: RenatoPhoto on November 12, 2013, 12:51:24 AM
BTW this guy claims to have done it : http://www.magiclantern.fm/forum/index.php?topic=6035.msg78315#msg78315
This is the third link of chris_overseas...
And there is another guy too...
Quote from: chris_overseas on November 12, 2013, 01:00:29 AM
What about getting a dump of 1.2.3, does that also require decrypting 5D300123.FIR or can it be pulled off the camera?
The bootflag fir also dumps the ROM.
If you dumped the 1.2.3 please send me a PM.
Quote from: Pelican on November 12, 2013, 01:05:57 AM
The bootflag fir also dumps the ROM.
If you dumped the 1.2.3 please send me a PM.
Yeah we were discussing that over here: http://www.magiclantern.fm/forum/index.php?topic=2602.msg87729#msg87729 I'm reluctant to upgrade to 1.2.3 and back to 1.1.3 though given I don't know if the bootflag fir will even work on 1.2.3, plus I'm slightly concerned going to 1.2.3 and back might aggravate the AFMA bug. I'm off on Safari in a couple of weeks and
really don't want to have an upset camera for the trip!
QuoteStill not clear why we should worry about to call DisableBootDisk on 5D3 and should not worry on the older cameras.
Well... if you're willing to risk it you could call this from a normal autoexec.bin and then you'd reboot to boot flag free firmware, no? Maybe can even put it on don't click me. Nothing makes it *have* to go from fir... except if you don't have a boot flag set as no code loads.
QuoteIf you dumped the 1.2.3 please send me a PM.
There should be a subs.s for 1.2.3 floating on the forum... I saw it posted by coutts. I can't port it because I have no 5DIII, otherwise it would be on the new FW already.
Quote from: 1% on November 12, 2013, 09:06:41 AM
There should be a subs.s for 1.2.3 floating on the forum... I saw it posted by coutts. I can't port it because I have no 5DIII, otherwise it would be on the new FW already.
Are you sure? I know he did the stubs.S for 1.2.1, haven't seen anything about 1.2.3 though:
http://www.magiclantern.fm/forum/index.php?topic=5695.msg61657#msg61657
Also I still don't understand what's required to get an initial ROM dump of 1.2.3. Will running the 5d3-113-bootflag.fir work with it?
All the off topic discussion got move here: http://www.magiclantern.fm/forum/index.php?topic=9296.0
Keep this thread on topic. Discuss moral issues in the thread linked.
Quote from: Audionut on November 12, 2013, 06:55:40 PM
Keep this thread on topic. Discuss moral issues in the thread linked.
You're the mod with the power, but I have to say I disagree on this because the topic is "$300 offered to developer" with no further specification, so it seems to me discussing this and what is more important for a feature request topic - the amount of money or what it is about at all - actually is on topic.
Further specification is in the OP. Subject title is limited in character length and is no excuse to justify off topic conversation.
I'm not saying you can't discuss things. Just keep this thread about the topic at hand.
This is the feature request section, not let's discuss whatever topic comes to hand. Hence why I moved the relevant discussion to general chat.
Quote from: 5D3shooter on November 11, 2013, 05:24:06 AM
I will pay the developer who provides a safe way to remove the 5D3 bootflag to the masses- $200 via paypal
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.
@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.
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.
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.
Get back in the free speech zone. [fires mace]
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.
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?
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 (http://en.wikipedia.org/wiki/Code_signing). 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
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.
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.
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
additionally, DRM related things actually have more protection under the law than plain old copyright (The DMCA (http://en.wikipedia.org/wiki/Digital_Millennium_Copyright_Act) 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.
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.
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.
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 (http://en.wikipedia.org/wiki/Digital_Millennium_Copyright_Act) 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.
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? :)
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
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 :)
No solution, huh?
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.
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. :)
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.
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.
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.
So?
I'll see how it goes when I get back. Either reslock or one of the hacks does it.