Hello
I treat this thread as DEVELOPMENT focused, so please keep non-technical questions and all the excitement aside and use it strictly for the technical discussion.
As most of you have been able to witness, FOTA seems the right track for bypassing bada bootloader security.
During the Android porting we have found ourselves in the situation where we developed a fairly simple asm code for the purpose of loading and booting Android.
A successful attempt has some important limitations, though. One major is strict dependency from the bada bootloader level 3 (BL3) that we used to interact with the hardware for us and provide filesystem abstraction. I feel that main reason for that happening was coming directly from what was the biggest advantage in the beginning - simplicity of building crafted FOTA module from asm.
Since the time I've made the discovery of the FOTA vulnerability (as described initially here) and after I provided sample framework for building crafted FOTA file for fasmarm (see here) only b.kubica and Rebellos took over and made it into the FOTA booting Android. That approach required installing specific bootloader version in the phone and used patched I9000 secondary bootloader (SBL), as we needed it to correctly initialize the display for the kernel.
The first attempt to make it more universal was proposed, but it still only introduced additional abstraction layer for BL3 calls and was using the very same assembler framework.
I'd like to change something again and therefore, I've scratched a new framework for building FOTA. This time, it is using a proper gcc toolchain and quickly jumps a level higher in abstraction - into C/C++ code. Linker scripts provide abstraction for building the right FOTA file headers and footers for:
- S8500 running bada 1.x
- S8500 running bada 2.x
- S8530 running bada 1.x
- S8530 running bada 2.x
All four targets are built from same source files with a single 'make'. I tested all that by writing FLOCK (that still is BL3 dependent but written in C).
In my opinion, it should allow us to get into development of the modules handling hardware, filesystem, etc. by ourselves (or simply building that from external source codes handling that) resulting in full independence from version of the bootloader installed.
Now we get to the right question - do you have suggestions as for what opensource bootloader project we should integrate into FOTA? I've done a proof-of-concept integration of u-boot and it compiles flawlessly (of course, getting it to run is whole other story as there's lots of low-level initialization procedures to be rewritten). Please answer with some supporting arguments as it's not voting and would prefer a discussion and picking the right solution.
The second thing - is there anybody with the know-how and interest in this development? I'd like to share the code and support it only in some spare time, so it would be perfect if somebody took it over.
Again, please keep this thread clean - strictly technical discussion here.
Regards,
mijoma
I treat this thread as DEVELOPMENT focused, so please keep non-technical questions and all the excitement aside and use it strictly for the technical discussion.
As most of you have been able to witness, FOTA seems the right track for bypassing bada bootloader security.
During the Android porting we have found ourselves in the situation where we developed a fairly simple asm code for the purpose of loading and booting Android.
A successful attempt has some important limitations, though. One major is strict dependency from the bada bootloader level 3 (BL3) that we used to interact with the hardware for us and provide filesystem abstraction. I feel that main reason for that happening was coming directly from what was the biggest advantage in the beginning - simplicity of building crafted FOTA module from asm.
Since the time I've made the discovery of the FOTA vulnerability (as described initially here) and after I provided sample framework for building crafted FOTA file for fasmarm (see here) only b.kubica and Rebellos took over and made it into the FOTA booting Android. That approach required installing specific bootloader version in the phone and used patched I9000 secondary bootloader (SBL), as we needed it to correctly initialize the display for the kernel.
The first attempt to make it more universal was proposed, but it still only introduced additional abstraction layer for BL3 calls and was using the very same assembler framework.
I'd like to change something again and therefore, I've scratched a new framework for building FOTA. This time, it is using a proper gcc toolchain and quickly jumps a level higher in abstraction - into C/C++ code. Linker scripts provide abstraction for building the right FOTA file headers and footers for:
- S8500 running bada 1.x
- S8500 running bada 2.x
- S8530 running bada 1.x
- S8530 running bada 2.x
All four targets are built from same source files with a single 'make'. I tested all that by writing FLOCK (that still is BL3 dependent but written in C).
In my opinion, it should allow us to get into development of the modules handling hardware, filesystem, etc. by ourselves (or simply building that from external source codes handling that) resulting in full independence from version of the bootloader installed.
Now we get to the right question - do you have suggestions as for what opensource bootloader project we should integrate into FOTA? I've done a proof-of-concept integration of u-boot and it compiles flawlessly (of course, getting it to run is whole other story as there's lots of low-level initialization procedures to be rewritten). Please answer with some supporting arguments as it's not voting and would prefer a discussion and picking the right solution.
The second thing - is there anybody with the know-how and interest in this development? I'd like to share the code and support it only in some spare time, so it would be perfect if somebody took it over.
Again, please keep this thread clean - strictly technical discussion here.
Regards,
mijoma
