Running a camera without lenses, patching the FLASH idea.

RaduP

926

« on: 18 / February / 2021, 19:16:44 »

Advertisements

11 years ago I got the idea to use a small Canon camera either without lenses or with the lenses permanently extended for long timelapse photography.
One problem is that the camera retracts/extends the lens each time it is powered on, and this uses precious electricity (which can be scarce if the camera is in a remote area) and it will wear off the mechanical parts so it will eventually fail.

I did some research on and off on how to trick the camera to think the lens is in a certain position but haven't managed to get anything useful done. Meanwhile I wrote a few timelapse programs for Android and ESP32 Cam, but every once in a while I think about how nice it would be to do that with a Canon camera.
Looking at the forum, I've only found hardware tricks, but nothing software (besides for disabling the IS check).

So I came up with an idea (not sure if it is feasible) which I wanted to check with the more experienced people here.

Basically, it would be a script (or even a binary) that searches for the function/functions which verify the lens/sensors being ok, and then patches them in ROM (using some returns or nops at strategic places).
I have some cameras that support CHDK which are kind of broken, so I am willing to take the risk to totally brick it. Is there any reason why this wouldn't work?

Logged

reyalp

14080

Re: Running a camera without lenses, patching the FLASH idea.

« Reply #1 on: 19 / February / 2021, 17:13:48 »

Quote from: RaduP on 18 / February / 2021, 19:16:44

Basically, it would be a script (or even a binary) that searches for the function/functions which verify the lens/sensors being ok, and then patches them in ROM (using some returns or nops at strategic places).

In principle, sure. In practice, doing the reverse engineering to figure out what to change is likely a huge effort. It's not like there's generally a single "is the lens OK" check, there are dozens of interdependent tasks that all have asserts at various points based on the assumption the lens system is OK. You can't just ignore the assert, because the code is expecting some value that's derived from a functioning lens. So you not only have to ignore all the error checks, you have to provide valid dummy data everywhere it might be used.

You *can* hook assert calls and even continue from them with enough hairy stack and PC manipulation (example https://chdk.setepontos.com/index.php?topic=13451.msg142512#msg142512), but it's definitely non-trivial.

Logged

Don't forget what the H stands for.

RaduP

926

Re: Running a camera without lenses, patching the FLASH idea.

« Reply #2 on: 22 / February / 2021, 08:57:42 »

My idea is to just patch the asserts, so it won't call that code (replace the jump with a nop or something). Then the camera will think the lens is working ok and populate the right structures with the right values. So each command the camera sends to the lens subsystem will come up as totally ok.

Logged

reyalp

14080

Re: Running a camera without lenses, patching the FLASH idea.

« Reply #3 on: 22 / February / 2021, 13:12:50 »

Quote from: RaduP on 22 / February / 2021, 08:57:42

My idea is to just patch the asserts, so it won't call that code (replace the jump with a nop or something). Then the camera will think the lens is working ok and populate the right structures with the right values. So each command the camera sends to the lens subsystem will come up as totally ok.

Well, from my time spent poking around these firmwares, the logic and interdependencies are complicated enough to make it extremely difficult in practice. But if you can make it work, more power to you, and please publish the results

Some related work in this area: https://chdk.fandom.com/wiki/User:Srsa_4c/Working_with_a_broken_camera

If I were to attempt it, I would use methods that don't involve re-writing flash (like hooked / copied tasks, assert hooks and cache hacks) for as much of the initial research as possible. It would also be desirable to have a working camera of the same model. Older models and models without IS are likely to be simpler.

Logged

Don't forget what the H stands for.

RaduP

926

Re: Running a camera without lenses, patching the FLASH idea.

« Reply #4 on: 22 / February / 2021, 19:33:11 »

Ok, so my idea is this (in pseudocode)
Start the program as a modified blinker.

Search for all the assert calls in ROM
Save the original bytes for each assert somewhere (might be hard to do without access to SD, so this step is optional)
Patch them with a NOP instruction.
Write the changes to flash

Assuming I do this (and do it properly), would there be a problem for a non modified camera? Would anything break?

Logged

reyalp

14080

Re: Running a camera without lenses, patching the FLASH idea.

« Reply #5 on: 22 / February / 2021, 21:00:05 »

Quote from: RaduP on 22 / February / 2021, 19:33:11

Search for all the assert calls in ROM
Save the original bytes for each assert somewhere (might be hard to do without access to SD, so this step is optional)
Patch them with a NOP instruction.

Assuming I do this (and do it properly), would there be a problem for a non modified camera? Would anything break?

If you made DebugAssert itself NOP, and don't hit any asserts, than nothing will break. There is no need to modify ROM to do this, it can be done trivially by just setting an assert hook that does nothing. However, it will absolutely not do what you want.

Look at real disassembly.

You would need to identify the condition that leads to the assert, and then modify the logic to take the the non-failing path.

Code: [Select]

if(some_condition)
 do_something
else
 DebugAssert()

Or worse

Code: [Select]

x = some_function()
if(x == bad_value)
 DebugAssert()
else
 do_something(x)

In both of these these cases, returning from the assert would wander off into never never land. In the second one, NOPing out the if condition would just lead to cascading failures later. And that doesn't even get into the stuff involving multiple tasks. What happens when one task signals it wants the lens to move, and then waits for an event flag set by the task that talks to the hardware?

To actually do what you propose, you would need to run your camera with the lens disabled, identify the first thing that makes it crash, find the appropriate workaround for that specific case, and repeat, until every case was identified.

Logged

Don't forget what the H stands for.

RaduP

926

Re: Running a camera without lenses, patching the FLASH idea.

« Reply #6 on: 22 / February / 2021, 21:07:07 »

Ok, I forgot about the multitasking component.
My idea was/is, if I remove the lens of the camera the firmware will try to do stuff with the lens, and check for errors. For example (and this is made up, I didn't recently look at the disassembly code).

Code: [Select]

move lens
check for errors in moving the lens
if errors found, assert and stop
else
assume the lens moved

Logged

reyalp

14080

Re: Running a camera without lenses, patching the FLASH idea.

« Reply #7 on: 22 / February / 2021, 21:51:53 »

Quote from: RaduP on 22 / February / 2021, 21:07:07

Ok, I forgot about the multitasking component.
My idea was/is, if I remove the lens of the camera the firmware will try to do stuff with the lens, and check for errors. For example (and this is made up, I didn't recently look at the disassembly code).

IMHO, if you spend a little time with the real disassembly (or de-compilation), you'll have your answer. If it's as straightforward as you hope, that's where you'll need to start. If it's not, you'll know

To me, the kind of logic you suggest isn't readily identifiable. Instead, you have hundreds of thousands to millions of lines of assembly code, with only vague hints as to the general purpose (from things like eventprocs, task names and filenames in asserts) with checks scattered throughout. The meaning of any individual check is usually not apparent without significant analysis.

Logged

Don't forget what the H stands for.

RaduP

926

Re: Running a camera without lenses, patching the FLASH idea.

« Reply #8 on: 22 / February / 2021, 21:56:55 »

I am not expecting things to be that simple

If I decide to start doing the research, I think one good strategy would be to look for all the MMIO access, and try to find the motors and optic sensors for the lens. Once this is done, it should be relatively easy to see which things should be modified.

Logged

reyalp

14080

Re: Running a camera without lenses, patching the FLASH idea.

« Reply #9 on: 23 / February / 2021, 14:07:45 »

Quote from: RaduP on 22 / February / 2021, 21:56:55

If I decide to start doing the research, I think one good strategy would be to look for all the MMIO access, and try to find the motors and optic sensors for the lens. Once this is done, it should be relatively easy to see which things should be modified.

My impression is on most cameras the Mecha CPU (one or sometimes more separate MCUs) is responsible for most of the actual control. The interface between it and the main CPU might provide a fairly well defined place to override things, but how it's actually structured isn't obvious to me, and I've never investigated it in depth.

The mecha firmware itself might also be an interesting target, although I'm not clear how accessible it is from the main firmware.

edit: Some previous investigation https://chdk.setepontos.com/index.php?topic=11316.msg140563#msg140563

« Last Edit: 23 / February / 2021, 15:35:13 by reyalp »

Logged

Don't forget what the H stands for.