[KERNEL] [KEXEC] Kernel EXECution for locked devices [N900V] [WIP]

[the_rooter]

Stuff like is device specific as far as I know, but could lead to breaking ground for other devices. It took us almost a year to get this far thanks to @hsbadr and his group of bad ass'.

How exactly would this work. Just flash aosp room that has custom kernel and then it works?

 

[Sheradrax]

How exactly would this work. Just flash aosp room that has custom kernel and then it works?

From my understanding kexec allows for another, non stock, kernel to be loaded on top of ours so we can run an aosp based rom. There is lots of info in the op. I would suggest taking a look at it. Hsbadr will direct us as needed for instructions once he is ready.

 

[the_rooter]

Thanks man. I am gonna read up on that. There is one thing that I noticed wasn't asked. If we use let's say a kernel on top of another wouldn't that in reality slow our devices?

 

[Surge1223]

I assumed you had compiled the kexec kernel modules already before opening this thread. Getting them compiled is the easy part and building a custom kernel shouldn't even be on the table right now.
Also just because the kernel panics when trying to execute kexec doesn't mean the kexec kernel loaded, checking kmsg you can confirm.

You should be trying to get the kexec hijack to to work with just the stock kernel. Getting the actual kexec hijack to work is the problem, sure you can get it to start by executing the binary while in the ramdisk but you have to cleanly shutdown most drivers before the jump to the seconds kernel. Plus a lot of other sanity checking and system monitoring.

Also you shouldn't have had to patch anything, the kexec kernel module would have loaded just fine being cross compiled..as long as you gave the correct addresses for kernel, tags etc. That's why it was so great that these kernels allowed insecure modules.

 

[hsbadr]

I assumed you had compiled the kexec kernel modules already before opening this thread. Getting them compiled is the easy part and building a custom kernel shouldn't even be on the table right now.
Also just because the kernel panics when trying to execute kexec doesn't mean the kexec kernel loaded, checking kmsg you can confirm.

You should be trying to get the kexec hijack to to work with just the stock kernel. Getting the actual kexec hijack to work is the problem, sure you can get it to start by executing the binary while in the ramdisk but you have to cleanly shutdown most drivers before the jump to the seconds kernel. Plus a lot of other sanity checking and system monitoring.

Also you shouldn't have had to patch anything, the kexec kernel module would have loaded just fine being cross compiled..as long as you gave the correct addresses for kernel, tags etc. That's why it was so great that these kernels allowed insecure modules.

1. I agree that the remaining part is the hardest...
2. I don't agree that kexec module shouldn't be patched. This means that you've NOT compiled VZW KK kernel from source since NC2/NC4 kernels are compiled with MODVersions meaning that your cross-compiled module against the kernel source code published by Samsung won't be loaded (failed to load, invalid argument etc) before you apply required patches!
3. Building a guest kernel is what I need for debugging now!!
4. The required hijack is considered & some patches have been applied for that. Moreover, I think Safestrap/hijack could be modified for that purpose.
5. I've already updated Safestrap & contacted @Hashcode several times asking for permission with no response!!!
6. I'm testing better alternatives, but I post only successful phases.
7. A lot have been done by a beginner dev like me with no contributions!!!

Please share your experience or contribute to the thread if you've any useful info. From day one, I invited everyone to contribute & asked for no credits (no one responded!!!),

All devs are invited to contribute to this thread & all credits are for the entire team. I hope @Hashcode would help us or even lead the team, as he's the most experienced dev in this area & he did it before for other device(s).

 

[hsbadr]

(Mod Snip)

If you're interested to contribute to the thread, you don't have to wait for me. I've started the thread because you didn't & you shouldn't wait for me to "bring up a point of discussion" (all devs were already invited & you can do it). Moreover, if you've more experience & stuck on some point, you should share your sources/results so that we can start from that point !

 

[stryver]

@hsbadr according to michael scott(hashcode)'s statements on g+ it seems he wants other devs like yourself to continue and keep safestrap alive.



Sent from my SM-N900V using XDA Free mobile app

 

[ironfisted]

Yeah I believe it says that in his threads

 

[hsbadr]

@hsbadr according to michael scott(hashcode)'s statements on g+ it seems he wants other devs like yourself to continue and keep safestrap alive.

Yeah I believe it says that in his threads

yeah, I read that. I understand that Safestrap is open source & I can update it, but I decided to ask for permission 1st since he may be preparing someone else to take care of his thread. I sent him a msg here & on g+ many days ago. I'll wait for some more time before releasing an updated version if there's no one else recommended by @Hashcode to update it.

I may use the hijack for kexec anyway & will give him proper credits.

 

[garwynn]

Thread Reopened with Specific Conditions

To all,

After discussions with the original poster we have cleaned and reopened the thread.

Note: Intent of this thread is being allowed for discussion of kexec and how this may be exploited successfully, primarily on the Verizon Note 3. To avoid non-dev discussion this has been moved to a Devs Only forum.

If you want to post, stay on the topic of discussing ways that this may be used, including any attempts, logs, and notes of a development nature. Anything that isn't on that very narrow topic will not be tolerated and the thread will be closed permanently if it goes south one more time.

We don't want to discourage research and exploring development options - but we don't want threads to turn into flame wars. We hope that this will find a balance between both.

If there are any questions about the actions taken in this thread including cleaning please PM me for further assistance. Thank you for your continued support of XDA

 

[KennyG123]

To add to this, before posting make sure to read the guidelines for this strictly moderated section. Sections like this were made to get XDA back to its roots of development. If you are not contributing towards the development here then please do not post. Basic questions, ETA requests, progress requests have no place in these threads. You should have some development knowledge to post in this section.

Thank you all for your cooperation and making XDA great!
Friendly Neighborhood Senior-Mod

 

[hsbadr]

Technical Details & Discussions

.
Many thanks to @garwynn & @KennyG123 for their help & support despite being very busy in RL & XDA!

I'll post some technical details very soon & I hope devs would contribute/open useful discussions for knowledge exchange. I'll also share the different kexec-module sources/patches, logs for successful phases & current problems/bugs. The progress rate for this month may be affected because I'm preparing for my PhD defense, but I'll do my best to keep you updated with all technical info & I'd be glad to discuss details with anyone interested.

The thread has been reopened with specific conditions, for devs-only discussions. You may follow the thread for progress updates, but please avoid off-topic/non-dev posts, or they'll be deleted immediately. Thanks for your understanding!

 

[hsbadr]

Technical Information

Post #2 is reserved for technical information with sources, logs & binaries. This includes kernel sources, kexec-module, kexec-tools, hijack script, required patches & current problems with logs. It's being updated; there're some sources/patches that I'm currently testing & will be posted ASAP upon success or failure.

 

[CovXX]

hsbadr if you need any help or anything shoot me a pm or maybe we can get a dedi irc channel setup, I have too much free time @ college

 

[CalcProgrammer1]

Does anyone have any information on how kexec with dt.img is supposed to work? I'm working on an alternative method using kexec-hardboot for the bootloader-unlocked variants and I can get the phone to reboot, but the kernel never runs. I've ported Tasssadar's kexec-hardboot patch as well as fixed up ram console to view the last kmsg, but upon rebooting the last kmsg is from running the kexec host kernel rather than the guest. I'm using Tasssadar's kexec-tools package.

 

[hsbadr]

hsbadr if you need any help or anything shoot me a pm or maybe we can get a dedi irc channel setup, I have too much free time @ college

Thanks! I'll for sure when I reach a ~safe phase for testing; the current phase isn't safe & needs time for debugging. Unfortunately, I'm very busy in RL nowadays, but I'll get to this ASAP.

Does anyone have any information on how kexec with dt.img is supposed to work? I'm working on an alternative method using kexec-hardboot for the bootloader-unlocked variants and I can get the phone to reboot, but the kernel never runs. I've ported Tasssadar's kexec-hardboot patch as well as fixed up ram console to view the last kmsg, but upon rebooting the last kmsg is from running the kexec host kernel rather than the guest. I'm using Tasssadar's kexec-tools package.

I'm still learning kexec & its challenges, but I'll try to answer your question as much as I can. To use kexec, device tree information needs to be passed to the kernel during boot either by specifying a DTB file or using legacy ATAGs. kexec checks that the location where it wants to load the guest kernel into memory is physically contiguous. This requires accurate memory computations + patches for kexec-tools & machine driver. You may study the code changes in these patches (as an example) to understand how/why kexec uses DTB or ATAGS & some of the problems that makes it fails to work on arm with proposed solutions.

 

[TheLoonyRebel]

I dunno how much of this helps but there's quite a bit of progress happening on the Verizon S4 front with KEXEC in this thread here:

http://forum.xda-developers.com/showthread.php?t=2500826

Some of this might be useful on our VZW Note 3 but who knows. Never hurts to point this out in hopes it can be useful.

 

[hsbadr]

I dunno how much of this helps but there's quite a bit of progress happening on the Verizon S4 front with KEXEC in this thread here:

http://forum.xda-developers.com/showthread.php?t=2500826

Some of this might be useful on our VZW Note 3 but who knows. Never hurts to point this out in hopes it can be useful.

Thanks! I'll take a look when I've some free time. I'm very busy in RL & I've already fixed the deep sleep issues on S5/N4 ports for VZW N3. I'll get to kexec very soon though b/c I want to port ASOP ROMs to locked devices. If successful, Debian will be considered too.

 

[the_rooter]

Thanks! I'll take a look when I've some free time. I'm very busy in RL & I've already fixed the deep sleep issues on S5/N4 ports for VZW N3. I'll get to kexec very soon though b/c I want to port ASOP ROMs to locked devices. If successful, Debian will be considered too.

What about a Ubuntu convert? Would this make it possible

 

[crhylove]

If it can Debian you can probably switch repos and mint or Ubuntu or whatever, but we're way getting ahead of ourselves.