eduperez
Coutts
from what I understand, with magic_off, magic lantern still loads, but no tasks are started. why not implement something similar to this? this way it's a temporary off.
All current functionalities of 400plus are designed around a proxy, that intercepts messages as they travel around the camera; if we just let the messages pass untouched, and do nothing else, the camera should behave exactly as before the hack. We would still be doing all the initialization at the booting process, but I do not see how to avoid that (unless we do call eventproc_DisableBootDisk, obviously).
It would be temporary, but the user would need to have access to a computer with a card reader in order to enable the hack back again.
I think Coutts means what we discussed last night... and i spoke with Alex to give me some light on magic_off in ML...
let's say the user wants to disable the hack... we will call this NoHackFlag...
my idea was to catch the NoHackFlag in early phase of booting, actually in the first possible moment, so we will not initialize with our tasks and our handlers and our proxies ... instead we will call the original rom_Start().
the result will be: the hack is still in the RAM, but effectively disabled, because no one actually is using it.
this is the safest way to disable the hack temporarily, without touching the ROM!
unfortunately we cannot detect NoHackFlag in that earlier phase, because we have nothing initialized at that moment... no FileIO, nothing we can really use to detect the NoHackFlag.
so Alex(or someone else on ML) found the best possible solution for NoHackFlag.
in ML they detect the half-shutter button hold when they power-on. if there is half-shutter holded on power-on, then they call the original FW.
there is another unfortunate for us here... we do not know the RAM addresses of any button... so far we know only the Blue and Red LED addresses in RAM...
when i spoke with Alex, he told me, that they use MemorySpy technique to catch the buttons... so i will implement something like that in the future, but there are other more important stuff for now ...
the solution for now would be to have the hack permanently disabled with eventproc_DisableBootDisk()
and if the user wants the hack again, he will need to go through the testfir.bin procedure.
we will need to warn the users when they want to disable the hack, to do this on charged battery, because if the battery drains while this routine works (it changes ROM addresses), then the camera can be bricked ...
