Database Users

Global Subclassing

OK, I know that global subclassing of windows is formally not supported. However, I have a few ideas of how to do it. First, I was wondering if anyone knows whether or not the internal window structure is similar to the internal structure used on Windows NT.
Also, I was wondering if anyone knows how to locate the internal window table. I figure that it's contained somewhere in GWES as it contains the USER functions. I've been researching CreateWindowEx, but I haven't been able to land on anything specific.
Thanks!

Here is info that I've digged in last 10 minutes. It can be incorrect.
chmckay said:
First, I was wondering if anyone knows whether or not the internal window structure is similar to the internal structure used on Windows NT.
Click to expand...
Click to collapse
It is completely different.
As far as I've seen from coredll decompilation the HWND is internally translated to internal CWindow class by an internal "static CWindow* CWindow::coredllPwndFromHwnd(HWND__*)" function defined in twinuser.obj file in thunks.lib in PlatformBuilder. I've dumped it from a COREDLL.PDB file from old PlatformBuilder 4.0beta. Here is it, cleaned from unnecessary function prototypes:
Code:
struct CWindow
{
struct CWindow* m_pcwndNext;
struct CWindow* m_pcwndParent;
struct CWindow* m_pcwndChild;
unsigned m_sig;
struct CWindow* m_pcwndOwner;
struct CWindow* m_pcwndOwned;
struct CWindow* m_pcwndNextOwned;
struct CWindow* m_pcwndRestore;
struct tagRECT m_rc;
struct tagRECT m_rcClient;
void* m_pgdiwnd;
void* m_pgdiwndClient;
void* m_pgdiwndClientUpdate;
struct tagRECT m_rcRestore;
struct _GENTBL* m_ptblProperties;
unsigned m_dwState;
struct ScrollBarInfoInternal* m_psbii;
DWORD* m_pszName;
struct MsgQueue* m_pmsgq;
DWORD m_himc;
unsigned m_grfStyle;
unsigned m_grfExStyle;
struct CWindowClass* m_pwc;
long m_lID;
long m_lUserData;
void* m_hprcCreator;
void* m_hthdCreator;
void* m_hprcWndProc;
int (*m_pfnWndProc)(HWND__*, DWORD, DWORD, int);
struct HRGN__* m_hrgnWindowRgn;
struct HRGN__* m_hrgnVisible;
struct HRGN__* m_hrgnUpdate;
struct HRGN__* m_hrgnClientVisible;
struct HRGN__* m_hrgnClientUpdate;
struct HMENU__* m_hmenu;
void* m_hprcDestroyer;
struct CWindow::__unnamed::__unnamed m;
unsigned m_grfBitFields;
DWORD m_rgdwExtraBytes[0];
};
The structure may have been changed in the current version of OS.
The code of coredllPwndFromHwnd() function taken from iMate 1.72 ROM:
Code:
.text:01F6E65C sub_1F6E65C ; COD
.text:01F6E65C ; sub
.text:01F6E65C 10 40 2D E9 STMFD SP!, {R4,LR}
.text:01F6E660 FE 24 C0 E3 BIC R2, R0, #0xFE000000
.text:01F6E664 2C 00 9F E5 LDR R0, =unk_1FC65AC ; this is a "g_dwGwesBase" variable
.text:01F6E668 00 10 90 E5 LDR R1, [R0]
.text:01F6E66C 01 40 82 E0 ADD R4, R2, R1
.text:01F6E670 1C 10 9F E5 LDR R1, =0x574E4457 ; Magic value? It is in m_sig member.
.text:01F6E674 0C 00 94 E5 LDR R0, [R4,#0xC]
.text:01F6E678 01 00 50 E1 CMP R0, R1
.text:01F6E67C 57 0E A0 13 MOVNE R0, #0x570
.text:01F6E680 08 00 80 13 ORRNE R0, R0, #8
.text:01F6E684 00 40 A0 13 MOVNE R4, #0
.text:01F6E688 72 0C 00 1B BLNE SetLastError
.text:01F6E68C 04 00 A0 E1 MOV R0, R4
.text:01F6E690 10 80 BD E8 LDMFD SP!, {R4,PC}
I can upload somewhere the complete dump of all structures from coredll, gwes, nk. But they are taken form old PlatformBuilder, because latest version has this data removed from PDB files.
I don't know the address that containf the head of this linked list, but probably it starts from the desktop window. So you can get CWindow of desktop and enumerate windows with m_pcwndNext/m_pcwndChild members.
The other problem is that we cannot determine the g_dwGwesBase value that is added to HWND to determine CWindow pointer.
One idea. You can try "GetWindowLong" to get data from CWindow structure. But its predefined offsets look very strange.

Mamaich,
Thank you VERY much. That was just the information I needed! I've managed to locate the class information and successfully subclass a window globally on the emulator (my cradle is at home, so I can't test this on my device).
Here's what I've learned that you might be interested in:
the g_dwGwesBase variable is actually a pointer to the virtual memory location of gwes.exe. Also, the 0xfe000000 value is specific to the processor. In this case, the value is (hwnd & ~0xfe000000), while on the x86/emulator platform, it is (hwnd & 0x1fffffff). I don't have access to the MIPS or SH3 libraries (as I don't have a full copy of Platform Builder).
Anyway, this is what the coredllPwndFromHwnd() function amounts to:
DWORD *wnd = (hwnd & ~0xfe000000) + g_dwGwesBase;
if( wnd[3] == 0x574e4457 )
return wnd;
else {
SetLastError(0x578);
return NULL;
}
The 0x574e4457 is not processor specific (as it appears in the x86 libs). Also, you easily replace the "+ g_dwGwesBase" with this:
DWORD *wnd = (DWORD*)MapPtrToProcess((LPVOID)(hwnd & ~0xfe000000), hHandleToGWES);
Thank you again for your help. Now, the only thing I have left to do is get the magic numbers for MIPS and SH3 and I'll be all set.

chmckay said:
The 0x574e4457 is not processor specific (as it appears in the x86 libs).
Click to expand...
Click to collapse
0x574e4457 == 'WNDW', so it would be the same for all platforms. I also don't have MIPS/SH3 libraries for platformBuilder.
The value ~0xfe000000 == 0x1fffffff, so it should also be the same an all platforms (it looks similar to HANDLE_ADDRESS_MASK, which is also same for all, the only difference is that HANDLE_ADDRESS_MASK clears the lowest 2 bits of address).

I can't believe that I didn't catch that the values were the same . Anyway, I looked up HANDLE_ADDRESS_MASK and I'm a little concerned that it doesn't appear in ksshx.h. I guess that begs the question as to whether or not it is used on that platform. I'll do some investigating and see what I can find.
As far as the lower two bits are concerned, it's probably not a big deal. Using Spy++ on the emulator shows that EVERY window handle has the least significant byte set to 0. So, maybe the HANDLE_ADDRESS_MASK is the ticket.
Thank you again for your help. I've managed to do what I need to do. I wouldn't have been able to get this far without you. Thanks!

Apparently there is one more thing that I need in order to have my project working perfectly. In Gwes, there is a structure that contains some data that I need to manipulate in order to achieve some consistency. Unfortunately this structure is contained in a global variable that is not exposed to any outsider.
What I'm wondering is this: if I have a dll injected into the Gwes process, is there a way that I could locate the address of that global variable on various devices? I guess what I'm looking for is more of a technique than anything else. If this were a desktop binary, I would just access a specific location, but since the OS is apparently recompiled for different devices, that's not feasible as the location changes based upon different variables.
So, if anyone can help me out, I'd appreciate it. Thanks again!

chmckay said:
What I'm wondering is this: if I have a dll injected into the Gwes process, is there a way that I could locate the address of that global variable on various devices?
Click to expand...
Click to collapse
Typically you should search for such address using signatures of code that accesses it. It is easier to explain by an example.
For example you may determine the value of g_dwGwesBase by searching for the code that accesses it. Look at the coredllPwndFromHwnd function. At its end it has an off_1F6E698 variable that contains the address of g_dwGwesBase. This is a function code:
Code:
coredllPwndFromHwnd:
10 40 2D E9 STMFD SP!, {R4,LR}
FE 24 C0 E3 BIC R2, R0, #0xFE000000
2C 00 9F E5 LDR R0, =g_dwGwesBase
00 10 90 E5 LDR R1, [R0]
... skipped ...
72 0C 00 1B BLNE SetLastError
04 00 A0 E1 MOV R0, R4
10 80 BD E8 LDMFD SP!, {R4,PC}
; End of function coredllPwndFromHwnd
57 44 4E 57 aWdnw DCB "WDNW"
AC 65 FC 01 off_1F6E698 DCD g_dwGwesBase
You see that the needed address is located after the end of this function after the "WDNW" constant. "WDNW" {57 44 4E 57} is located in lots of places in coredll, but only in one place it is prefixed by "LDMFD SP!, {R4,PC}" (10 80 BD E8) command . So you may search for bytes {10 80 BD E8 57 44 4E 57} and the next DWORD after them would contain the address of g_dwGwesBase.
This function is the same in different OSes on different devices, so this method would work on every PocketPC with ARM CPU.
You should carefully select the signatures. In your program you should keep a set of signatures for most common versions of ROMs, for different CPUs, etc.
To search for a giver pattern you may use this function:
Code:
#define _XX_ '?'
int RabSearch(unsigned char *SearchString, int StringLen,
unsigned char *SearchBuff, int BuffSize)
{
register int i,j;
if (BuffSize < StringLen) return -1;
for(i=0;i<(BuffSize-StringLen);i++)
{
for(j=0;j<StringLen;j++)
{
if (
(SearchString[j] != _XX_) &&
(SearchString[j] != SearchBuff[i+j])
)
break;
}
if (j==StringLen) return i;
}
return -100;
}
This code is taken from [email protected].
You may place "?" char in a buffer to indicate that this byte should be ignored on search.
This method is commonly used by crackers to create "universal" cracks that work with different versions of a given program

DiMaggio bootloader

I've found it in dell axim x51. I've reversed the bootloader code and discovered that the Wallaby commands are present in it also, but they can be enabled only in some special way (they call it "serial debug" mode). There's an appliation that comes with dell devices romupdate tool called EnterBootLoader.exe. It reboots the device to bootloader in the RRU monitor mode:
.text:00011000 ; int __stdcall WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPWSTR lpCmdLine,int nShowCmd)
.text:00011000 WinMain ; CODE XREF: start+28p
.text:00011000 ; DATA XREF: .pdata:00014000o
.text:00011000
.text:00011000 nOutBufSize = -0x18
.text:00011000 lpBytesReturned = -0x14
.text:00011000 InBuf = -0x10
.text:00011000 BytesReturned = -0xC
.text:00011000
.text:00011000 STMFD SP!, {R4,LR}
.text:00011004 SUB SP, SP, #0x10 ; nOutBufSize
.text:00011008 MOV R0, #'U'
.text:0001100C MOV R3, #'R'
.text:00011010 STRB R0, [SP,#0x18+InBuf] ; 55
.text:00011014 STRB R0, [SP,#0x18+InBuf+1] ; 55
.text:00011018 MOV R0, #0x2EC
.text:0001101C STRB R3, [SP,#0x18+InBuf+2] ; 52
.text:00011020 MOV R3, #' '
.text:00011024 MOV R4, #0
.text:00011028 STRB R3, [SP,#0x18+InBuf+3] ; 20
.text:0001102C ORR R0, R0, #2 ; dwMilliseconds
.text:00011030 STR R4, [SP,#0x18+BytesReturned]
.text:00011034 BL Sleep
.text:00011038 ADD R3, SP, #0x18+BytesReturned
.text:0001103C LDR R0, =0x101012F ; dwIoControlCode
.text:00011040 STR R3, [SP,#0x18+lpBytesReturned]
.text:00011044 MOV R2, #4 ; nInBufSize
.text:00011048 MOV R3, #0 ; lpOutBuf
.text:0001104C STR R4, [SP,#0x18+nOutBufSize]
.text:00011050 ADD R1, SP, #0x18+InBuf ; lpInBuf
.text:00011054 BL KernelIoControl
.text:00011058 MOV R0, #0
.text:0001105C ADD SP, SP, #0x10
.text:00011060 LDMFD SP!, {R4,PC}
.text:00011060 ; End of function WinMain
In RRU monitor mode only 3 commands are available:
rru_u - update image.
rru_r - restore image.
rru_b - exit the rru monitor.
The handler for "rru_r" command just shows "Image Restore" instead of "Image Update" and then just calls the "rru_u" command code.
Does anyone know how to switch to "serial debug" mode?

Sleep() hook question

Hi all,
just for fun I'm trying to hook the Sleep() function (on WM6) through SystemAPISets[] array. While the hook is working fine, my "fake" Sleep() function seems to have some problems. I have cannibalized the real Sleep() function from coredll.dll but I have one problem:
Code:
.text:03FBE0A8 Sleep ; CODE
.text:03FBE0A8
.text:03FBE0A8 04 E0 2D E5 STR LR, [SP,#var_4]!
.text:03FBE0AC 04 D0 4D E2 SUB SP, SP, #4
.....
.text:03FBE0C4 2C 30 9F 15 LDRNE R3, =unk_1FFF824
.....
.text:03FBE0F0 1E FF 2F E1 BX LR
.text:03FBE0F0 ; End of function Sleep
As you can see at address 0x03FBE0C4 a value is loaded into R3 from an address (in this case 0x01FFF824) but I'm not able to retrieve the value contained there because it seems to be relocated on my phone. Do you have any suggestion on how to proceed to get the right value inside R3?
Thanx a lot in advance to everyone!

[Q] Memory address unknown in IDA Pro?

Hi guys,
I'm trying to disassemble and analyse a WinMo 6.5 Dll that manages the battery, in order to port it to Android.
So far I managed to understand the structure of the file, and I am 99% sure where the value I'm looking for is
I used IDA Pro 5.5 and 6.0, tried many loading options but unfortunately I cannot get the value decoded by IDA Pro
See here:
Code:
BatteryPDDGetStatus (addr= .text:10005E48)
STMFD SP!, {R4-R6,LR}
MOV R6, R1
MOV R5, R0
LDR R4, =unk_1000C228
MOV R1, 0x1388 ; dwMilliseconds
LDR R0, [R4] ; hHandle
BL WaitForSingleObject
CMP R0, #0
BLNE GetLastError
[B]LDR R0, =unk_1000C384[/B]
LDR R2, [R0]
LDR R3, [R2]
STR R3, [R5]
LDR R3, [R2,#4]
STR R3, [R5,#4]
LDR R3, [R2,#8]
You see this line: LDR R0, =unk_1000C384
how can you tell IDA pro to look for it?
Address 1000C384 of the dll is full of zero, and 0x1000C384 is not a valid address in my device.
In the code, this value is supposed to be the shared memory address where to read the data.
In my device, SMEM start address is 0X0FF00000 and virtual address is 0xACC00000.
maybe its a wrong IDA setting? maybe this is a parameter sent when DDL is being loaded?
Attached the DLL I used, if anybody has a clue how to go further i thank you very much in advance, it's been a long time I searched for this, but cannot find it by myself...
Thanksssss

[Guide] Patch libandroid_runtime to allow suhide to work. (Pixel/Pixel XL)

This thread is about hiding root. Feel free to discuss anything ranging from MagiskHide to suhide. See the suhide patching instructions below.
Introduction:
With the November security patches, Google back-ported a security feature that allows only a certain whitelist of filesystem sockets to be used.
This is the same feature that prevents suhide from working.
This particular commit is here:
https://android.googlesource.com/pl...8be33b0bedec211708c4525b9d3f3b4effb385c^!/#F0
If you are building CM or AOSP, all you need to do is revert this commit.
However, for binary builds a more direct patching approach is needed.
As I said earlier:
Fenny said:
The basis of my binary patches is to remove the function calls to
Code:
RuntimeAbort(JNIEnv* env, int line, const char* msg)
and remove a later reference to
Code:
gOpenFdTable
that was causing a crash.
Click to expand...
Click to collapse
ARM
Let me get into a bit more detail, and we can start with the error message that zygote spits out with an unpatched version of the file:
"Unable to construct file descriptor table"
We see that in the commit here:
Code:
+ // Close any logging related FDs before we start evaluating the list of
+ // file descriptors.
+ __android_log_close();
+
+ // If this is the first fork for this zygote, create the open FD table.
+ // If it isn't, we just need to check whether the list of open files has
+ // changed (and it shouldn't in the normal case).
+ if (gOpenFdTable == NULL) {
+ gOpenFdTable = FileDescriptorTable::Create();
+ if (gOpenFdTable == NULL) {
+ RuntimeAbort(env, __LINE__, "Unable to construct file descriptor table.");
+ }
+ } else if (!gOpenFdTable->Restat()) {
+ RuntimeAbort(env, __LINE__, "Unable to restat file descriptor table.");
+ }
+
pid_t pid = fork();
When searching for references to the string in the disassembly of the file:
Code:
.text:000C8CC8 ADD R2, PC ; "Unable to construct file descriptor tab"...
.text:000C8CCA B loc_C8CDE
.text:000C8CCC BL sub_C845C
.text:000C8CD0 CBNZ R0, loc_C8CE2
.text:000C8CD2 LDR.W R2, =(aUnableToRestat - 0xC8CE0)
.text:000C8CD6 MOV R0, R4
.text:000C8CD8 MOV.W R1, #0x1D6
.text:000C8CDC ADD R2, PC ; "Unable to restat file descriptor table."
.text:000C8CDE BL sub_C873C
.text:000C8CE2 BLX fork
So, we're looking at the instruction "BL sub_C873C" as "RuntimeAbort" we know it's the right one because it is a conditional call just before the fork.
Which in hex is:
Code:
FF F7 2D FD
The simplest patch is to remove the function call entirely by replacing this with the arm equivalent of nop.
Code:
00 00 00 00
However, that breaks things because the file descriptor variable now contains a null where a reference should be.
Code:
.text:000C8D08 LDR.W R0, [R12]
.text:000C8D0C LDR.W R9, [R0,#8] ; <- Crash happens here.
.text:000C8D10 CMP.W R9, #0
.text:000C8D14 BEQ loc_C8D38
Hex:
Code:
DC F8 00 00 D0 F8 08 90 B9 F1 00 0F
So, since we always need to take the BEQ branch, we're going to replace the whole lot of functions with:
Code:
.text:000C8D08 MOVS R0, #0
.text:000C8D0A MOVS R0, #0
.text:000C8D0C MOVS R0, #0
.text:000C8D0E MOVS R0, #0
.text:000C8D10 MOVS R0, #0
.text:000C8D12 CMP R0, #0
Hex:
Code:
00 20 00 20 00 20 00 20 00 20 00 28
ARM64
The ARM64 patches are the same idea, but different opcodes:
In this example sub_881B8 calls our RuntimeAbort function, so first we nop out the call to that.
Replace:
Code:
.text:000000000014EF8C ADD X2, X27, #[email protected] ; "Socket name not whitelisted : %s (fd=%d"...
.text:000000000014EF90 MOV W4, W20
.text:000000000014EF94 MOV W0, #6
.text:000000000014EF98 MOV X19, #0
[B].text:000000000014EF9C BL sub_881B8[/B]
.text:000000000014EFA0 B loc_14ECA0
Hex:
Code:
87 E4 FC 97
Replace with:
Code:
.text:000000000014EF8C ADD X2, X27, #[email protected] ; "Socket name not whitelisted : %s (fd=%d"...
.text:000000000014EF90 MOV W4, W20
.text:000000000014EF94 MOV W0, #6
.text:000000000014EF98 MOV X19, #0
[B].text:000000000014EF9C NOP[/B]
.text:000000000014EFA0 B loc_14ECA0
Hex:
Code:
1F 20 03 D5
Next, we patch away the crash:
We want to take the CBZ X23, loc_151AC0 jump.
Replace:
Code:
.text:00000000001510CC ADRP X9, #[email protected]
.text:00000000001510D0 LDR X10, [X9,#[email protected]]
[B].text:00000000001510D4 LDR X23, [X10,#0x10][/B]
.text:00000000001510D8 CBZ X23, loc_151AC0
.text:00000000001510DC LDR X19, [X23,#0x18]
.text:00000000001510E0 CBZ X19, loc_1511F4
.text:00000000001510E4 BL sub_88468
.text:00000000001510E8 MOV X22, X0
.text:00000000001510EC ADRP X11, #[email protected] ; "/dev/null"
.text:00000000001510F0 ADD X24, X11, #[email protected] ; "/dev/null"
.text:00000000001510F4 B loc_151174
Hex:
Code:
57 09 40 F9
Replace with:
Code:
.text:00000000001510CC ADRP X9, #[email protected]
.text:00000000001510D0 LDR X10, [X9,#[email protected]]
[B].text:00000000001510D4 MOV X23, #0[/B]
.text:00000000001510D8 CBZ X23, loc_151AC0
.text:00000000001510DC LDR X19, [X23,#0x18]
.text:00000000001510E0 CBZ X19, loc_1511F4
.text:00000000001510E4 BL sub_88468
.text:00000000001510E8 MOV X22, X0
.text:00000000001510EC ADRP X11, #[email protected] ; "/dev/null"
.text:00000000001510F0 ADD X24, X11, #[email protected] ; "/dev/null"
.text:00000000001510F4 B loc_151174
Hex:
Code:
17 00 80 D2
Finally, nop out the second call to RuntimeAbort (ARM optimized these two calls into one, whereas arm64 split them into two subfunctions.)
Replace:
Code:
.text:0000000000151AAC MOV X0, X25
.text:0000000000151AB0 MOV W1, #0x1D3
.text:0000000000151AB4 ADD X2, X4, #[email protected] ; "Unable to construct file descriptor tab"...
[B].text:0000000000151AB8 BL sub_150264[/B]
.text:0000000000151ABC B loc_150F10
Hex:
Code:
EB F9 FF 97
Replace with:
Code:
.text:0000000000151AAC MOV X0, X25
.text:0000000000151AB0 MOV W1, #0x1D3
.text:0000000000151AB4 ADD X2, X4, #[email protected] ; "Unable to construct file descriptor tab"...
[B].text:0000000000151AB8 NOP[/B]
.text:0000000000151ABC B loc_150F10
Code:
1F 20 03 D5
TL;DR
I have this working on 7.1/7.1.1.
The gist:
Patching ART binaries required. System modification required. (can't bind mount modified ART or suhide breaks).
Known issues:
UI prompts to allow new or updated root apps do not display when suhide is enabled. (7.1.1+)
SuperSU 2.79 SR1 and above use incompatible selinux contexts with Suhide 0.55 and below.
JAYNO20 said:
I can confirm this works on the 5" Pixel device as well. This is NOT limited to just the XL.
Click to expand...
Click to collapse
Downloads:
Here are a couple patched versions:
libandroid_runtime_pixelxl_NDE63V.tar
libandroid_runtime_pixelxl_NMF26O.tar
libandroid_runtime_pixelxl_NMF26Q.tar
libandroid_runtime_pixelxl_NOF26V.tar (Reported working with NOF27B/C, N2G47E/J/K)
You WILL need to match your builds up.

Finally!
Cant wait for the write up!

ghostENVY said:
Finally!
Cant wait for the write up!
Click to expand...
Click to collapse
Well, since you can't wait... I will do a full write-up when I get home, until then, you can grab the modded Android runtime files from NDE63V: libandroid_runtime_pixelxl_NDE63V.tar
Basic process is: Replace modded files in system, fix permissions, flash suhide.

Will this work on NMF26Q?

Also, NMF26O?

Ker~Man said:
Will this work on NMF26Q?
Click to expand...
Click to collapse
JAYNO20 said:
Also, NMF26O?
Click to expand...
Click to collapse
ART libs look like they can be patched for both of those builds, but I haven't done them yet.
The old libs I posted probably won't set your phone on fire, but it is very likely you would have weird issues even if it doesn't just bootloop, which is what I would expect to happen.

JAYNO20 said:
Also, NMF26O?
Click to expand...
Click to collapse
So, after replacing the first of the four files, my phone froze immediately and now boots to an all black screen. Just fu**ing great...
Any ideas other than a full flash of stock???

Fenny said:
ART libs look like they can be patched for both of those builds, but I haven't done them yet.
The old libs I posted probably won't set your phone on fire, but it is very likely you would have weird issues even if it doesn't just bootloop, which is what I would expect to happen.
Click to expand...
Click to collapse
Any chance you'll get around to patching those as well?

JAYNO20 said:
Any chance you'll get around to patching those as well?
Click to expand...
Click to collapse
+1. Would be really nice...

Ker~Man said:
+1. Would be really nice...
Click to expand...
Click to collapse
I'd love to be able to use Android Pay again...

Ker~Man said:
So, after replacing the first of the four files, my phone froze immediately and now boots to an all black screen. Just fu**ing great...
Any ideas other than a full flash of stock???
Click to expand...
Click to collapse
Yeah, you're not going to be able to replace those files while you're booted into the normal system.
If you have a backup of the file restore it in recovery. If not, you'll probably need to flash a stock system partition.
It is likely that you did not get a chance to set permissions on the file when you replaced it. You can try going into recovery and try setting the correct owner and permissions on the file.

I'm so looking forward to this write up, thank you for your work!

Great job!

The anticipation is killing me

MyNarwhalBacon said:
The anticipation is killing me
Click to expand...
Click to collapse
Likewise!

Added some patched versions to the OP.
Write-up still pending. Working on an auto patcher for the files.

Fenny said:
Added some patched versions to the OP.
Write-up still pending. Working on an auto patcher for the files.
Click to expand...
Click to collapse
Nice work. Will the Q files work with the O update?
---------- Post added at 02:47 AM ---------- Previous post was at 02:34 AM ----------
Also, will this be ok to flash to the Pixel? (NOT XL)

Hi, great work. Is it doable for other brands (Sammy, Moto, Huawei...)? Any advice, paths to follow? Thx
Echoe™ team member / S7E

I tried on O update, bootloops.

You sir are the man. I'm excited to be able to root and still play Pokemon go