Well, don't get too excited yet. I haven't done this kind of stuff in a while, but quite a bit of stuff has already been automated for me. It's mostly a matter of how long this will take me.
The thing is that this kind of work falls into the realm of Embedded Systems which is not your usual sort of software engineering because it usually involves working closer to the hardware than in application programming. Basically it's more like developing a Windows device driver than writing an application in Visual Basic or something.
In addition, the vendor doesn't intend for people to do any of this so they provide no documentation. So you have to take stuff apart (reverse engineer) in order to figure out what to do, whereas a vendor that expects you to develop software extensions will just give you exact instructions on what to do. So in addition to understanding the architecture and assembly language, you also have to understand DISassembly and analysis well enough to take the firmware apart.
That's why it's hard for someone who knows C, Java, VB, etc to catch on to all this because those languages are most often used to write applications for operating systems that insulate you from the hardware with many layers of abstraction, and come with nice documentation for the uppermost layers. Embedded systems are small though so there is usually not enough space and power for all those abstraction layers to make things easy for the programmer. As a result you usually end up with something like a layer of function calls written in assembly which can then be called by C code. Then at the very least you get to write the rest in C instead of asm.
As far as what other people can do....
It looks like 1.01b is almost exactly the same as 1.02b. I'm going to do 1.02b first since I have a camera with 1.02b, but once I do that it should be pretty easy (from what I can tell) to generate a 1.01b image with very little work. It may be a while, but when I get the 1.01b image then I'll need someone with a 1.01b camera to test it.
