Adapting for 32-bit PXN enabled device

[dadreamer]

Hi, @dosomder !

I have troubles with adapting iovyroot for Docomo Fujitsu Arrows NX F-01F, which has PXN enabled, even when it's on 32-bit arch. Okay, I've found _ptmxfops, sidtab, policydb and _selinuxenabled from kallsyms. I can't find the pointer to _selinuxenforcing. It seems, this parameter is hard-coded to 1:

.text:C0361214 ; =============== S U B R O U T I N E =======================================
.text:C0361214
.text:C0361214
.text:C0361214 sel_read_enforce                        ; DATA XREF: .text:C0A2BA94
.text:C0361214                                         ; .text:C0AC95E8
.text:C0361214
.text:C0361214 var_30          = -0x30
.text:C0361214 var_28          = -0x28
.text:C0361214 var_1C          = -0x1C
.text:C0361214
.text:C0361214                 STMFD           SP!, {R4-R7,LR}
.text:C0361218                 MOV             R5, R3
.text:C036121C                 LDR             R4, =__stack_chk_guard
.text:C0361220                 SUB             SP, SP, #0x1C
.text:C0361224                 MOV             R7, R1
.text:C0361228                 MOV             R6, R2
.text:C036122C                 MOV             R1, #0xC
.text:C0361230                 LDR             R2, =0xC0D70ADD
.text:C0361234                 ADD             R0, SP, #0x30+var_28
.text:C0361238                 LDR             R3, [R4]
.text:C036123C                 STR             R3, [SP,#0x30+var_1C]
.text:C0361240                 MOV             R3, #1
.text:C0361244                 BL              scnprintf
.text:C0361248                 STR             R0, [SP,#0x30+var_30]
.text:C036124C                 MOV             R2, R5
.text:C0361250                 ADD             R3, SP, #0x30+var_28
.text:C0361254                 MOV             R0, R7
.text:C0361258                 MOV             R1, R6
.text:C036125C                 BL              simple_read_from_buffer
.text:C0361260                 LDR             R2, [SP,#0x30+var_1C]
.text:C0361264                 LDR             R3, [R4]
.text:C0361268                 CMP             R2, R3
.text:C036126C                 BEQ             loc_C0361274
.text:C0361270                 BL              __stack_chk_fail
.text:C0361274
.text:C0361274 loc_C0361274                            ; CODE XREF: sel_read_enforce+58
.text:C0361274                 ADD             SP, SP, #0x1C
.text:C0361278                 LDMFD           SP!, {R4-R7,PC}
.text:C0361278 ; End of function sel_read_enforce

I also tried hard to find the suitable locations for joploc and jopret but still didn't succeed. Here you write, that setfl() is inside sys_fcntl, but in the source it is called from do_fcntl. Nevertheless I checked both sys_fcntl and do_fcntl in IDA and I didn't see anything, that looks like your patterns. Some googling gave me this article. There are the modifications to iovyroot for rooting Samsung Galaxy S5, which is also on x32 and has got PXN on. But I couldn't find those JOP patterns also.

Maybe you could take a look at my kernel dump and kallsyms and give me some advice on how to complete my offsets. kernel kallsyms I already tried running without JOP locations and the exploit cannot finish. After some time my phone reboots.

[copslock]

Does the source code of F-01F helpful? It was provided over here http://spf.fmworld.net/oss/oss/f-01f/index.html

[copslock]

the methods used by kingroot all got the same result on F-01F 4.4.2------reboot,like you,possible some proprietary kernel protect watch-guard was used to moniter the kernel access

[dadreamer]

@copslock Yes, it helps a little but I think now that it's very hard (or nearly impossible) to get full root from within this protected system on F-01F. There's Linux Security Module (LSM) from Docomo, called fjsec. It hooks user interactions and allows or disallows them (e.g. mount points access). There's PXN also so you can't reach kernel memory space from your userland. Well, even when you are root you still can do nothing. So I think the only way to full-root F-01F is to reflash EMMC externally (this is called hardware root). I'm gonna try that but I don't know when I get more time for this.

[copslock]

@dadreamer Well,the fjsec that called LSM was mentioned by tewilove for many times,and so far some tools for other devices were used the method to disable the LSM manually then execute some else commands, i dont know will this give you some idea that you can Google “tewilove + LSM”,and you will a lot about his works on the japanese cellphones.,some were wrriten in Chinese, Besides,did you get the pbl or sbl analysed?if we can not get root priv from userspace why not change the game play method ? I know at least some Chinese solder in Shenzhen were able to modify the phone's preinstalled apps by using the method that possible entering the Qualcomm 9088 Emergency download mode ,i am not very sure about that and it may implement by some odd combinations of vol power fingerprint button and usb insert even some modified usb cables like the one tewilove provided for sharp 303sh,Can you do some analyse on the fujitsu Qualcomm download mode?the EDL mode code include in QRD devices was msm_power.c,and unkown for fujitsu

[copslock]

if we can get into the Qualcomm 9008,then with the firehorse loadet then entering the 9006 download mode ,then you were able to modify the content on eMMC via diskgenius

[copslock]

i had even tear down my device to find the test point for the GPIO that trigger into the emergency download mode,but it seems nonsense, here are some tech information about the Qualcomm download mode and may written by some QC R&D http://blog.csdn.net/fybon/article/details/37565227 http://huaqianlee.github.io/2015/08/18/Android/%E9%AB%98%E9%80%9A%E5%B9%B3%E5%8F%B0Android%E6%BA%90%E7%A0%81bootloader%E5%88%86%E6%9E%90%E4%B9%8Bsbl1-%E4%B8%89/ Written in Chinese and if cant understand i can translate for you ,thanks for the work on the abandoned phones！

[copslock]

if you can find the way to get to the 9006,i will buy another devices with JB to get a full dump for downgrade,even with some early tools provided to generated the rawprogram0.xml and patch0.xml

[copslock]

one more thing , http://blog.csdn.net/sakaison/article/details/52218517 a POC of Quadrooter by Chinese that implemented one of the GPU driver vuls

[dadreamer]

Well,the fjsec that called LSM was mentioned by tewilove for many times,and so far some tools for other devices were used the method to disable the LSM manually then execute some else commands, i dont know will this give you some idea that you can Google “tewilove + LSM”,and you will a lot about his works on the japanese cellphones.,some were wrriten in Chinese

Maybe I'm having another Google... But all I find is his UpAny tool and some old imageboard threads. There's not so much info about fjsec. And as I know the only one thing to disable it - Backdoor mmap tools by fi01. Sadly these tools don't work for F-01F on 4.4.2 because mmap to kernel ds doesn't work due to PXN.

Besides,did you get the pbl or sbl analysed?

No, I didn't try.

Can you do some analyse on the fujitsu Qualcomm download mode?

I'm not completely sure but afraid that we won't have success with that. F-01F doesn't have fastboot so we cannot load to EDL via Fastboot or ADB. I tried to activate USB Modem/Diag Mode under root but it didn't work also. There are some funcs in the sources related to EDL, e.g. _set_dloadmode, _dloadset, _dload_modeaddr, _dload_modeenabled, _downloadmode, _emergency_dload_modeaddr. But we cannot call them from userland. Maybe there exists a way to switch on EDL by manipulating on hardware level, but I know nothing about it.

thanks for the work on the abandoned phones！

I'm just an user of F-01F as you. I'm not an expert in Android kernel and not a developer. So, while I own this phone, I will be trying to full-root it. If I sell it or whatever... well, then I don't see a much sense to find out those secret rooting techniques.

if you can find the way to get to the 9006,i will buy another devices with JB to get a full dump for downgrade,even with some early tools provided to generated the rawprogram0.xml and patch0.xml

All these experiments take a lot of free time. And honestly I don't believe that EDL mode is reachable from under the device system. I'm gonna spend some time on hardware root if there will be a time, ofc. If you feel that it's possible, you might do your own research on this task and post your findings on xda or somewhere.. This would be useful for others.

a POC of Quadrooter

As I see this poc lacks basic root gain functionality, so someone should write this part his/herself. Even if this exploit is written and gives you #, still there's LSM which you want to override somehow. This is even more important than root priv's (think of it as you already have these priv's). So, I don't know what I can do with this code.

[copslock]

@dadreamer Thanks!Could you provide any script for open the DIAG port on fujitsu qualcomm model phone?（under ROOT shell）I think this will be useful for QPST operation

[dadreamer]

Thanks!Could you provide any script for open the DIAG port on fujitsu qualcomm model phone?（under ROOT shell）I think this will be useful for QPST operation

I didn't use any script for this. I just tried to run the following command under root: setprop sys.usb.config diag,adb I didn't try another ways to activate it. Maybe you would be more lucky than I am. :)

[copslock]

@dadreamer well,looks like nothing helpful now,can you share with me of the modified code of RowHammer you used on F-01F? Some of my friend be able to bypass the PXN with some evil JOP code,I thnk i may have a try with your temp root shell, email: paficrock@gmail.com thanks a lot

[dadreamer]

@copslock Do you have some progress on that with Drammer exploit? Recently I've been searching for a way to unsolder emmc, not damaging other components. But it seems to be complicated to do. Now I'm going to order one broken system board to play around. Do you have one? Or maybe know where to get it on the cheap?..

[copslock]

@dadreamer нет,the drammer EXPLOIT depends on the memory error and it's too costly to gain such an temp root access,,I contacted someone can really bypass the PXN on android 4.4 ,he said should with some JOP ROP method but not willing to share the tool,maybe it's appliable to most android devices for even higher realeses.He told me that using the CVE-2017-8890 CVE-2017-7533 and possible other ret2usr method which is beyond my ability. http://www.freebuf.com/articles/terminal/160041.html and https://bbs.pediy.com/thread-226057.htm I got some tool from him,in it mentioned about the fjsec but i don't know how to use it, you can do something with it,good luck!

[copslock]

S0012.7z.gz

[dadreamer]

it's too costly to gain such an temp root access

Yeah, it's very unconvenient, time-consuming and buggy on F-01F. But it's the only way to gain temp root for F-01F for now. And it more or less works ( even if it takes a half/a whole day of you ;) ). Since my last message I have launched this poc "a thousand" times in order to test different things. Sadly, nothing interesting. I cannot mmap to the kernel memory (data and code sections). But I can read/dump almost all the memory with dd (under root, of course). When I try to write to the memory, the phone reboots. Well, I have been told by Drammer author (Victor van der Veen), that his poc is written only for LG Nexus 5 with Android 6.0.1 and if I rewrite it for my phone target, it would work normally. Look here, how fast it works. But I'm not a native Android programmer, so it would take months to figure out, what's happening in that Drammer test tool. Moreover I'd have to write (on my own) an exploit part 'cause it's missing from the sources. Maybe, one day I'll get my hands on it, if nothing else works, as Drammer poc is the only thing that's able to write to the kernel memory for now (watch at the very end, when it's writing user creds).

CVE-2017-8890

This CVE is really interesting as those two links. I see a real way to apply JOP code from the kernel DS. But no poc there or on github :( Someone should think of it and write the code him(her?)self. I don't have enough knowledge to finish this work, sorry.

S0012.7z.gz

Seems to be a bunch of various rooting tools, united into one app. There's "root" binary inside. I tried to run it twice and always getting this:

shell@F01F:/data/local/tmp $ ./r00t
init: PID = 23996
init: TGID = 23996
init: phys_offset = 0
init: page_offset = c0000000
cve-2015-0569: ctor()
cve-2015-0569: unlock_addr_limit()
PS C:\adb> ./adb shell
shell@F01F:/ $ cd data/local/tmp
shell@F01F:/data/local/tmp $ ./r00t
init: PID = 3502
init: TGID = 3502
init: phys_offset = 0
init: page_offset = c0000000
cve-2015-0569: ctor()
cve-2015-0569: unlock_addr_limit()

After that my phone reboots (it seems to trigger the kernel protection). What about fjsec - the app contains the code by fi01: unlock_security_module, which doesn't work on PXN-enabled devices. There is a more detailed article about using this tool. Well, I've studied the kernel code in IDA and compared it to the official sources. I think, I know what to alter to disable fjsec. But to achieve this I need the memory be writable from the root user. Still trying some things, so will write on success.

Btw I tried to do hardware rooting, but it was a fail take. You may read about it here.

[copslock]

@dadreamer PXN bypass with JOP/ROP method is necessary,that's what he told me.I think the PXN protect will obivously prohibit anything you want to expand in next steps.So xOP programming is absolutely required first.So far these security guys will not pubilcly share these code obviously as most useful poc will be used by those low-tech bundling malicious android app.So the only way is to learn something about the assembly programming but that's something pretty hard. https://googleprojectzero.blogspot.com/2017/02/lifting-hyper-visor-bypassing-samsungs.html https://paper.seebug.org/587/ https://bbs.pediy.com/thread-226057.htm https://bbs.pediy.com/thread-220057.htm https://blog.csdn.net/hu3167343/article/details/47394707 These are something about the JOP/ROPgadget method,but most of them device specific. In breif,bypass PXN need to patch the addr_limit to 0xffffffff by using the kernel-state JOP/ROPgadget,then do somethng to gain the r00t access. here are something you may need. https://github.com/android-exploit/offensive_poc. Good luck

[copslock]

The fujitsu must implemnted some protect method that it's private like in this one,PXN is onething,the fjsec will be the second thing. https://bbs.pediy.com/thread-215549.htm By the way,the tool seems that need payload like boot.img twrp.img to be add,and maybe some internal authencation need to bypass because this tool is used for jni and it actually need to pay for the activation code.i don't think the tool has target at the F01F 4.4 but the fjsec bypass method included in the jni binary may give you some idea to do some stuff:)

[copslock]

And something about the big-dirtycow CVE-2017-10661 https://www.anquanke.com/post/id/129468

[copslock]

In conclusion. bypass PXN -- JOP/ROPgadget set addr_limit kernel vulnerability -- race condition or something else OEM LSM -- analyse specific function,find the key flag in memory

[dadreamer]

This issue is closed, because F-01F (V10R22A) is rooted now using CVE-2017-8890 exp: https://github.com/dadreamer/CVE-2017-8890. I adapted the exp from thinkycx with some tricky ROP chain to overcome fjsec protection. The LSM and SELinux are still in place after the system restart, so it's a subject for bootloader unlocking and the system modification, but no progress is made for that yet.