This is mainly for ROM developers - allows you to "restart" init process with your custom binary and custom rc scripts. Technically using code injection the code to call "execve("/init", {"/init", NULL**, environ);" is injected and the environ variables are read from /proc/1/environ by the binary.
Hi Skirlax, I wuould love to have more delucidations about the 2nd-init and the sh hijack (of wich I've didn't find anything)
Now, I'm interested on creating a custom init.rc for my Rom, but where to start?
In what does it differ from the Ramdisk method of dexter? (in both good and bad way)
Would love to have some informations because I'm very intrested in this type of hack, and maybe some links or file example wuould help me
It's a "evolution" of that method (that was being used by dext3r and nadlabak in older CM) - so no cons.
What they did was starting the "init" instance for a second time - thus there were two init instances; the original one "frozen" and the second one doing the job. What you call "Ramdisk method" - this is nothing else than replacing the init, init.rc, etc. from the signed ramdisk image. 2nd-init only changes the way how the new init is called - which is by injecting code to the original init basically to restart itself (look on execve manual) - but if you replaced it, it will restart into the new one.
"sh hijack" - in init process, a script is called in very early stage (called "init" as well) - basically it calls /system/bin/sh. Now the "sh" doesn't have to be the shell, it can be your own program which will do the necessary things to call 2nd-init and ensures that future calls to sh are handled normally (mounts sh to the real shell binary). An example is shown in the newest CM.
oh MANY thanks
Now I'm starting to understand something xD I'll read execve manual ASAP;
Just a curiosity, INIT calls /system/bin/sh, But when I create a rom,The backup will not contain /system/bin (and even /sbin) so how can I call a Custom sh? (I mean, I have to create a Rom by update.zip or there is another method)?