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

[Q] WiFi problem on pinkflozd CM kernel

Hello all Forum Users.
Unfortunately I'm not yet allowed to post on Android Development, so I have to write here.
I would be gratuful if someone could post a link there or permit me to write there:
http://forum.xda-developers.com/showthread.php?t=2180085
I'm quite experienced FreeBSD kernel developer and I would like to get involved into pinkflozd CM kernel development.
I'm almost newbe to Linux kernel but I think there are some problems with WiFi on e610 devices.
I have the latest CM 10 with pinkflozd CM kernel v0.70.
Everything seems to work OK except from the Wifi.
When the WiFi is off, "lsmod" shows only "frandom" module - it's OK.
When I turn the WiFi on, "lsmod" shows also "librasdioif" and "wlan" modules loaded
but the WiFi is unable to turn on and the modules are unloaded soon.
"dmesg" show some info (not including everything):
- wlan0: link is not ready (many times)
- init: untracked pid xxxx exited
- wlan: unloading driver v0.2.2.542
- <many other errors>
- libra sdio remove : Module removed.
I also tried "l5_wifi_fix" - it didn't help.
I can send more debug info if required. I am not familiar with the Android "log" subsystem.

I have a problem with the 3G Data Connection. The WiFi is working fine, sorry I can't help about it. I just didn't know where to ask my question. How can i fix data connectivity? before flashing CM10, on original ICS it was working just fine. I also tried flashing only the ROM without the pinkflozd kernel, still no connectivity. In settings its set on "allowed" or whatever it says. Please help. :/

l5_wifi_fix must be started from PC, there is fix.cmd, of course phone must be connected by USB

Andro995 said:
I have a problem with the 3G Data Connection. The WiFi is working fine, sorry I can't help about it. I just didn't know where to ask my question. How can i fix data connectivity? before flashing CM10, on original ICS it was working just fine. I also tried flashing only the ROM without the pinkflozd kernel, still no connectivity. In settings its set on "allowed" or whatever it says. Please help. :/
Click to expand...
Click to collapse
I'm afraid I can't help. Everyone says that 3G Data Connection starts working after the second reboot.
Try reboot and then run "dmesg" from the terminal. Scroll it and try to find something which might be useful to solve the problem.

twisted_tits said:
l5_wifi_fix must be started from PC, there is fix.cmd, of course phone must be connected by USB
Click to expand...
Click to collapse
Thanks, I know it. I've rewritten the script so it could be executed from Linux.

Some dmesg output
I have something like that when booting PinkFlozd kernel:
<4>[ 23.496161] ------------[ cut here ]------------
<4>[ 23.496248] WARNING: at arch/arm/mach-msm/clock.c:196 clk_disable+0x138/0x148()
<4>[ 23.496274] ebi_grp_3d_clk is unbalanced
<4>[ 23.496288] Modules linked in: wlan(P) librasdioif frandom
<4>[ 23.496351] [<c00467c4>] (unwind_backtrace+0x0/0x138) from [<c00d5e00>] (warn_slowpath_common.constprop.7+0x4c/0xd0)
<4>[ 23.496391] [<c00d5e00>] (warn_slowpath_common.constprop.7+0x4c/0xd0) from [<c00d5ea8>] (warn_slowpath_fmt+0x24/0x34)
<4>[ 23.496428] [<c00d5ea8>] (warn_slowpath_fmt+0x24/0x34) from [<c00569c4>] (clk_disable+0x138/0x148)
<4>[ 23.496466] [<c00569c4>] (clk_disable+0x138/0x148) from [<c046dd9c>] (_sleep+0x108/0x3ec)
<4>[ 23.496499] [<c046dd9c>] (_sleep+0x108/0x3ec) from [<c046eadc>] (kgsl_idle_check+0x154/0x1c8)
<4>[ 23.496538] [<c046eadc>] (kgsl_idle_check+0x154/0x1c8) from [<c00f0d44>] (process_one_work+0x1ec/0x354)
<4>[ 23.496573] [<c00f0d44>] (process_one_work+0x1ec/0x354) from [<c00f10a0>] (worker_thread+0x1c8/0x308)
<4>[ 23.496608] [<c00f10a0>] (worker_thread+0x1c8/0x308) from [<c00f6b0c>] (kthread+0x84/0x8c)
<4>[ 23.496646] [<c00f6b0c>] (kthread+0x84/0x8c) from [<c0040e9c>] (kernel_thread_exit+0x0/0x8)
<4>[ 23.496673] ---[ end trace a139245ee3e508ee ]---
It might be the reason why WiFi doesn't work.

kkarpowi said:
Thanks, I know it. I've rewritten the script so it could be executed from Linux.
Click to expand...
Click to collapse
BTW - Running l5_wifi_fix results are:
modprobe: 'librasdioif.ko': invalid module format
modprobe: 'wlan.ko': invalid module format

WiFi working
WiFi is working after a total wipe and CM10-20130414 installed.
I don't know what was wrong or if anything was fixed. Really don't know.
PinkFlozd kernel and gapps also installed and still OK.
I hope that everything else is working fine - checking...

I recommend to update your stock firmware to V20A_Rooted.kdz. Its very smooth and runs my Temple run 2 whith no lags on 800mhz.
Link for the kdz update:
http://forum.xda-developers.com/showthread.php?t=2230679
Link for the 4.1.2 Clean rom v2:
http://forum.xda-developers.com/showthread.php?t=2232123

jannick63 said:
I recommend to update your stock firmware to V20A_Rooted.kdz. Its very smooth and runs my Temple run 2 whith no lags on 800mhz.
Link for the kdz update:
http://forum.xda-developers.com/showthread.php?t=2230679
Link for the 4.1.2 Clean rom v2:
http://forum.xda-developers.com/showthread.php?t=2232123
Click to expand...
Click to collapse
That's what I did yesterday. And AFTER that (and of course after reinstalling the latest CM10 from scratch) WiFi started working. Strange, isn't it?

my sim card is not working
Andro995 said:
I have a problem with the 3G Data Connection. The WiFi is working fine, sorry I can't help about it. I just didn't know where to ask my question. How can i fix data connectivity? before flashing CM10, on original ICS it was working just fine. I also tried flashing only the ROM without the pinkflozd kernel, still no connectivity. In settings its set on "allowed" or whatever it says. Please help. :/
Click to expand...
Click to collapse
my sim card is not working

you should try flashing baseband,specify which base band you are in now
Sent from my LG-P700 using xda app-developers app

OP, if you want to help pm pinkflozd. And I think you need to post at least 10 times to be able to post on development forum.
So just keep posting on this thread
on my p705g - vanir rom

[Q] i9505 No Wifi, what should be in /persist ?

Hi Folks,
Another "no wifi" s4 here. This is a work colleagues phone that was totally stock. After upgrading to 4.4.2, wifi won't turn on. I've tried pretty much everything I've found on this site with regards to fixing it. The last thing that I hadn't looked at was the /persist folder (MMCBLK0P17). The one on this phone is empty and from what I've read, it should be populated. Could someone with a rooted i9505 post a list of the contents or better still, upload a copy of their /persist folder please?
TIA!
Mark

mjh74 said:
Hi Folks,
Another "no wifi" s4 here. This is a work colleagues phone that was totally stock. After upgrading to 4.4.2, wifi won't turn on. I've tried pretty much everything I've found on this site with regards to fixing it. The last thing that I hadn't looked at was the /persist folder (MMCBLK0P17). The one on this phone is empty and from what I've read, it should be populated. Could someone with a rooted i9505 post a list of the contents or better still, upload a copy of their /persist folder please?
TIA!
Mark
Click to expand...
Click to collapse
So what is everything found on this site with regards to fix it?
/persist folder is also empty on my phone.

mjh74 said:
Hi Folks,
Another "no wifi" s4 here. This is a work colleagues phone that was totally stock. After upgrading to 4.4.2, wifi won't turn on. I've tried pretty much everything I've found on this site with regards to fixing it. The last thing that I hadn't looked at was the /persist folder (MMCBLK0P17). The one on this phone is empty and from what I've read, it should be populated. Could someone with a rooted i9505 post a list of the contents or better still, upload a copy of their /persist folder please?
TIA!
Mark
Click to expand...
Click to collapse
Dial *#1234# and paste here what appears.

AP: I9505XXUGNG8
CP: I9505XXUGNG8
CSC: I9505BTUGNG2
So far I've tried the following:
Flashing the wifi-fix
Re-partitioning before flashing a stock rom
Rooting, Phillz recovery, clear dalvik, factory reset and format for new rom option before flashing various different 4.4.2 UK stock roms.
Editing build.prop and changing "ro.securestorage.support=true" to false.
Removing the back, removing and replacing the antenna wire.
Flashing a CM11 nightly.
Deleting wpa_supplicant.conf
Dmesg shows some interesting stuff.
"<4>[ 1277.591125] ## wifi_remove
<4>[ 1277.591125] wifi_set_power = 0
<4>[ 1277.591156] ####btlock released, cookie: WiFi
<6>[ 1277.591156] ------------------------------------------------
<6>[ 1277.591156] ------------------------------------------------
<6>[ 1277.591156] brcm_wlan_power Enter: power off
<6>[ 1277.591186] barcode_emul_ice4: ice_gpiox_set : num = 3 , val = 0
<7>[ 1277.592590] usb 1-1: usb wakeup-resume
<7>[ 1277.592651] usb 1-1: finish resume
<7>[ 1277.599456] hub 1-0:1.0: resume on port 1, status 0
<7>[ 1277.599487] hub 1-0:1.0: port 1, status 0503, change 0004, 480 Mb/s
<6>[ 1277.727569] [email protected] 42
<6>[ 1277.732635] set_freq_limit: 0x1 -1, min 384000, max 1350000
<4>[ 1277.822662] wifi_set_carddetect = 0
<4>[ 1277.822692] brcm_wifi_status:298 status 0
<6>[ 1277.822692] mmc1: Slot status change detected (1 -> 0)
<4>[ 1277.823638]
<4>[ 1277.823638] failed to power up wifi chip, max retry reached, exits **"
As I'm typing this, the phone has a stock rom and isn't rooted. I've just rooted again with CF-ROOT and Odin, rebooted the phone and wifi enabled instantly, something I've not seen before! It was the first boot and SuperSU wanted to update and reboot. After the reboot, wifi will no longer come on again.

I See you have the same error as I'm having:
Code:
<6>[ 1277.822692] mmc1: Slot status change detected (1 -> 0)
Can you check dmesg for mmc1 CRC errors and post output here?

ajax505 said:
I See you have the same error as I'm having:
Code:
<6>[ 1277.822692] mmc1: Slot status change detected (1 -> 0)
Can you check dmesg for mmc1 CRC errors and post output here?
Click to expand...
Click to collapse
Here you go.

mjh74 said:
Here you go.
Click to expand...
Click to collapse
So after pretty much giving up and weeks of flashing and faffing around. I managed to get wifi enabled. I've no idea how but I went from stock rom XXUGNG2, rooted with CF-AUTO-ROOT, Phillz recovery installed and a Cyanogen nightly and no wifi. Flashed XXUGNG2 back to the phone and wifi sprung into life! I then flashed XXUGNG8 and wifi still worked! I then performed a factory reset from Backup & Reset and wifi hasn't worked again since!?!?
So I'm not so convinced now that it's a hardware issue as I first thought.....

Lucky you I tried every possible solution. The interesting thing is that if I flash stock I can see Wifi mac, toggle button is "alive" but wifi won't turn on. If I flash cyanogen, wifi mac is not available and the wifi button is gray saying "turning wifi on" like forever.

ajax505 said:
Lucky you I tried every possible solution. The interesting thing is that if I flash stock I can see Wifi mac, toggle button is "alive" but wifi won't turn on. If I flash cyanogen, wifi mac is not available and the wifi button is gray saying "turning wifi on" like forever.
Click to expand...
Click to collapse
Like you, I'm back at exactly the same place. Cyanogen won't even let me turn wifi on now, the button is grayed out and says "turning wifi on". Stock roms show a pale green wifi signal icon until it turns gray again and fails. Arghhh how did I get it working briefly?!

mjh74 said:
So after pretty much giving up and weeks of flashing and faffing around. I managed to get wifi enabled. I've no idea how but I went from stock rom XXUGNG2, rooted with CF-AUTO-ROOT, Phillz recovery installed and a Cyanogen nightly and no wifi. Flashed XXUGNG2 back to the phone and wifi sprung into life! I then flashed XXUGNG8 and wifi still worked! I then performed a factory reset from Backup & Reset and wifi hasn't worked again since!?!?
So I'm not so convinced now that it's a hardware issue as I first thought.....
Click to expand...
Click to collapse
mjh74 said:
Like you, I'm back at exactly the same place. Cyanogen won't even let me turn wifi on now, the button is grayed out and says "turning wifi on". Stock roms show a pale green wifi signal icon until it turns gray again and fails. Arghhh how did I get it working briefly?!
Click to expand...
Click to collapse
When people learn that means "nightly" with CM?