Related
Hi guys,
i am doing some research regarding the subject and would be apreciate somebody providing any clue how to re-construct a password generation algorithm.
What I achieved so far:
I was able to disassemble a password function, it checks for three passwords -
Pass, Pass1 and SecurityPass.
The first one is BOOTLOADER, but it is not a big deal as it does not provide any kind of advanced access.
The second password is generated by system and that is where I need a hand to re-construct this function.
Third one seems to be checking for a flag in mem and it doesn't really check any user input at all.
Below I provide some disassembled code with my comments :
STMFD SP!, {R4,R5,LR}
SUB SP, SP, #0x20
MOV R5, R0 ; r0 contains function argument (ptr on user password string)
CMP R1, #2 ; r1 kinda function type or so one, if it is not 2 then go to exit function
BNE error_9ADC
LDR R4, =0x91F00840 ; checks if command is locked after the number of incorrect intetns
LDRB R3, [R4]
CMP R3, #0xF ; 15 wrong intents
BCS cmd_lock_9AB4
LDR R1, =0x91F2D4E0 ; system original password - source address
MOV R2, #0x20 ; ' ' ; length
ADD R0, SP, #0x2C+pass_buff_2C ; r0 = *var_2C - destination address
BL move_block_mem ; copy password to var_2C - function does copy of mem block length from src to dest
ADD R0, SP, #0x2C+pass_buff_2C ; r0 = *var_2C
BL passw_calc_2 ; var_2c will contain generated password
LDR R1, =0x900324F4 ; BOOTLOADER string
LDR R0, [R5,#4] ; user password
BL compare_r0_r1 ; compare two strings
MOVS R3, R0
LDREQ R0, =0x91F2D7D9 ; Flag of Pass. set 1
MOVEQ R1, #1
MOVEQ R2, #6
STREQB R1, [R0]
LDREQ R1, =0x900324EC ; show message - Pass.
BEQ loc_9A9C ; jump to print message HTCS Pass. .... HTCE where HTCS means start and HTCE means end of message body
if user password is not bootloader then compare with system generated password
LDR R0, [R5,#4] ; user password
ADD R1, SP, #0x2C+pass_buff_2C ; system generated password
BL compare_r0_r1 ; compare two strings
MOVS R3, R0
MOVEQ R0, #0
STREQB R0, [R4] ; Reset counter of wrong passwords to 0 to unblock command
MOVEQ R1, #1
LDREQ R0, =0x91F2D7E0 ; Flag1 of Pass1. set 1
MOVEQ R2, #7
STREQB R1, [R0]
LDREQ R1, =0x900324E4 ; Pass1. string
BEQ loc_9A9C ; jump to print message HTCS Pass1. .... HTCE where HTCS means start and HTCE means end of message body
etc.
~~~~~~
~~~~~~
~~~~~~
_________________________________________________________
What I actually need is somebody helps me with passw_calc_2 function and some memory relocation stuff during bootloader phase to understand what information goes to address 0x91F2D4E0.
I have IDA idb file (ver 4.9) if somebody would like to join and help with this stuff.
P.S. forgot to mention that my device is blue angel one - i-mate PDA2k.
It is easier to create a SuperCID SD-card or change your CID to 11111111 (it is SiperCID on BA). This would unlock all bootloader commands.
mamaich said:
It is easier to create a SuperCID SD-card or change your CID to 11111111 (it is SiperCID on BA). This would unlock all bootloader commands.
Click to expand...
Click to collapse
Checked through but I couldn't find any reference how to do that for BA. Not quite sure that the unlock tool for Universal will work for BA ...
As far as I know this unlocking method requires full access to a device, doesn't it ? Any clue what to do in case if a device is locked by password ? Hard reset is not an option because I need the information on the device intact.
Probably my assumptions were wrong , but the main idea was to get into BL mode then to enable extended set of commands and finally use these commands to obtain content of the device memory (DOC) or/and to remove password protection on the device by changing a register value.
But thanks any way for information, I have to think how to adapt CID method for my needs.
flywhc makes an adapter driver to support GFMAPI for HTC devices. This project makes all FM RDS based applications such as Radio players, Radio Alarm, TMC navigation becomes possible also on LEO.
But he need same files from LEO.
flywhc said:
Eventually I found functions FmRadioSDK send and receive data.
Send request:
Code:
.text:10001208 MOV R12, SP
...
.text:10001220 LDR R3, =__0MsgQueueUtils__QAA_XZ
.text:10001224 LDR R3, [R3]
.text:10001228 MOV LR, PC
.text:1000122C MOV PC, R3 ; create MsgQueueUtils()
....
.text:100012A8 LDR LR, =_Create_MsgQueueUtils__QAAXPA_W_N1KKK_Z
.text:100012AC LDR R4, [LR]
.text:100012B0 MOV LR, PC
.text:100012B4 MOV PC, R4 ; pMsgQ->MsgQueueUtils::Create(L"BTAgProfileQueue",0, 0, 2, 0x14, 0x800)
It uses MsgQueueUtils class sends requests.
Receive events:
Code:
sub_100014E8
branch loc_10001644
It calls sub_100059B4 three times for PS, RT and PTN.
However look at sub_100059B4:
sub_100059B4
.text:100059B4 MOV R12, SP
.text:100059B8 STMFD SP!, {R0-R3}
...
.text:100059EC BL InitRDSBuf
then it is a loop, doesn't have raw RDS parsing logic.
It parses an internal data structure from BTAG (Bluetooth Audio Gateway?).
I have to look into BTAG driver to see if it handles raw RDS. So many bluetooth related DLLs... I guess it is btagsvc.dll?
I don't understand why HTC or Broadcomm make this FM driver so complicated. waste CPU, battery, storage... I guess it is Broadcomm provided those drivers to HTC to restrict capabilities of this chipset, just like HTC didn't have proper MSM graphics driver before.
I can't find file btagext.dll, which is loaded by a btagsvc.dll. anyone have this file? Maybe it is not important to us.
It sends message to a window with class name "WCE_BTTRAY" during initialization.
Update: I just found BTTrayCE.exe has string "WCE_BTTRAY" and "BTAgProfileQueue". It is a big exe file!
MsgQueueUtils is imported from BtCECommon.dll - I can't find this file. Anyone who has this device can upload BT*.*?
Global messages, such as registerwindowmessage(L"WIDCOMM_WM_REG_PROF_EVENT")
Code:
.rdata:100147F8 aWidcomm_wm_stack_loa unicode 0, <WIDCOMM_WM_STACK_LOAD>,0
.rdata:100147F8 ; CODE XREF: sub_100131F0+24j
.rdata:100147F8 ; DATA XREF: .text:off_1001321Co
.rdata:10014824 aWidcomm_wm_stack_unl unicode 0, <WIDCOMM_WM_STACK_UNLOAD>,0
.rdata:10014824 ; CODE XREF: sub_10013220+24j
.rdata:10014824 ; DATA XREF: .text:off_1001324Co
.rdata:10014854 aWidcomm_wm_getstacks unicode 0, <WIDCOMM_WM_GETSTACKSTATUS>,0
.rdata:10014854 ; CODE XREF: sub_10013250+24j
.rdata:10014854 ; DATA XREF: .text:off_1001327Co
.rdata:10014888 aWidcomm_wm_setstackc unicode 0, <WIDCOMM_WM_SETSTACKCONFIG>,0
.rdata:10014888 ; CODE XREF: sub_10013280+24j
.rdata:10014888 ; DATA XREF: .text:off_100132ACo
.rdata:100148BC aWidcomm_wm_btradio_o unicode 0, <WIDCOMM_WM_BTRADIO_OFF>,0
.rdata:100148BC ; CODE XREF: sub_100132B0+24j
.rdata:100148BC ; DATA XREF: .text:off_100132DCo
.rdata:100148EA DCW 0
.rdata:100148EC aWidcomm_wm_btradio_0 unicode 0, <WIDCOMM_WM_BTRADIO_ON>,0
.rdata:100148EC ; CODE XREF: sub_100132E0+24j
.rdata:100148EC ; DATA XREF: .text:off_1001330Co
.rdata:10014918 aWidcomm_wm_visible1 unicode 0, <WIDCOMM_WM_VISIBLE1>,0
.rdata:10014918 ; CODE XREF: sub_10013310+24j
.rdata:10014918 ; DATA XREF: .text:off_1001333Co
.rdata:10014940 aWidcomm_wm_reg_prof_ unicode 0, <WIDCOMM_WM_REG_PROF_NOTIF>,0
.rdata:10014940 ; CODE XREF: sub_10013340+24j
.rdata:10014940 ; DATA XREF: .text:off_1001336Co
.rdata:10014974 aWidcomm_wm_reg_pro_0 unicode 0, <WIDCOMM_WM_REG_PROF_EVENT>,0
.rdata:10014974 ; CODE XREF: RegWidcommProfEventMsg+24j
.rdata:10014974 ; DATA XREF: .text:off_1001339Co
.rdata:100149A8 aWidcomm_wm_activesyn unicode 0, <WIDCOMM_WM_ACTIVESYNC>,0
.rdata:100149A8 ; CODE XREF: sub_100133A0+24j
.rdata:100149A8 ; DATA XREF: .text:off_100133CCo
.rdata:100149D4 aWidcomm_wm_isvisibil unicode 0, <WIDCOMM_WM_ISVISIBILITYTIMER>,0
.rdata:100149D4 ; CODE XREF: sub_100133D0+24j
.rdata:100149D4 ; DATA XREF: .text:off_100133FCo
.rdata:10014A0E DCW 0
.rdata:10014A10 aWidcomm_wm_ident_cha unicode 0, <WIDCOMM_WM_IDENT_CHANGE>,0
.rdata:10014A10 ; CODE XREF: sub_10013400+24j
.rdata:10014A10 ; DATA XREF: .text:off_1001342Co
.rdata:10014A40 aWidcomm_wm_post_stac unicode 0, <WIDCOMM_WM_POST_STACK_LOAD>,0
.rdata:10014A40 ; CODE XREF: sub_10013430+24j
.rdata:10014A40 ; DATA XREF: .text:off_1001345Co
.rdata:10014A76 DCW 0
.rdata:10014A78 aWidcomm_wm_update_st unicode 0, <WIDCOMM_WM_UPDATE_STATUS>,0
.rdata:10014A78 ; CODE XREF: sub_10013460+24j
.rdata:10014A78 ; DATA XREF: .text:off_1001348Co
.rdata:10014AAA DCD 0
.rdata:10014AAE DCW 0
.rdata:10014AB0 aWidcomm_wm_kill_visi unicode 0, <WIDCOMM_WM_KILL_VISIBILITYTIMER>,0
.rdata:10014AB0 ; CODE XREF: sub_10013490+24j
.rdata:10014AB0 ; DATA XREF: .text:off_100134BCo
.rdata:10014AF0 aWidcomm_wm_set_fm_co unicode 0, <WIDCOMM_WM_SET_FM_CONFIG>,0
.rdata:10014AF0 ; CODE XREF: sub_100134C0+24j
.rdata:10014AF0 ; DATA XREF: .text:off_100134ECo
.rdata:10014B22 DCW 0
.rdata:10014B24 aWidcomm_wm_prof_chan unicode 0, <WIDCOMM_WM_PROF_CHANGE_EVENT>,0
.rdata:10014B24 ; CODE XREF: sub_100134F0+24j
.rdata:10014B24 ; DATA XREF: .text:off_1001351Co
.rdata:10014B5E DCW 0
.rdata:10014B60 aWidcomm_wm_stackload unicode 0, <WIDCOMM_WM_STACKLOADED>,0
.rdata:10014B60 ; CODE XREF: sub_10013520+24j
.rdata:10014B60 ; DATA XREF: .text:off_1001354Co
.rdata:10014B8E DCW 0
.rdata:10014B90 aWidcomm_wm_stackunlo unicode 0, <WIDCOMM_WM_STACKUNLOADED>,0
.rdata:10014B90 ; CODE XREF: sub_10013550+24j
.rdata:10014B90 ; DATA XREF: .text:off_1001357Co
.rdata:10014BC2 DCB 0
.rdata:10014BC3 DCB 0
.rdata:10014BC4 aWidcomm_wm_trayunloa unicode 0, <WIDCOMM_WM_TRAYUNLOADED>,0
.rdata:10014BC4 ; CODE XREF: sub_10013580+24j
.rdata:10014BC4 ; DATA XREF: .text:off_100135ACo
.rdata:10014BF4 aWidcomm_wm_activate unicode 0, <WIDCOMM_WM_ACTIVATE>,0
.rdata:10014BF4 ; CODE XREF: sub_100135B0+24j
.rdata:10014BF4 ; DATA XREF: .text:off_100135DCo
.rdata:10014BF4 ; END OF FUNCTION CHUNK FOR sub_100131F0
Click to expand...
Click to collapse
Can somebody upload the files?
Here´s the thread from flywhc:
[APP][29JUL09]RDS FM Radio R&D: Get radio text, Alt Freqency, free TMC etc
dussel said:
flywhc makes an adapter driver to support GFMAPI for HTC devices. This project makes all FM RDS based applications such as Radio players, Radio Alarm, TMC navigation becomes possible also on LEO.
But he need same files from LEO.
Can somebody upload the files?
Here´s the thread from flywhc:
[APP][29JUL09]RDS FM Radio R&D: Get radio text, Alt Freqency, free TMC etc
Click to expand...
Click to collapse
Just from kitchen made a quick search with BT, and here are all *bt*files I got. Hope you will find what you are looking for there.
http://www.sendspace.com/file/1sw0le
Thanks for the Heads Up.
Let's keep all the goods in the thread flywhy watches .
Closed.
Dave
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
Hello all,
I'm working on the mac address problem inherent to HD2.
For now under Magldr, it is more or less unique (more than less) ;-)
Other boot method I can't test is haret/wimo
It seems that my patch modifying the NAND(magldr) boot affects the SD boot.
I can't figure it without precise reports. I need you to use "adb" to report me some info.
Here is how to do it:
cd your/android-sdk-linux/platform-tools/
[email protected]:> ./adb shell
# uname -a
Linux localhost 2.6.32-ics_tytung_HWA_r2.3-uniMAC #7 PREEMPT Tue May 22 02:13:09 CEST 2012 armv7l GNU/Linux
# dmesg |grep -i mac
<4>[ 0.000000] Machine: htcleo
<6>[ 1.439056] Device Bluetooth MAC Address: 00:23:76:32:16:be
<6>[ 2.989105] rndis_function_bind_config MAC: 00:00:00:00:00:00
<6>[ 2.989593] usb0: MAC 36:b0:0d:af:76:1d
<6>[ 2.989624] usb0: HOST MAC ca:50:bc:14:ad:79
<6>[ 3.444152] Device Wifi Mac Address: 00:23:76:be:16:32
Tips
-shell into your hd2 asap, while in the boot animation !
-do it with both kernels HWA_r2.3-uniMAC and previous functionnal
Please other Magldr users, post here the macaddress you have.
This is just to eval 'dispersion' (collision avoidance) with actual patch.
Franck
ok, good news,
Saw the mistake in the kernel code.
function() call to guess a mac was inadvertandly removed for SD boot method!
Fixed in R4
This thread still must be filled with MAC address for NAND and SD kernel version to evaluate collision avoidance.
Meanwhile I'm working on reading on interesting NAND block with something ressembling a MAC in it.
Will need more testers to check it is a unique MAC ;-)
Hello All,
How many of you users with hd2 will be able to compile a custom kernel with a patched htcleo_nand.c ?
This is to validate my guess of finding two unique macadress writed in block 505 of the NAND.
To definitly get rid of this problem.
Franck
Code:
diff --git a/drivers/mtd/devices/htcleo_nand.c b/drivers/mtd/devices/htcleo_nand.c
index 2150bcc..bfbcbad 100755
--- a/drivers/mtd/devices/htcleo_nand.c
+++ b/drivers/mtd/devices/htcleo_nand.c
@@ -1827,6 +1827,116 @@ static int param_get_page_size(char *buffer, struct kernel_param *kp)
}
module_param_call(pagesize, NULL, param_get_page_size, NULL, S_IRUGO);
+int is_htc_mac (int pattern)
+{
+ /* HTC blocks to find :
+ 00:09:2D
+ 00:23:76
+ 18:87:76
+ 1C:B0:94
+ 38:E7:D8
+ 64:A7:69
+ 7C:61:93
+ 90:21:55
+ A0:F4:50
+ A8:26:D9
+ D4:20:6D
+ D8:B3:77
+ E8:99:C4
+ F8:DB:F7 */
+ static int nums[] = {
+ 0x00092D,0x2D0900,
+ 0x002376,0x762300,
+ 0x188776,0x768718,
+ 0x1CB094,0x94B01C,
+ 0x38E7D8,0xD8E738,
+ 0x64A769,0x69A764,
+ 0x7C6193,0x93617C,
+ 0x902155,0x552190,
+ 0xA0F450,0x50F4A0,
+ 0xA826D9,0xD926A8,
+ 0xD4206D,0x6D20D4,
+ 0xD8B377,0x77B3D8,
+ 0xE899C4,0xC499E8,
+ 0xF8DBF7,0xF7DBF8};
+ int i;
+ for (i=0; i< (sizeof(nums)/sizeof(nums[0])); i++)
+ {
+ if (nums[i] == pattern) return 1;
+ }
+ return 0;
+}
+void scanmac(struct mtd_info *mtd)
+{
+ unsigned char *iobuf;
+ int ret;
+ loff_t addr;
+ struct mtd_oob_ops ops;
+ int i,j,k;
+
+ iobuf = kmalloc(2048/*mtd->erasesize*/, GFP_KERNEL);
+ if (!iobuf) {
+ /*ret = -ENOMEM;*/
+ printk("%s: error: cannot allocate memory\n",__func__);
+ return;
+ }
+
+ ops.mode = MTD_OOB_PLACE;
+ ops.len = 2048;
+ ops.datbuf = iobuf;
+ ops.ooblen = 0;
+ ops.oobbuf = NULL;
+ ops.retlen = 0;
+
+ /* bloc 505 page 6 contains as good candidate */
+ addr = ((loff_t) 505*0x20000 + 6*2048);
+ ret = msm_nand_read_oob(mtd, addr, &ops);
+
+ if (ret == -EUCLEAN)
+ ret = 0;
+ if (ret || ops.retlen != 2048 ) {
+ printk("%s: error: read(%d) failed at %#llx\n",__func__,ops.retlen, addr);
+ goto out;
+ }
+
+ printk("%s: Prefered candidate mac=%02x:%02x:%02x:%02x:%02x:%02x\n",__func__,
+ iobuf[5],iobuf[4],iobuf[3],iobuf[2],iobuf[1],iobuf[0]);
+
+ /* now lets walk looking for HTC mac in the first reserved blocks of NAND */
+ /* NUM_PROTECTED_BLOCKS=0x212 but Parttiontable starts at 0x219 */
+ /* I think 400 is ok, I have already eliminated 0 - 157 with false positive */
+ /* If my guess is correct, only 505 will match ;-) */
+ for (i=158; i<0x219; i++) {
+ for (j=0; j<64; j++) {
+ addr = ((loff_t) i*0x20000 + j*2048);
+ ret = msm_nand_read_oob(mtd, addr, &ops);
+
+ if (ret == -EUCLEAN)
+ ret = 0;
+ if (ret || ops.retlen != 2048 ) {
+ printk("%s: error: read(%d) failed at %#llx\n",__func__,ops.retlen, addr);
+ break;
+ }
+ /* check */
+ for (k=0; k<2045; k++) {
+ if (is_htc_mac( (iobuf[k+0]<<16) + (iobuf[k+1]<<8) + iobuf[k+2])) {
+ printk("Mac candidate at block:%d page:%d offset:%d:\n",i,j,k);
+ k >>= 4;
+ k <<= 4;
+ print_hex_dump_bytes("", DUMP_PREFIX_OFFSET, &iobuf[k], 16);
+ k += 16;
+ }
+ }
+ }/*j*/
+ }/*i*/
+ ret = 0;
+out:
+ kfree(iobuf);
+ if (ret)
+ printk("Find MAc Error %d occurred\n", ret);
+ return;
+}
+
/**
* msm_nand_scan - [msm_nand Interface] Scan for the msm_nand device
* @param mtd MTD device structure
@@ -1992,6 +2102,8 @@ int msm_nand_scan(struct mtd_info *mtd, int maxchips)
/* msm_nand_unlock_all(mtd); */
/* return this->scan_bbt(mtd); */
+ scanmac(mtd);
+
#if VERBOSE
for (i=0;i<nand_info->block_count;i++)
my findings are on five HD2 are:
Frk
Mac candidate at block:505 page:0 offset:40:
00000000: 00 00 00 00 30 00 00 00 38 e7 d8 e6 38 fc 00 00 ....0...8...8...
Mac candidate at block:505 page:6 offset:3:
00000000: 80 1c e2 d8 e7 38 ff ff ff ff ff ff ff ff ff ff .....8..........
wifi mac 38 e7 d8 e6 38 fcunder WIMO
Bad
Mac candidate at block:505 page:0 offset:40:
00000000: 00 00 00 00 30 00 00 00 00 23 76 5d fb 08 00 00 ....0....#v]....
Mac candidate at block:505 page:6 offset:3:
00000000: df 20 74 76 23 00 ff ff ff ff ff ff ff ff ff ff . tv#...........
Frk2
Mac candidate at block:505 page:0 offset:40:
00000000: 00 00 00 00 30 00 00 00 00 23 76 d7 ea 13 00 00 ....0....#v.....
Mac candidate at block:505 page:6 offset:3:
00000000: 80 5b e5 76 23 00 ff ff ff ff ff ff ff ff ff ff .[.v#...........
Val
Mac candidate at block:505 page:0 offset:40:
00000000: 00 00 00 00 30 00 00 00 00 23 76 89 09 c0 00 00 ....0....#v.....
Mac candidate at block:505 page:6 offset:3:
00000000: 46 da 6d 76 23 00 ff ff ff ff ff ff ff ff ff ff F.mv#...........
Flo
Mac candidate at block:505 page:0 offset:40:
00000000: 00 00 00 00 30 00 00 00 00 23 76 8c a4 a6 00 00 ....0....#v.....
Mac candidate at block:505 page:6 offset:3:
00000000: 3d 48 6f 76 23 00 ff ff ff ff ff ff ff ff ff ff =Hov#...........
Flo after full task29+reinstall
Mac candidate at block:505 page:0 offset:40:
00000000: 00 00 00 00 30 00 00 00 00 23 76 8c a4 a6 00 00 ....0....#v.....
Mac candidate at block:505 page:6 offset:3:
00000000: 3d 48 6f 76 23 00 ff ff ff ff ff ff ff ff ff ff =Hov#...........
I think you nailed it,
My device's bluetooth mac id under windows: 00:23:76:78:70:78
My device's wireless mac id under windows: 00:23:76:96:1B:F9
Code:
<4>[ 1.325286] scanmac: Prefered candidate mac=00:23:76:78:70:78
<4>[ 22.797302] Mac candidate at block:505 page:0 offset:40:
<7>[ 22.797332] 00000000: 00 00 00 00 10 00 00 00 [B]00 23 76 96 1b f9[/B] 00 00
<4>[ 22.803070] Mac candidate at block:505 page:6 offset:3:
<7>[ 22.803100] 00000000: [B]78 70 78 76 23 00[/B] ff ff ff ff ff ff ff ff ff ff
Although there was another candidate,
Code:
<4>[ 24.686889] Mac candidate at block:536 page:5 offset:443:
<7>[ 24.686950] 00000000: bf 03 1e ad ba 9d 4a 6f a4 e1 89 7c 61 93 67 d9
But this one is totally wrong, block:536 is after the bootloader(clk in this case) and is part of the config table
As i said in the email, you should only scan till block 530 (0x212)
EDIT: modified your code a bit,
Code:
<4>[ 1.325347] scanmac: candidate for wifi mac=00:23:76:96:1b:f9
<4>[ 1.325622] scanmac: candidate for bluetooth mac=00:23:76:78:70:78
Code:
diff --git a/drivers/mtd/devices/htcleo_nand.c b/drivers/mtd/devices/htcleo_nand.c
index e4e347e..27aa6e8 100755
--- a/drivers/mtd/devices/htcleo_nand.c
+++ b/drivers/mtd/devices/htcleo_nand.c
@@ -1835,6 +1835,54 @@ static int param_get_page_size(char *buffer, struct kernel_param *kp)
}
module_param_call(pagesize, NULL, param_get_page_size, NULL, S_IRUGO);
+void scanmac(struct mtd_info *mtd)
+{
+ unsigned char *iobuf;
+ int ret;
+ loff_t addr;
+ struct mtd_oob_ops ops;
+
+ iobuf = kmalloc(2048/*mtd->erasesize*/, GFP_KERNEL);
+ if (!iobuf) {
+ printk("%s: error: cannot allocate memory\n",__func__);
+ return;
+ }
+
+ ops.mode = MTD_OOB_PLACE;
+ ops.len = 2048;
+ ops.datbuf = iobuf;
+ ops.ooblen = 0;
+ ops.oobbuf = NULL;
+ ops.retlen = 0;
+
+ addr = ((loff_t) 505*0x20000);
+ ret = msm_nand_read_oob(mtd, addr, &ops);
+ if (ret == -EUCLEAN)
+ ret = 0;
+ if (ret || ops.retlen != 2048 ) {
+ printk("%s: error: read(%d) failed at %#llx\n",__func__,ops.retlen, addr);
+ goto out;
+ }
+ printk("%s: candidate for wifi mac=%02x:%02x:%02x:%02x:%02x:%02x\n",__func__,
+ iobuf[40],iobuf[41],iobuf[42],iobuf[43],iobuf[44],iobuf[45]);
+
+ addr = ((loff_t) 505*0x20000 + 6*0x800);
+ ret = msm_nand_read_oob(mtd, addr, &ops);
+ if (ret == -EUCLEAN)
+ ret = 0;
+ if (ret || ops.retlen != 2048 ) {
+ printk("%s: error: read(%d) failed at %#llx\n",__func__,ops.retlen, addr);
+ goto out;
+ }
+ printk("%s: candidate for bluetooth mac=%02x:%02x:%02x:%02x:%02x:%02x\n",__func__,
+ iobuf[5],iobuf[4],iobuf[3],iobuf[2],iobuf[1],iobuf[0]);
+ ret = 0;
+out:
+ kfree(iobuf);
+ if (ret) printk("Find MAC Error %d occurred\n", ret);
+ return;
+}
+
/**
* msm_nand_scan - [msm_nand Interface] Scan for the msm_nand device
* @param mtd MTD device structure
@@ -2000,6 +2048,7 @@ int msm_nand_scan(struct mtd_info *mtd, int maxchips)
/* msm_nand_unlock_all(mtd); */
/* return this->scan_bbt(mtd); */
+ scanmac(mtd);
#if VERBOSE
for (i=0;i<nand_info->block_count;i++)
Great job.
I've implemented the mac address reading in my kernel. You can see the commit here:
https://github.com/marc1706/desire_kernel_35/commit/0b249dfba877b96fc0ebe1333738f0920b4dc7c5
edit:
My mac addresses, now both with Windows Mobile and with Android:
Code:
Wifi Mac: 00:23:76:8A:40:B9
BT Mac: 00:23:76:6E:4B:C6
well, I'l sure now that the offset [40...45] have a macaddress.
problem is how is it unique....
If you read this code you will see that when the Nand is blank, a default macaddress of 00:90:4C:C5:00:34 is created.
Code:
ROM:95043CC8 @ =============== S U B R O U T I N E =======================================
ROM:95043CC8
ROM:95043CC8 @ 1 initdata
ROM:95043CC8 @ 0 displaydata
ROM:95043CC8
ROM:95043CC8 eMapiCheckWlanDataValidity: @ CODE XREF: StartupSequence+3Cp
ROM:95043CC8 @ Emapitest:loc_9502020Cp
ROM:95043CC8 @ DATA XREF: ...
ROM:95043CC8
ROM:95043CC8 var_30 = -0x30
ROM:95043CC8 var_2C = -0x2C
ROM:95043CC8 var_28 = -0x28
ROM:95043CC8
ROM:95043CC8 STMFD SP!, {R4-R11,LR}
ROM:95043CCC SUB SP, SP, #0xC
ROM:95043CD0 MOV R4, R0
ROM:95043CD4 LDR R0, =WlanBlock
ROM:95043CD8 MOV R5, #0
ROM:95043CDC BL GetWLANblock
ROM:95043CE0 BL CheckSignature
ROM:95043CE4 LDR R7, =0xEE4329
ROM:95043CE8 MOV R6, R0
ROM:95043CEC CMP R4, #0
ROM:95043CF0 BNE _InitData
ROM:95043CF4 LDR R3, [R6]
ROM:95043CF8 CMP R3, R7
ROM:95043CFC BNE _InitData
ROM:95043D00 LDR R3, [R6,#4]
ROM:95043D04 CMP R3, #0
ROM:95043D08 BEQ _err_invalid_update
ROM:95043D0C LDR R3, [R6,#8]
ROM:95043D10 CMP R3, #0
ROM:95043D14 BEQ _err_invalid_update
ROM:95043D18 LDR R2, [R6,#0xC]
ROM:95043D1C CMP R2, #0x7C0
ROM:95043D20 BLS loc_95043D30
ROM:95043D24
ROM:95043D24 _err_invalid_body_size: @ "[eMapiCheckWlanDataValidity] Invalid bo"...
ROM:95043D24 LDR R0, =aEmapicheckwlan
ROM:95043D28 BL print
ROM:95043D2C B _end
ROM:95043D30 @ ---------------------------------------------------------------------------
ROM:95043D30
ROM:95043D30 loc_95043D30: @ CODE XREF: eMapiCheckWlanDataValidity+58j
ROM:95043D30 AND R3, R2, #3
ROM:95043D34 SUB R3, R2, R3
ROM:95043D38 ADD R1, R3, #4
ROM:95043D3C MOV R2, #0
ROM:95043D40 ADD R0, R6, #0x40
ROM:95043D44 BL GetRamCrc
ROM:95043D48 LDR R3, [R6,#0x10]
ROM:95043D4C CMP R0, R3
ROM:95043D50 BEQ _DisplayData
ROM:95043D54
ROM:95043D54 _err_checsum_invalid: @ "[eMapiCheckWlanDataValidity] CheckSum e"...
ROM:95043D54 LDR R0, =aEmapicheckwl_0
ROM:95043D58 BL print
ROM:95043D5C B _end
ROM:95043D60 @ ---------------------------------------------------------------------------
ROM:95043D60
ROM:95043D60 _DisplayData: @ CODE XREF: eMapiCheckWlanDataValidity+88j
ROM:95043D60 LDR R0, =aWlanDataHeader @ "Wlan data header ++++++++++++++++++++\n"
ROM:95043D64 BL print
ROM:95043D68 LDR R1, [R6]
ROM:95043D6C LDR R0, =aSignature0xX @ "Signature : 0x%x\n"
ROM:95043D70 BL printf
ROM:95043D74 LDR R1, [R6,#4]
ROM:95043D78 LDR R0, =aUpdatestatus0x @ "UpdateStatus : 0x%x\n"
ROM:95043D7C BL printf
ROM:95043D80 LDR R1, [R6,#8]
ROM:95043D84 LDR R0, =aUpdatecount0xX @ "UpdateCount : 0x%x\n"
ROM:95043D88 BL printf
ROM:95043D8C LDR R1, [R6,#0xC]
ROM:95043D90 LDR R0, =aBodylength0xX @ "BodyLength : 0x%x\n"
ROM:95043D94 BL printf
ROM:95043D98 LDR R1, [R6,#0x10]
ROM:95043D9C LDR R0, =aBodycrc0xX @ "BodyCRC : 0x%x\n"
ROM:95043DA0 BL printf
ROM:95043DA4 LDR R1, [R6,#0x14]
ROM:95043DA8 LDR R0, =aAdieid00xX @ "aDieId(0) : 0x%x\n"
ROM:95043DAC BL printf
ROM:95043DB0 LDR R1, [R6,#0x18]
ROM:95043DB4 LDR R0, =aAdieid10xX @ "aDieId(1) : 0x%x\n"
ROM:95043DB8 BL printf
ROM:95043DBC LDR R1, [R6,#0x1C]
ROM:95043DC0 LDR R0, =aAdieid20xX @ "aDieId(2) : 0x%x\n"
ROM:95043DC4 BL printf
ROM:95043DC8 LDR R1, [R6,#0x20]
ROM:95043DCC LDR R0, =aAdieid30xX @ "aDieId(3) : 0x%x\n"
ROM:95043DD0 BL printf
ROM:95043DD4 LDR R1, [R6,#0x24]
ROM:95043DD8 LDR R0, =aCountryid0xX @ "countryID : 0x%x\n"
ROM:95043DDC BL printf
ROM:95043DE0 LDRB LR, [R6,#45]
ROM:95043DE4 LDRB R4, [R6,#44]
ROM:95043DE8 LDRB R5, [R6,#43]
ROM:95043DEC LDRB R3, [R6,#42]
ROM:95043DF0 LDRB R2, [R6,#41]
ROM:95043DF4 LDRB R1, [R6,#40]
ROM:95043DF8 LDR R0, =aMacBBBBBB @ "MAC= %B %B %B %B %B %B\r\n "
ROM:95043DFC STR LR, [SP,#0x30+var_28]
ROM:95043E00 STR R4, [SP,#0x30+var_2C]
ROM:95043E04 STR R5, [SP,#0x30+var_30]
ROM:95043E08 BL printf
ROM:95043E0C LDR R0, =aWlanDataHead_0 @ "Wlan data header ----------------------"...
ROM:95043E10
ROM:95043E10 _ok: @ CODE XREF: eMapiCheckWlanDataValidity+1F4j
ROM:95043E10 BL print
ROM:95043E14 MOV R5, #1
ROM:95043E18 B _end
ROM:95043E1C @ ---------------------------------------------------------------------------
ROM:95043E1C
ROM:95043E1C _err_invalid_update: @ CODE XREF: eMapiCheckWlanDataValidity+40j
ROM:95043E1C @ eMapiCheckWlanDataValidity+4Cj
ROM:95043E1C LDR R0, =aEmapicheckwl_1 @ "[eMapiCheckWlanDataValidity] Invalid up"...
ROM:95043E20 BL print
ROM:95043E24 B _end
ROM:95043E28 @ ---------------------------------------------------------------------------
ROM:95043E28
ROM:95043E28 _InitData: @ CODE XREF: eMapiCheckWlanDataValidity+28j
ROM:95043E28 @ eMapiCheckWlanDataValidity+34j
ROM:95043E28 MOV R2, #0x800 @ Count
ROM:95043E2C MOV R1, #0 @ char
ROM:95043E30 MOV R0, R6 @ int
ROM:95043E34 BL fillchar
ROM:95043E38
ROM:95043E38
ROM:95043E38 MOV R3, #0x238
ROM:95043E3C LDR R1, =unk_97901318
ROM:95043E40 ORR R3, R3, #2
ROM:95043E44 MOV R5, #0x10
ROM:95043E48 MOV R8, #0x90 @ '�'
ROM:95043E4C MOV R9, #0x4C @ 'L'
ROM:95043E50 MOV R10, #0xC5 @ '+'
ROM:95043E54 MOV R11, #0x34 @ '4'
ROM:95043E58 MOV LR, #1
ROM:95043E5C MOV R4, #0
ROM:95043E60 MOV R2, R3
ROM:95043E64 ADD R0, R6, #0x40
ROM:95043E68 STMIA R6, {R7,LR}
ROM:95043E6C STR LR, [R6,#8]
ROM:95043E70 STR R3, [R6,#0xC]
ROM:95043E74 STR R5, [R6,#0x24]
ROM:95043E78 STRB R4, [R6,#0x28]
ROM:95043E7C STRB R8, [R6,#0x29]
ROM:95043E80 STRB R9, [R6,#0x2A]
ROM:95043E84 STRB R10, [R6,#0x2B]
ROM:95043E88 STRB R4, [R6,#0x2C]
ROM:95043E8C STRB R11, [R6,#0x2D]
ROM:95043E90 BL memcpy
ROM:95043E94 MOV R2, #0
ROM:95043E98 MOV R1, #0x23C
ROM:95043E9C ADD R0, R6, #0x40
ROM:95043EA0 BL GetRamCrc
ROM:95043EA4 MOV R3, R0
ROM:95043EA8 MOV R0, R6
ROM:95043EAC STR R3, [R6,#0x10]
ROM:95043EB0 BL callNAND_WriteConfig
ROM:95043EB4 CMP R0, #0
ROM:95043EB8 LDRNE R0, =aInitializeWlan @ "Initialize wlan data success\n"
ROM:95043EBC BNE _ok
ROM:95043EC0
ROM:95043EC0 _err_init_failed: @ "Initialize wlan data fail\n\n"
ROM:95043EC0 LDR R0, =aInitializeWl_0
ROM:95043EC4 BL print
ROM:95043EC8 MOV R5, #0
ROM:95043ECC
ROM:95043ECC _end: @ CODE XREF: eMapiCheckWlanDataValidity+64j
ROM:95043ECC @ eMapiCheckWlanDataValidity+94j ...
ROM:95043ECC MOV R0, R5
ROM:95043ED0 ADD SP, SP, #0xC
ROM:95043ED4 LDMFD SP!, {R4-R11,LR}
ROM:95043ED8 BX LR
Is that from a ROM? If yes then I'm guessing that it maybe creates a "default" mac before the actual mac address is parsed from SPL.
I've done a task29 and installed a (close to) stock windows mobile ROM before checking my real wifi and bt mac addresses.
And they are the same as the ones this code returns.
marc1706 said:
Is that from a ROM? If yes then I'm guessing that it maybe creates a "default" mac before the actual mac address is parsed from SPL.
I've done a task29 and installed a (close to) stock windows mobile ROM before checking my real wifi and bt mac addresses.
And they are the same as the ones this code returns.
Click to expand...
Click to collapse
It is from SPL, But since nand config data is never erased and is written in factory, i think it should be fine using this as a source, since we know there weren't any mac collisions under windows mobile as far as i know.
Add another htc-hd2 I got
Directly installed with Tytung kernel hwa v2.3 (jun 2012), macaddress:
wifi : 00:23:76:89:1F:B2
bluetooth : 00:23:76:6D:E3:FF
are unique :angel:
Franck
Franck78 said:
Add another htc-hd2 I got
Directly installed with Tytung kernel hwa v2.3 (jun 2012), macaddress:
wifi : 00:23:76:89:1F:B2
bluetooth : 00:23:76:6D:E3:FF
are unique :angel:
Franck
Click to expand...
Click to collapse
I've confirmed this fix with 4 different HD2 devices - all are unique, and show the same MAC from WinMo65 Thanks a ton for your work!!!
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