Database Users

Getting serious about root: FIOASYNC bug

Presently we're running a little short on kernel exploits, with the following being the only one that looks remotely plausible:
http://xorl.wordpress.com/2010/01/14/cve-2009-4141-linux-kernel-fasync-locked-file-use-after-free/
Big hold-up? For all that we have a trigger, we don't have an exploit. I believe it's up to us at this point to make that happen.
If I'm reading it right, it looks like the bug initially rears its head right here:
Code:
void __kill_fasync(struct fasync_struct *fa, int sig, int band)
{
while (fa) {
struct fown_struct * fown;
if (fa->magic != FASYNC_MAGIC) {
printk(KERN_ERR "kill_fasync: bad magic number in "
"fasync_struct!\n");
return;
}
[B]fown = &fa->fa_file->f_owner;[/B]
/* Don't send SIGURG to processes which have not set a
queued signum: SIGURG has its own default signalling
mechanism. */
if (!(sig == SIGURG && fown->signum == 0))
send_sigio(fown, fa->fa_fd, band);
fa = fa->fa_next;
}
}
... as fa_file now points to invalid memory (having been free'd earlier). The f_owner member gets shot out to send_sigio, which look like this:
Code:
void send_sigio(struct fown_struct *fown, int fd, int band)
{
struct task_struct *p;
enum pid_type type;
struct pid *pid;
int group = 1;
read_lock(&fown->lock);
type = fown->pid_type;
if (type == PIDTYPE_MAX) {
group = 0;
type = PIDTYPE_PID;
}
[B]pid = fown->pid;[/B]
if (!pid)
goto out_unlock_fown;
read_lock(&tasklist_lock);
do_each_pid_task(pid, type, p) {
send_sigio_to_task(p, fown, fd, band, group);
} while_each_pid_task(pid, type, p);
read_unlock(&tasklist_lock);
out_unlock_fown:
read_unlock(&fown->lock);
}
... in which we see the f_owner member being dereferenced. Also it gets pushed through several other functions which may be exploitable.
There are several questions to be answered before we can start attacking this:
Can we resolve the address of the fa_file data structure so we can overwrite the f_owner value?
Can we do anything with it once we've done that? (Presumably we can set it to zero to cause a null-pointer dereference, but we're mmap_min_addr = 32768 on the most recent versions, so unless we can flag the mmap region to grow down and apply memory pressure to reach page 0 this will do us no good.)
Failing the plan above: are any of the functions that f_owner gets pushed into vulnerable? I evaluated this over the weekend, but without the help of a trained kernel dev I'm not going to get very far.
While I studied a lot of this in uni, I'll admit I'm green when it comes to actually writing these exploits. I'm hoping that this will get the creative juices flowing, and perhaps provide a more comprehensive resource in case any hard-core kernel hackers want to take a look at what we're doing or give us pointers (harhar) in the right direction.
Thanks, guys. Great work up to this point.

In the original POC if you change /bin/true to /system/bin/sh you can get a new shell to open just not as root. So I'm guessing that their needs to be more added to the POC to make it a full exploit.

Right, the fork()'s in the PoC exist only to cause the file descriptor's fasync_struct to be erroneously killed, not start a root session. The root session would need to be started (presumably) by the kernel doing something to our maliciously crafted fown_struct.
The tough part is figuring out exactly where and what that fown_struct needs to be.

Well I definetly agree with you that this seems to be our best best bet I am some what of a newbie when it comes to linux allthough i am learning as i go. Do you know of any good sites to read up on kernel hacking?

Sorry Guys just got the word that this one is dead for us.....
Here is the explantion i got.
some_person said:
Nope, the bug didn't exist in 2.6.27. That's why they say >= 2.6.28 are vulnerable.
As far as how the bug works, there are 2 other issues. 1) our kernel probably wasn't compiled with AT_RANDOM 2) we don't have an elf executable.
The exploit you found does not give us root access, it crashes the system. Basically, you open the "random number generator" file, lock it, and close it... but the lock release when you close it. Then you have to call an elf executable because that generates a random number (running an elf executable) provided the kernel was compiled AT_RANDOM. you continue to call that executable (and generating random numbers) until the the lock is released on the "random number generator" file... then it's your program's turn... the kernel tries to send your program notification that the file is available, but your program has moved on. BLAM the kernel stops (or "oops").
Click to expand...
Click to collapse

Sorry to dredge up an old thread:
This exploit *will* work. According to Zanfur, the hole is in our kernel. We need to use it without AT_RANDOM (which I dont know how to do).

http://sourceware.org/ml/libc-alpha/2008-10/msg00016.html

I am pretty sure we do have elf executables, here is proof:
% file m6
m6: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), not stripped
If our kernel is susceptible to this bug then it should work, as long as there is a way to do it without at random.

Though I do not in any way represent my self as a hacker or developer I was wondering if I could throw in my 2 cents. I notice that this bug/exploit won't work because it requires AT RANDOM. I was wondering if it s possible to write code that does what the function does and insert it in. Is root required to do this (i.e. insert code into the kernel that wasn't there before) or is this a matter of know-how? Just some brainstorming I thought that I would throw in.

jballz0682 said:
Though I do not in any way represent my self as a hacker or developer I was wondering if I could throw in my 2 cents. I notice that this bug/exploit won't work because it requires AT RANDOM. I was wondering if it s possible to write code that does what the function does and insert it in. Is root required to do this (i.e. insert code into the kernel that wasn't there before) or is this a matter of know-how? Just some brainstorming I thought that I would throw in.
Click to expand...
Click to collapse
This won't get us root. Even zanfur said it. Moving on....

Framework43 said:
This won't get us root. Even zanfur said it. Moving on....
Click to expand...
Click to collapse
To clarify, even if we get AT_RANDOM functionality working, we can't use this to exploit our kernel. All we can do with this is get data from a file that was recently closed. The point of this exploit is to send a signal to a process, but there are no processes we could send a signal to that would give us root.

Our kernel seems practically invulnerable, it appears that almost all exploits are patched

Kernel serial console on I9100

Hi,
I did some experimenting with getting kernel serial console output on SGSII I9100 without soldering, or even disasembling the device. And seems I succeeded .
So, for anyone interested, here are the details.
First, two warnings:
- you will loose access to CWM recovery! ODIN still usable though.
- no access to bootloader output, only kernel logging available
Now the steps:
enable UART PDA
Flash original samsung ROM (changes in service mode settings in cyanogenmod are not permanent for some reason, I haven't tried other ROMs)
Enter service mode by dialing *#7284#, select UART mode PDA (default is modem. No need to change USB mode to PDA, leave it as is).
Configure, build and flash the kernel
get your kernel command line using dmesg right after boot
modify the console parameter to console=ttySAC2,115200
configure your kernel with this command line (CONFIG_CMDLINE). In my case, the commandline used was:
Code:
loglevel=4 console=ttySAC2,115200 sec_debug.enable=0 sec_debug.enable_user=0 c1_watchdog.sec_pet=5 [email protected] s3cfb.bootloaderfb=0x5ec00000 ld9040.get_lcdtype=0x2 consoleblank=0 lpj=3981312 vmalloc=144m
set force override parameters passed by the bootloader (CONFIG_CMDLINE_FORCE=y)
build the kernel
build your ROM of choice (I have used cyanogenmod) with this new kernel
flash
power off the device, connect "standard" Samsung UART cable - microUSB with 523K resistor to ID pin, 3.3V to RS232 level converter
Now the phone should start and you should see kernel boot messages on connected terminal emulator.
Open questions:
Why UART switch changes are not permanent from cyanogenmod? Is this i known bug?
How to change bootloader parameters from within linux? E.g. kernel command line options... Does anyone know where are the persistent settings of the bootloader stored?
This information is mainly collected from many sources here on this forum, thanks to all of you for publishing your findings. I take credit only for putting all this information together and spending a lot of time trying it out . Also, I take no responsibility for any bricked devices, make sure you know what you are doing, before you start following my steps.
Hope this helps anyone .

--DELETED--

KickerTom said:
[*]Why UART switch changes are not permanent from cyanogenmod? Is this i known bug?
Click to expand...
Click to collapse
The only reason I see for this is kernel. Are you using CM7 or CM9 ?
What did you use as UART cable? Do you have a microUSB to RJ45 + Z3X, or some homemade all-in-one ?

I am using CM7.2RC0 KANG, updated yesterday. Kernel also latest git, home built. But I remember having this problem with "official" nightly builds as well.
For cable, I have my own micro USB with id pin on break out cable, so I can switch resistors, and home made level shifter made from a MAX chip, that connected via stock USB to serial to the PC.

Why not just change index 0x10 in /mnt/.lfs/param.blk?

Odia said:
Why not just change index 0x10 in /mnt/.lfs/param.blk?
Click to expand...
Click to collapse
More details on this? - is that what changes UART PDA?
For the kernel cmdline side of things - I have never found any way to override the kernel cmdline in a controllable manner. The bootloader has a fixed commandline, and it makes changes to it depending on what buttons are pressed (which is why you can't enter CWM via the button combos if you force the cmdline) However, if you're working with a custom kernel, you can just go find the handler for the console= option and force it to always be ttySAC2 regardless of what is passed in the source. This won't work for custom kernels. (Wait... neither will the OP's approach either, sorry - not enough caffeine yet.)
If there's another cmdline option you want enabled, you can overload one of the ones that is in use, and have it trigger other handlers (but those have to have their parameters hardcoded) - such as how garyd9 caused ramconsole setup to be triggered by the loglevel cmdline parameter at https://github.com/garyd9/linux_kernel_GT-P6210/commit/d796ac86dcff1eeda19d7638315dcf6fe3978318. If you're wondering why he did this to enable ramconsole - in the I777 and GT-P6210 source drops, ramconsole support seems to be improved compared to the I9100 source drops - it requires little to no extra patching AND it's controllable by the kernel cmdline - while that's normally an improvement, it's a pain in the ass if you can't change the bootloader to add the ramconsole cmdline parameters.

Odia said:
Why not just change index 0x10 in /mnt/.lfs/param.blk?
Click to expand...
Click to collapse
Never heard of this file before, now took a look and it looks very interesting. I will investigate this option further, thanks for the hint.
Entropy512 said:
For the kernel cmdline side of things - I have never found any way to override the kernel cmdline in a controllable manner. The bootloader has a fixed commandline, and it makes changes to it depending on what buttons are pressed (which is why you can't enter CWM via the button combos if you force the cmdline) However, if you're working with a custom kernel, you can just go find the handler for the console= option and force it to always be ttySAC2 regardless of what is passed in the source.
Click to expand...
Click to collapse
Yes, I agree that your approach is also usable. Advantage of your way is that you are not loosing CWM and such. Mine is that it's without ugly hacks in the kernel ;-).
Ultimate goal would be to modify the bootloader parameters, so kernel recompilation is not needed at all, but not sure it is possible - thats my next direction of research .
Entropy512 said:
This won't work for custom kernels. (Wait... neither will the OP's approach either, sorry - not enough caffeine yet.)
Click to expand...
Click to collapse
Sorry, not following you here. Custom kernel - you mean kernels compiled by third party, which we can't modify? Well, not sure you need a log for kernel you can't modify, maybe for bug reporting to original author? If the kernel works, you can get most of the log using dmesg... And I am not interested in binary-only kernels...
Entropy512 said:
If there's another cmdline option you want enabled, you can overload one of the ones that is in use, and have it trigger other handlers (but those have to have their parameters hardcoded) - such as how garyd9 caused ramconsole setup to be triggered by the loglevel cmdline parameter at github.com commit d796ac86dcff1eeda19d7638315dcf6fe3978318. If you're wondering why he did this to enable ramconsole - in the I777 and GT-P6210 source drops, ramconsole support seems to be improved compared to the I9100 source drops - it requires little to no extra patching AND it's controllable by the kernel cmdline - while that's normally an improvement, it's a pain in the ass if you can't change the bootloader to add the ramconsole cmdline parameters.
Click to expand...
Click to collapse
Maybe that's a better solution for a kernel distributed to users and such. What I was trying to achieve is to have serial log of a booting kernel so you can troubleshoot kernel which does not boot, or which hard-locks or oops. AFAIK, ram console is useless in such cases (correct me if I am wrong, I have very little experience with ram console).
As far as I am interested, the description above does exactly what I need .

KickerTom said:
Sorry, not following you here. Custom kernel - you mean kernels compiled by third party, which we can't modify? Well, not sure you need a log for kernel you can't modify, maybe for bug reporting to original author? If the kernel works, you can get most of the log using dmesg... And I am not interested in binary-only kernels...
Click to expand...
Click to collapse
That was a brainfart - meant it won't work with stock kernels!
The ramconsole approach was just meant as an example - but instead of hooking loglevel to do ramconsole stuff, you could hook it to do other stuff. Of course here, since there's already a serial cmdline entry but it's just wrong, it's easy to just override.
As an example, I abused the "overload the loglevel handler" trick to try and enable profiling. (However, profiling didn't let me get any info on which interrupt handler is eating our IRQ time on suspend/resume.)

Just for reference, here is the cable I am using. There is a stock prolific PL-2303 based USB to serial converter (the grey cable), then a RS232 to 3.3V TTL level shifter (home made, built into the DB9 conector), and then there is a stock micro USB cable. The connection between these two is on this connector for easy re-configuration, as I am using the level shifter for other purposes as well.
The micro USB cable is stock microUSB to USB-A, but I cut off one end to connect it to the level shifter, and I have also cut the micro USB conector to connect a cable to the ID pin. That one and ground are on the blue/white cable, for easy resistor switching.
Except for the ID resistor (523K according to the table, some 507K in my case), all electronic parts are SMD .

A good source for USB-to-TTL/LVTTL cables is FTDI - they sell FT232-based cables. Adafruit is a good vendor for these in the USA.

Just noticed you can get bootloader output by booting the phone and shortly pressing Volume Down (shortly so that it doesn't boot into Download mode). I did it by accident and saw some Samsung PBL logging on my screen.

XpLoDWilD said:
Just noticed you can get bootloader output by booting the phone and shortly pressing Volume Down (shortly so that it doesn't boot into Download mode). I did it by accident and saw some Samsung PBL logging on my screen.
Click to expand...
Click to collapse
Cool. If you can get the bootloader prompt, we are maybe a step closer to being able to even unbrick phones .
So far, I was not able to reproduce this, can you, please, describe better the steps? Also, what version of bootloader do you use?

I did it once by accident, I haven't retried. Basically when I booted phone I mistakenly pressed the Volume Down button with the Power button, but not long enough to make it boot in download mode.
I'm not sure which bootloader I'm running, I think it is some LPx one (if flashing KI4 PDA doesn't overwrite it).
Here's the log of it:
http://pastie.org/3544766

Following up on Odia's hint (thanks ), I decoded the structure of the params.blk file and wrote an utility to deal with it. The file contains parameters normally visible in SBL. With this utility, you can manipulate then from within normally booted phone.
Run it without parameters, it will display current values for all parameters. With parameter name (case insensitive), it will display just that one parameter, run it with param name and value, it will set the new value.
WARNING: no checking on validity of the values is done. If you brick or fry your phone, I take no responsibility and it is your brick!
Put the utility somewhere where you can execute it, e.g. /data. Then to set e.g. a kernel command line to start logging on console, issue:
sblparam command_line "loglevel=4 console=ttySAC2,115200"
From my experiments it looks like the SWITCH_SEL parameter is ignored by the HW, at least I haven't observed any real effect. But you can change the UART switch by modifying a file next to the param.blk, /mnt/.lfs/sw_sel. It contains an ASCII number, by default 1. That is modem uart. Change it to 3 to get PDA uart connected, by e.g. "echo -n 3 > /mnt/.lfs/sw_sel".
Please, be careful about files in /mnt/.lfs, the j4fs is a strange filesystem. You can create files there, but you can't delete them. If you grow a file, you can't trim it back down. I tried longer numbers in sw_sel, and I broke the output completely, and I had to restore the whole .lfs partititon from backup (which reminds me - do a backup first , e.g. with dd).
Now there is no need to flash samsung firmware or compile custom kernel to get kernel console anymore! .

EPIC WIN!!!
This is going to be very nice.

This is amazingly cool!!! Maybe we can get even more...
Inviato dal mio GT-I9100 usando Tapatalk

My kernel finally boots
Seems like I get everytime the bootloader output by booting the phone with Power + Vol Down while having UART cable plugged in, then releasing the buttons when log starts to appear to make it not go into Download mode.

XpLoDWilD said:
My kernel finally boots
Click to expand...
Click to collapse
Wow, congratulations! Looking forward to try out your kernel with CM9 .
XpLoDWilD said:
Seems like I get everytime the bootloader output by booting the phone with Power + Vol Down while having UART cable plugged in, then releasing the buttons when log starts to appear to make it not go into Download mode.
Click to expand...
Click to collapse
Hmmm, must be really something with your kernel. I was not able to get any bootloader messages, and my unit always turn on as soon as I insert the cable.
AFAIK, the resistor is "read" and attach interrupt asserted by the FSA9280 switch. So it looks like your kernel "programs" the switch not to wake up the CPU? Maybe the switch has interrupt assert masked out? I will check the switch sources, when I get some time, maybe I find something interesting...

KickerTom said:
Wow, congratulations! Looking forward to try out your kernel with CM9 .
Hmmm, must be really something with your kernel. I was not able to get any bootloader messages, and my unit always turn on as soon as I insert the cable.
AFAIK, the resistor is "read" and attach interrupt asserted by the FSA9280 switch. So it looks like your kernel "programs" the switch not to wake up the CPU? Maybe the switch has interrupt assert masked out? I will check the switch sources, when I get some time, maybe I find something interesting...
Click to expand...
Click to collapse
I'm wondering if maybe he uses a different resistor value than you do. If I recall, there were multiple values that could trigger UART mode.
The difference in behavior being seen goes earlier in the boot process than kernel boot.

Entropy512 said:
I'm wondering if maybe he uses a different resistor value than you do. If I recall, there were multiple values that could trigger UART mode.
Click to expand...
Click to collapse
No, he does not (apart from the fact that no two resistors are exactly the same ;-) ). I know, because I made both cables ;-).
Moreover, I tried couple of different resistor values, and found none which would not trigger the boot on my unit. You can get e.g. car mode active together with UART with slightly different resistor, but AFAIK, you can not prevent the boot trigger.
Entropy512 said:
The difference in behavior being seen goes earlier in the boot process than kernel boot.
Click to expand...
Click to collapse
Yes, for sure. But don't forget that "turning off" the phone does not mean all ICs in the phone are really powered off. E.g. the switch IC is, AFAIK, always on (unless you pull the battery). So you can set the interrupt mask in the switch and then turn off the main CPU. When UART cable is detected by the switch, it uses the mask to trigger or not trigger interrupt to the CPU.
Which brings another idea - XpLoDWilD, can you, please, try pulling out the battery, put it back and then connect the cable? The switch does not have any means of persistent storage, according to the spec sheet, so if there is no hidden easter egg, then the cable should trigger boot in this case, I believe.

[WIP] Open Bootloader Development for Archos Gen8

Hey geeks,
you might know my hardware hacking thread already:
http://forum.xda-developers.com/showthread.php?t=1199450
Some time ago i started thinking about starting with an open bootloader for Archos Gen8.
So i started from scratch and made use of external boot mode to completely start from external MicroSD and leave the internal memory alone.
Remark: This is a geek project, there's no GUI or something. So don't expect anything useful right now.
At the moment you'll need some hardware hacking, because you'll need a serial console over uart3.
Unfortunately you'll also need a dirty hack to power up the MicroSD permanently.
Don't hesitate to ask for details about it.
So this is for the weird ones out there...
Right now there's work in progress, because stock kernel stucks at some point in the boot process.
Maybe there's some setup missing in the bootcode (it's very basic at the moment) or stock kernel relies heavily on avboot at some point.
I will work on this issue whenever i'll find some time.
Anyway it might be still an interesting project for at least a very few of you, so here's the source code:
- x-loader-archos
- u-boot-2011.09-archos
As pointed out the Archos implementation is very basic at the moment, but the code itself works very well and had been tested on A101IT Gen8.
To further devices, e.g. A70S Gen8, the machine id had to be included in the board file, the rest of the setup in early stage should be very similar.
The code bases:
- x-loader (https://gitorious.org/x-loader/x-loader)
- u-boot (taken from this archive: http://www.technexion.com/images/downloads/ARM_CPU_Modules/TDM-3730/linux-2.6.32-tdm3730.tar.xz)
I'd like to switch to official u-boot release 2011.09 as a base soon.
To start playing with it:
- open your case and start hacking, to get serial console working
- tweak the hardware to power the MicroSD slot permanently
- create a bootable MicroSD for OMAP systems
- place the binaries on your card
- insert the card and use vitalifs kernel module to reboot your device in external bootmode
Please refer to these posts from vitalif (thanks a lot for contributing!!!):
http://forum.xda-developers.com/showpost.php?p=22719203&postcount=105
http://forum.xda-developers.com/showpost.php?p=22765441&postcount=108
You might start digging in the source code and create your own loader:
- use a linux machine with a recent distribution
- setup a cross environment with ARM cross compiler suitable for ARMV7
- extract the sources to directory of your choice
- to compile x-load:
Code:
cd ./x-loader-archos
make archos_config
make
- to compile u-boot-2011.09-archos:
Code:
cd ./u-boot-2011.09-archos
make a101it_config
make
It might be required to tweak the top-level Makefiles to point at your toolchain.
I used my ready to work toolchain (for 32-bit linux only) here:
http://forum.xda-developers.com/showthread.php?t=1328027
Unfortunately i haven't found some time to create a project page at gitorious,
but hopefully i'll manage to do so in the next weeks...
I know this is a very very special project, but anyway if there's some interest, this might lead to something useful in the end.
If the bootcode is working very nice some day, it might also be possible to replace stock loader, but that's fiction yet.
You might ask what for...
I say... it's just for fun!
cheers,
scholbert

Boot console output... so far
Hey,
it had been posted already but her again for completeness...
The console log on UART3 starting custom kernel configured with stock config:
Code:
Texas Instruments X-Loader 1.5.1 (Mar 26 2012 - 20:41:11)
Found 0256 MB
Archos Gen8
Reading boot sector
Loading u-boot.bin from mmc
Done!
U-Boot 2011.09 (Mar 23 2012 - 18:53:39)
OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz
Archos 101IT Gen8 + LPDDR/MMC
I2C: ready
DRAM: 256 MiB
MMC: OMAP SD/MMC: 0
Using default environment
In: serial
Out: serial
Err: serial
Die ID #144800029ff800000160a4bb18027009
Hit any key to stop autoboot: 0
reading boot.scr
** Unable to read "boot.scr" from mmc 0:1 **
reading uImage
2987000 bytes read
Booting from mmc ...
## Booting kernel from Legacy Image at 82000000 ...
Image Name: Linux-2.6.29-omap1
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2986936 Bytes = 2.8 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux.............................................................
................................................................................
..................................................... done, booting the kernel.
<6>Initializing cgroup subsys cpu
<5>Linux version 2.6.29-omap1 ([email protected]) (gcc version 4.4.1 (GCC) ) #1
PREEMPT Thu Mar 22 23:59:34 CET 2012
CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: Archos A101IT board
fixup_archos: [console=ttyS2,115200n8 androidboot.console=ttyGS0 init=/linuxrc d
ebug omapdss.debug=0 vram=4915200 omapfb.vram=0:4915200 omapfb.debug=0 mmc_block
.split=0.0001:512M]
Memory policy: ECC disabled, Data cache writeback
<7>On node 0 totalpages: 65536
<7>free_area_init_node: node 0, pgdat c05fd368, node_mem_map c06a5000
<7> Normal zone: 512 pages used for memmap
<7> Normal zone: 0 pages reserved
<7> Normal zone: 65024 pages, LIFO batch:15
<4>L2 CACHE is enabled in bootloader
<6>OMAP3630 ES1.2
<6>DIE ID: 144800029FF800000160A4BB18027009
<6>FEATURE_STATUS: 00000c00
<6>SRAM: Mapped pa 0x40200000 to va 0xfc800000 size: 0x100000
<6>Reserving 4915200 bytes SDRAM for VRAM
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
<5>Kernel command line: console=ttyS2,115200n8 androidboot.console=ttyGS0 init=/
linuxrc debug omapdss.debug=0 vram=4915200 omapfb.vram=0:4915200 omapfb.debug=0
mmc_block.split=0.0001:512M
<3>Unknown boot option `androidboot.console=ttyGS0': ignoring
<3>Unknown boot option `omapdss.debug=0': ignoring
<6>Clocking rate (Crystal/DPLL/ARM core): 26.0/332/600 MHz
BTW, i extracted the function from Archos loader setup up PLL and MPU stuff.
Need some time to extract the stock setup for PLL at early stage.
Maybe this will give some answers.
One of my next plans is, to build some kind of bare bone kernel (console only), which may be used for recovery and debug purpose.
Maybe this gives it a kick and things start up to a login shell
TBC
Have fun!
scholbert

One of my next plans is, to build some kind of bare bone kernel (console only), which may be used for recovery and debug purpose.
Maybe this gives it a kick and things start up to a login shell.
Click to expand...
Click to collapse
Seems like an internal monologue... but i like to point out that i stopped this project for a while.
So don't expect anything like a brick recovery tool or similar.
If others will join in it might be possible that it would led to something,
but as long as no one even starts hacking the hardware this is just for me...
Happy days!
scholbert

scholbert said:
Seems like an internal monologue... but i like to point out that i stopped this project for a while.
So don't expect anything like a brick recovery tool or similar.
If others will join in it might be possible that it would led to something,
but as long as no one even starts hacking the hardware this is just for me...
Happy days!
scholbert
Click to expand...
Click to collapse
Shame you stopped your efforts for now, I always followed your posts with much interest. However I can understand it is frustrating being on your own.
Thanks for what you did this far and for posting your info .
divx118

Sorry to read that, this was a very very interesting reading.
But I don't have the knowledge to make the necessary hardware hack, and above all, my wife would kill me if she saw me opening the tab
Thanks again for all that amazing information scholbert

Hey,
first off all thanks for your interest and your replies
Some words on your comments though...
divx118 said:
Shame you stopped your efforts for now, I always followed your posts with much interest. However I can understand it is frustrating being on your own.
Click to expand...
Click to collapse
I did not want to sound frustrated, because i'm not.
All i do with the device and all that hacking stuff is fun and mostly for educational purpose
Maybe i'll continue working with this stuff, but for now i wanted to point out to not expect too much.
Some guys out there, bricked their devices and were looking for a solution.
That's why i wrote it down.
Basically it should be possible to recover bricks by using external boot procedure, but it's still far from a simple solution.
grim-a101 said:
Sorry to read that, this was a very very interesting reading.
But I don't have the knowledge to make the necessary hardware hack, and above all, my wife would kill me if she saw me opening the tab
Click to expand...
Click to collapse
Yeah that's a good point, the barrier for this kind of hacking is little high.
Unfortunately you'll have to tweak the hardware, to gain access to the serial debugging port and cheat the power management of the MicroSD slot.
Most of you simply want to use the device and do some less harder tweaks at system level.
Anyway, there are some other possibilities as well (e.g. using USB and TI Flash) to access the platform. Maybe i'll do some research here as well.
Thanks again for appreciation!!!
Regards,
scholbert

Root+Xposed+Busybox for Bootloader Locked Moto X ATT/VZW

Only fresh flashed bootloader locked XT1058 AT&T - ROM LPAS23.12-21.7-1, and XT1060 VZW - ROM LPAS23.12-39.7-1 are supported!
See archive content for instructions. Time to install ~20 min. If you experience problems after Android boot, like not working buttons or quick settings, wipe cache + data partitions. Don't update SuperSU (disable auto updates), it won't work. Later I'll post complete debloated ROMs with fresh SuperSU version, and simplify instructions. Be informed also, that this method doesn't give you read-write rights like unlocked bootloader. You may read and write having root-rights, but only till a restart or shutdown occurs, and every change will be undo by the Qualcomm protection (like HTC' s=on).
At the moment patch includes:
SuperSU 2.65 Free
Xposed Framework v86 (installer, modules)
Busybox 1.25.0.YDS, path /system/xbin/busybox
Download
P.S. Install only on indicated above ROM versions, and it's obvious that you must have enough theory knowledge and practical experience to make use of 9008 patch, so I'm not responsible for any consequences, etc. Greets go to: CrashXXL (method inventor), Sabissimo (our former OP), and serg_gangubas (ROM guru).
==============================================================================================
31.07.2017 - Full ROM Patch for Bootloader Locked Moto X ATT/VZW/etc
Based on the same principle, and not depend on system partition content, so it suits any bootloader locked Moto X Gen1 ATT/VZW (possibly any model, besides 1049 RepW / 1055 US Cell), but takes about 4 hours to be done - prepare for that, 100% battery level only!
This full ROM patch includes:
SuperSU 2.82 Free
Xposed Framework v87 (installer, modules)
Busybox 1.26.2, path /system/xbin/busybox
ViperFX 2.5.0.5 - sorry needs polishing, removed now (
Gallery and Camera not depend on Moto services
Gboard instead AOSP Keyboard. If it eats too much RAM, see Simple Keyboard
GAPPSes updated. Use command like adb shell pm uninstall --user 0 com.blahblah.blah to block any unwanted app or service
ES File Explorer Free Edition (a clone, you can disable and install yours )
"Jedy" gesture
AdBlock support (effect lasts till the 1st reboot yet, I'll think about make it constant). Please, choose /data/hosts instead of /system/etc/hosts
ROM debloated, but not deodexed.
Download
Instruction
Be careful, phone will be WIPED then flashed in 9008 "brick" mode (CrashXXL idea). Before you start install Moto drivers, latest RSD Lite, and fully charge the battery.
1) Download and unpack zip on С: (or any), open Python27, launch RUN_path.bat (needs to be launched only single time), install driver QHSUSB_driver.exe, and launch file _Moto.X.BootLocked.*.exe (where * - is desired ROM).
2) Go into fastboot mode, execute RUN_blbroke.bat. Screen gets black, Device Manager in Windows finds "QHSUSB_DLOAD", and installs it as "Qualcomm HS-USB QDLoader 9008 (COM*)". If it doesn't install, google for Windows driver digital signature disable.
3) Now launch RUN_root.bat, and see that patching process took start.
4) A small patch *SPEAKERS.BOOST.exe (if exists) boosts both speakers' volume.
P.S. Please, don't flash anything extra into the phone. In case of trouble, all you need is inside this folder. Just make it work.
To make "Battery OK" in fastboot use fastboot_cyclecharge.bat
Completely drained out battery causing "USB input device" needs disassembly of the phone to charge externally.
In case Titanium Backup shows error "Batch backup interrupted: insufficient free storage space", delete default backup folder, and make a new:
Titanium Backup > Menu > Preferences > Backup folder location > Storage Provider > DocumentProvider storage > Show Internal Storage > Internal Storage > Select Internal Storage > Create the folder > Use the current folder. Done!
Notes for myself: Viper, force wipe, readme.txt, volume patch, Adblock, advanced debloat

Debloated, rooted, lightweight ROM - soon! )
PUBLISHED. Sorry, took long time.

As soon as I can actually get 5.1 flashed I'll try this.
Though I'm afraid I'll have to try to go to stock and use sunshine first, still have a locked BL.
But this is great, I didn't expect root so soon.

DownTheCross said:
As soon as I can actually get 5.1 flashed I'll try this.
Though I'm afraid I'll have to try to go to stock and use sunshine first, still have a locked BL.
But this is great, I didn't expect root so soon.
Click to expand...
Click to collapse
This method is working on locked BL.

DownTheCross said:
As soon as I can actually get 5.1 flashed I'll try this.
Though I'm afraid I'll have to try to go to stock and use sunshine first, still have a locked BL.
But this is great, I didn't expect root so soon.
Click to expand...
Click to collapse
Wait wait... If you can have now possibility to unlock bootloader - go for it immediately! You will have normal FULL root-rights (SuperSU 2.49). Don't install 5.1, if you plan to unlock, because Sunshine app (25$) works only on 4.4.2 Android.
This topic is to help those AT&T users that are boot locked forever (who missed out possibility to unlock on 4.4.2 by proceed to 5.1) to give them READ-ONLY root. Yes, it's limited, but anything at least.

s5610 said:
If you can have now possibility to unlock bootloader...
Click to expand...
Click to collapse
I guess anyone on 4.4.4 today. There is no possibility to use Sunshine anymore.
Anyway spasibo za method

Ahh, if I don't have to be BL unlocked that's great lol.
I haven't read too much into the 5.1 updates or sunshine for that matter.
I've been on krypton 1.4.1 since it was released, and I haven't been able to successfully upgrade to any 5.1 roms yet.

Works great!
Works great for me on Windows 10 RTM 64-bit! Thanks a ton, I was waiting for a post like this.
I only had 3 minor hiccups:
1. RSD Lite gave me an error about "getvar", so I had to go into flashfile.xml in the ROM zip and remove the line that said getvar
2. I had to reboot to disable driver signature enforcement twice for some reason because Windows Update
3. The run-root.bat got stuck on "Executing..." because I installed the wrong driver (the correct file is qcusb.inf when installed from device manager -> browse my computer for driver software -> let me pick from a list -> all devices -> have disk)
Otherwise, everything runs just as well as KitKat, including Xposed.

Hehe got to love step 9

System Write
How can we help in getting the system write to zero using the same method,because I have xt1058 model bootloader unlocked and I provide any file needed to disable the pesky system write...

How can we help in getting the system write to zero using the same method,because I have xt1058 model bootloader unlocked and I provide any file needed to disable the pesky system write...
Click to expand...
Click to collapse
First, never quote op. It takes way to much space and is redundant.
Second, to get write off we would need to some how either start a custom kernel some magical way or disable it via a kernel mod like htc guys did. Another way, which was done before was to burn the efuse but kernel has been patched since then.

Need some help, I did all steps until step 9. I installed the QHSUSB_DLOAD driver manually, and I can see 'Qualcomm HS-USB QDLoader 9008 (COM4)' showed in my Device Manager, but when I run 'RUN_Root.bat', I got this
c:\Python27>python qdloadRoot.py MPRG8960.bin -ptf root/partitions.txt
QDLoad utility version 1.2 (c) VBlack 2014
Found TTY port: com4
Sending MAGIC ...
QCOM fast download protocol targ:
Version: 7
Compatible version 2
Maximum block size 1024 (0x00000400)
Base address of Flash 0x00000000
Flash: eMMC
Window size: 30
Number of sectors: 128
First sector size: 2097152 (0x00200000)
Feature bits: 09
Sending SBL Reset...
Done
c:\Python27>pause
Press any key to continue . . .
Then I tried to run 'RUN_Root.bat' again, then I got
c:\Python27>python qdloadRoot.py MPRG8960.bin -ptf root/partitions.txt
QDLoad utility version 1.2 (c) VBlack 2014
Found TTY port: com4
Requesting Params...
Params:
Version: 8
Min version: 1
Max write size: 1536 (0x00000600)
Model: 144
Device size: Invalid or unrecognized Flash device, or Flash device progr
amming not supported by this implementation
Device type: Intel 28F400BX-TL or Intel 28F400BV-TL
Requesting SoftwareVersion...
Version: PBL_DloadVER2.0
Requesting SerialNumber...
Serial number: 00,00,48,03
Requesting HW Id...
HW Id: 00,00,48,03,e1,10,7e,00
Requesting PublicKey...
PublicKey: 39,c4,ee,3e,b5,be,eb,87,8e,2f,e3,b8,53,4d,14,6f,91,ca,fd,bb,94,2a,0d
,aa,d0,1e,b0,87,62,d4,b9,b8
Uploading file 'MPRG8960.bin' to addr 0x2a000000...
Executing...
Could not find Qualcomm device in Emergency download mode
Done, with errors!!!
c:\Python27>pause
Press any key to continue . . .
any suggestions? Thanks

jahrule said:
First, never quote op. It takes way to much space and is redundant.
Second, to get write off we would need to some how either start a custom kernel some magical way or disable it via a kernel mod like htc guys did. Another way, which was done before was to burn the efuse but kernel has been patched since then.
Click to expand...
Click to collapse
Ill put the files here

Fantastic!!! I was looking this. All the last week I was sleeping about 3 hours per day trying to root my phone.
----
I scream "Victory" before the process finish.
Damn! My phone reboot and stay in the android doll fallen screen.

DejanPet said:
Ill put the files here
Click to expand...
Click to collapse
What to do with these files?

Those files are needed by Jahrule

Sabissimo
Hello.
I did everything as instructed, but eventually got the screen "no command".
The only thing I did not flash rom - a month ago updated by an OTA to 5.1, thought it was not necessary.
Factory reset does not help.
Advise something.
In the end, everything worked, thank you))

It works
It works great! Thank you very much! ATT xt1058.

eze_cba17 said:
Damn! My phone reboot and stay in the android doll fallen screen.
Click to expand...
Click to collapse
Follow the OP instruction EXACTLY, no exceptions!
If you got your current 5.1 through AT&T OTA, it's not enough for root patching procedure. A full RSD 5.1 official SBF flash over is required.

Could someone please do a video on this. I'm having a little trouble.

[Discontinued]

---

---

---

---

---

For owners of Xiaomi Air 12 or 13 that are facing static sound in Audio cause of Windows 10 please update your Realtek driver from their own website and not use windows update or general update. You need to download the latest 64bit driver dated ' 14-Jun-17 - 6.0.1.8186 '

@Wootever, sorry for my unrelated question. But, I have a Xiaomi Air 13 2016 and I've set a supervisor password when I changed to Linux. I then removed the password when I changed back to Windows 10, but it's still asking me for one...
Do you happen to know a way on how to remove the BIOS password on this laptop? I've extracted the executable from Insyde H20 A06 updater and changed the platform.ini, so it does a force flash of the password area (Password=1), however, it's still asking for one.. Any help would be greatly appreciated! Thanks in advance

@r00tPT
Try to set the password again and then set it to blank.

Wootever said:
@r00tPT
Try to set the password again and then set it to blank.
Click to expand...
Click to collapse
Thanks, but I cannot set the a new password, as when I try to access the BIOS, it asks me for a password..
I wanted to reset this password altogether, so I can access my BIOS and set a new one =/

@r00tPT
You can try to flash this default BIOS A06 Package, it will overwrite all device specific data (Serial, Windows Key, NVstore).
All settings should be set to default (including the password), but i haven't tested this (no guarantee and at your own risk).
Edit:
Don't forget to create a backup using the Backup.cmd file, it should be possible to restore the Serial number on the "empty" default BIOS.

Wootever said:
@r00tPT
You can try to flash this default BIOS A06 Package, it will overwrite all device specific data (Serial, Windows Key, NVstore).
All settings should be set to default (including the password), but i haven't tested this (no guarantee and at your own risk).
Edit:
Don't forget to create a backup using the Backup.cmd file, it should be possible to restore the Serial number on the "empty" default BIOS.
Click to expand...
Click to collapse
Thank you, Wootever! I think it's worth a try.
Would it make sense to create the backup, flash the default package, confirm if there's no password and then flash back the original Xiaomi BIOS to restore the Serial number?
Sorry, as I have near to none experience related to bios. thanks once again

@r00tPT
The backup includes all current settings (including the password), restoring it would also re-enable the password protection.
I made a little script to restore the device serial from the backup.bin file.
This is necessary because the Windows Activation seems linked with the device serial number.
Edit:
Updated the script.

Wootever said:
@r00tPT
The backup includes all current settings (including the password), restoring it would also re-enable the password protection.
I made a little script to restore the device serial from the backup.bin file.
This is necessary because the Windows Activation seems linked with the device serial number.
Edit:
Updated the script.
Click to expand...
Click to collapse
Wouldn't it be best to make a backup of the current bios with a flash programmer? I still haven't done this, as I'm trying to figure out what password I put.. (I basically set a supervisor password when I disabled secure boot, but then when I tried to set a new blank password it didn't change it back)
I have a friend who has the exact same laptop. Would it be fine if I made a backup of his bios and restore it into mine?
Could there be an issue or some missing information? Probably only the device serial number, which I could write again using your script? Would that be feasible?
By the way, sorry for asking these questions here/to you, but it's hard to find some guidance regarding this topic. Thanks once again

@Wootever, it worked!! You're the greatest man! I'm now able to access my BIOS again!
Is there any way to re-enable the flash protected range register again, just in case?

Wootever said:
I just got my hands on a Xiaomi Air 13 (2016 version) and wanted to share my findings.
The BIOS version of this device is A07, which is not yet made available by Xiaomi and originally, BIOS updates can only be flashed with the Insyde tools.
However, those require a valid certificate to correctly sign the binary file, thus a provided backup of version A07 won't be applicable as a update.
Intel Flash Programming tool is another alternative which allows to flash unsigned/customized versions, but in practice FPT can't access the BIOS region due to the protected range register which prohibits write access.
Code:
Error 316: Protected Range Registers are currently set by BIOS, preventing flash access.
Please contact the target system BIOS vendor for an option to disable Protected Range Registers.
Fortunately there is an undocumented variable switch that i found by coincidence which deactivates the flash protected range register.
For this i made a little tool which automatically patches the variable to allow BIOS update via FPT.
Note: modifying your BIOS is at your own discretion, i am not responsible for any damage caused by this procedure.
Download my variable patcher, extract it and execute Patcher.cmd
Reboot your device.
Download BIOS A07 for the Xiaomi Air 13 (2016)
Execute Backup.cmd to create a backup of your current BIOS.
Then execute Update.cmd to install version A07.
Use Serial.cmd to restore the device serial number from the backup BIOS.
Reboot your device.
I also made a few changes for this BIOS:
Updated microcode to 0xBA
Increased PWM frequency to 5000 Hz
Click to expand...
Click to collapse
I tried but I have this problem with patcher, any suggestion?

@Wootever
1) after upgrading the bios, how do i re-activate the flash protected range register?
2) do you have the default clean A07 bios (without the microcode and PWM changes)?
thank you!

May I ask if there is an easy way to unlock BIOS totally on Xiaomi Air 13? Because previously I opened a topic about it in biosmods.com , someone reached to me and told that due to write protection it needs quoting from him: "Bios mod can be flashed using SPI-programmer+SOIC8 clip only". That requires opening laptop up and connecting clip on chip physically. I love to tinker things in my laptop but that is a bit scary for me. So is there another way to do it, anyone knows??

THANK YOU!! This is pure gold! By the way, does the flag you found also unlock the ME region?
Update: nevermind. The answer is no unfortunately

bigorbi said:
May I ask if there is an easy way to unlock BIOS totally on Xiaomi Air 13? Because previously I opened a topic about it in biosmods.com , someone reached to me and told that due to write protection it needs quoting from him: "Bios mod can be flashed using SPI-programmer+SOIC8 clip only". That requires opening laptop up and connecting clip on chip physically. I love to tinker things in my laptop but that is a bit scary for me. So is there another way to do it, anyone knows??
Click to expand...
Click to collapse
No, you can flash any bios mod with the flag found by @Wootever. However, you may want to get a programmer (Altera USB blaster has cheap Chinese clones supported by flashrom) and a SOIC8 clip anyway just in case. They're dirt cheap and allow for recovery when things go wrong.
As a bonus, an external programmer enables you to get rid of the management engine.

CARLiCiOUS said:
THANK YOU!! This is pure gold! By the way, does the flag you found also unlock the ME region?
Update: nevermind. The answer is no unfortunately
Click to expand...
Click to collapse
It might be possible if the variable for ME Image Re-Flash is set:
Code:
Me FW Image Re-Flash, Variable: 0xD08
Disabled, Value: 0x0 (default)
Enabled, Value: 0x1
Variable to unlock protected range register:
Code:
BIOS SPI Lock:, Variable: 0x258
Enabled, Value: 0x1 (default)
Disabled, Value: 0x0
Edit:
Here is another variable patcher that also enables the ME Re-Flash variable.
(Note: not tested, use with caution)