Safe Hacking Toolbox

Started by a1ex, November 20, 2012, 10:59:15 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.


I think it's good to know what not to do and what things require special care when digging into ML code - so here's a quick draft. Suggestions or relevant links are welcome.

Device safety


- Safe Hacking - or how to practice Safe Hex (must read!)

Persistent modifications

- Be very careful when changing properties (camera settings and events) - they are saved in NVRAM. A bad setting can cause permanent malfunction.
- Disable prop_request_change calls for early ports! Only enable them after checking ALL prop_request_change calls used in ML.

Memory usage

- For new ports: ML should reserve some memory for itself, and mark it as used (so Canon code will never overwrite it). Currently it's done by shrinking the memory pools used for malloc or AllocateMemory.
- Memory usage: malloc pool should have at least 100K free, AllocateMemory pool should have at least 1MB free. If not, remove some features or try to use shoot_malloc.
- Malloc checking: (work in progress)
- Stack checking: look in Debug->Show Tasks.
- Don't create too many tasks / semaphores / message queues / property handlers / other objects.

CPU usage

- Look in Debug->Show CPU usage.
- Use msleep, semaphores and message queues - these will allow the other tasks to run.
- Don't use tasks with very high priority (lower values = higher priority). These may block Canon code.

Don't slow down or block Canon code

- Don't do complicated things from property handlers (don't make them wait - you will slow down Canon code). Setting variables and changing other properties is OK. Taking pictures is not (call schedule_remote_shot instead).

- Don't use (big) delays in gui_main_task (this includes all event handling functions). If your code takes too much time to run, consider running it on a separate task.

- When you hook from state objects, make sure your code finishes really fast (especially in LiveView hoks). Otherwise you will slow down the frame rate and cause jitter (not funny at all for video users).

Error handling

- Be very careful disabling Canon's error handling (side effects are unknown, but can be bad).
- Check for errors on: malloc, AllocateMemory, file I/O, things that return a pointer...
- Use the ASSERT macro (it will save small log files whenever assertions are broken).

At shutdown

- DryOS tasks will shutdown at:
    - next msleep call
    - next take_semaphore call
    - next msg_queue_receive call, but ONLY if the message queue is empty

- Don't pump events faster than the process from the other end can process them (otherwise the camera will not turn off).
- Use if (ml_shutdown_requested) to know when to stop (in most cases you won't need it).

If you screw it up

- Ask before trying any of the following!
- Diagnostic tools

Legal safety

- Check your local law about reverse engineering, copyright and digital locks!
- Read EFF's FAQ on reverse engineering (also here)
- Do not copy Canon code! (it's copyrighted)
- Do not publish things like encryption keys or copyrighted code! You can only publish what's needed to develop an interoperable program (e.g. document Canon's API, which is not copyrightable - see here).
- Do not agree to EULAs that prohibit reverse engineering! (tip: the firmware updates provided by Canon Europe do not contain anti-reverse engineering clauses at the time of writing this).
- Be careful not to infringe any patents (e.g. don't implement a MP3 player feature).
- Be careful not to mass-brick cameras! (this will cost Canon a lot; hint: Why Panasonic want to block hacked firmware)

Happy Hacking!


When changing properties, try first in C modes if your code crashes. In C modes the camera often doesn't save them to flash.
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!


Quote from: a1ex on November 20, 2012, 10:59:15 AM
Don't use (big) delays in gui_main_task (this includes all event handling functions). If your code takes too much time to run, consider running it on a separate task.

What about shoot_task (CBR_SHOOT_TASK in modules)? I saw that the autoexpo module creates a separate task for what seems to be very little code, so I wonder if this is necessary - or can a user-created task apart from shoot_task be run more often to do things that need a quick result?

Btw "if your code takes too much time to run" isn't a very specific advice :-o

Quote from: a1ex on November 20, 2012, 10:59:15 AM
Happy Hacking!

"Hack" should be banned from ml vocabulary because people get the impression that it's about breaking into Canon's fw, sneakily using their intellectual property and doing no original work at all... I'd prefer "coding" :-p