Database Info

[GPL][Kernel] 2.6.35 for HERC [AP #4/5]

Github:
I now consider this Release Candidate quality. Please do report issues (with logcats and dmesgs). Check the known bugs, etc, etc.
https://github.com/s0be/cm-kernel
the -amonra zip is for recoveries that don't take the FS type as the first argument of mount(...) If the regular zip fails complaining about missing files, try the -amonra version.
Latest official version:
no debug
http://heroc.s0be.com/HERC-2.6.35-AP-5.zip
http://heroc.s0be.com/HERC-2.6.35-AP-5-amonra.zip
Headset detection less broken. Now it always thinks there's a mic connected to anything plugged in.
http://heroc.s0be.com/HERC-2.6.35-AP-4.zip
http://heroc.s0be.com/HERC-2.6.35-AP-4-amonra.zip
If that download doesn't work for you, your OS likely has a broken ipv6 stack. Please check that you have ipv6 disabled if you don't actually have an ipv6 connection.
What works:
Ram console
Keypad
Screen
Touchscreen
GPS
Compass
G-Sensor
nand
Early Suspend
Bluetooth
Headset Detection
Camera
What Doesn't work or hasn't been tested:
Thanks to:
Elemag for the initial Hero 2.6.35 port, with Erasmux as a major contributor, Decadence for the 2.6.34/35 heroc board files, and riemervdzee for his pointers at fixes needed to get it working and his continued drive to get this kernel full featured and stable, and everyone they pulled from (Darch, Toast, Cyanogen, etc, etc). If I've forgotten anyone, please let me know the names to add.

See first post for current. This is just historic releases.
Headset detection fixed. Mic detection not working yet.
Weird audio program related crashes fixed
http://heroc.s0be.com/HERC-2.6.35-AP-3.zip
http://heroc.s0be.com/HERC-2.6.35-AP-3-amonra.zip
Rebased on Pershoot's G1 2.6.35.11 Kernel Tree
New base .config
BFS Disabled
Headset detection re-broken. Will be reviewing this currently.
http://heroc.s0be.com/HERC-2.6.35-AP-2.zip
http://heroc.s0be.com/HERC-2.6.35-AP-2-amonra.zip
Camera fix from JayBob via decad3nce
http://heroc.s0be.com/HERC-2.6.35-AP-1.zip
http://heroc.s0be.com/HERC-2.6.35-AP-1-amonra.zip
Pulls some changes from Decad3nce for the camera (still doesn't work) and some i2c speedups from riemervdzee
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-114.zip
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-114-amonra.zip
Fixes most of what I broke in 106
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-109.zip
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-109-amonra.zip
Disabled some ****
Changed some ****
This is an attempt to fix the power issues through voodoo
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-106.zip
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-106-amonra.zip
Fixed headset detection. Haven't figured out if the button works.
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-101.zip
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-101-amonra.zip
Went back to #55(never released) config
Disabled Debug
All updates from #56 still apply
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-57.zip
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-57-amonra.zip
Merged with upstream
Updated msm-camera
Updated msm-i2c
Ripped out a bunch of stuff, disabled debugging
This probably isn't going to be completely happy
This is definitely not happy...
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-56.zip
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-56-amonra.zip
Restored device mapper with crypt support. This may fix missing app issues
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-47.zip
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-47-amonra.zip
tun.ko Enabled - NOT TESTED AT ALL, PLEASE REPORT IF I GOT IT RIGHT
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-45.zip
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-45-amonra.zip
Enabled > 6912000 CPU speeds. Boots capped at 691 though
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-44.zip
Fix ramzswap/compcache
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-42-2.zip
h2w still broken
Camera almost works
Bluetooth is fixed
Touchscreen may not be problematic now.
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-42.zip
Merged MDP changes from upstream
Fixed h2w (I think) someone with a headset, try plugging it
Camera almost works on occasion. Can catch a preview frame now and then.
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-30.zip
Re-enabled netfilter modules
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-23.zip
changed the early_suspend.level value of the synaptics_i2c_rmi driver to match 2.6.29.
Last attempt til next week
still capped at 691200
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-18.zip
Clamped to 691200 max freq
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-17.zip
Maybe solved TS issues??? Testing now.
Fixed USB Mass Storage
Enabled PerfLock
CURRENT MAX IS AT 768000, throwing together a #14 with a 691200 cap.
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-13.zip
First alpha
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-5.zip

what kind of performance increase will this bring? and will it be nice to have when we get a fully working GB rom?

Unfortunally the current .35 build for the Hero GSM version is slower than any .29 kernel.
But yeah, seems we have to reimplement a lot of optimalisations.
It is nice that we actually get something out of the HeroC though

riemervdzee said:
Unfortunally the current .35 build for the Hero GSM version is slower than any .29 kernel.
But yeah, seems we have to reimplement a lot of optimalisations.
It is nice that we actually get something out of the HeroC though
Click to expand...
Click to collapse
There are other advantages of course, we have to remember. Performance is king, but features are definitely queen. Getting to a recent kernel (2.6.29 is coming up on 2 years old), makes future updates to Heroc a lot easier. Going to up-to-date drivers may allow us to eliminate some of the binary cruft from the Heroc tree, etc, etc.

Two things I've tried:
1. In the xda "hero" dev forum, there was a post that there was a problem with the newer (>.34) yaffs2 code, and you needed to boot and wipe using a 1.7 RA recovery. So, I copied the yaffs2 code from deca's .29 kernel. It then oopsed at 1017 in msm_fb, which was the ifdef'd line for HERO.
2. So, I added "&& !defined(CONFIG_MACH_HEROC)" to line 1016. It then still rebooted, but last_kmsg was different after "vsync on gpio 97 now 0":
[ 3.626831] vsync on gpio 97 now 0
[ 3.632263] msmfb_probe() installing 320 x 480 panel
[ 3.640106] Registered led device: lcd-backlight
[ 3.650085] msm_serial: driver initialized
[ 3.654052] msm_serial_hs module loaded
[ 3.697570] loop: module loaded
[ 3.698760] pmem: 1 init
[ 3.702514] pmem_adsp: 0 init
[ 3.706420] pmem_camera: 0 init
[ 3.711578] Android kernel panic handler initialized (bind=kpanic)
[ 3.712524] AKM8973 compass driver: init
[ 3.718566] input: compass as /devices/virtual/input/input0
[ 3.731079] msm_nand: allocated dma buffer at ffa0a000, dma_addr 256fb000
[ 3.732696] msm_nand: read CFG0 = aa5400c0 CFG1 = 8744a
[ 3.733245] msm_nand: CFG0 cw/page=3 ud_sz=512 ecc_sz=10 spare_sz=4
[ 3.734069] msm_nand: NAND_READ_ID = 5501bcec
[ 3.735229] msn_nand: nandid 5501bcec status c03120
[ 3.735595] msm_nand: manuf Samsung (0xec) device 0xbc blocksz 20000 pagesz 800 size 20000000
[ 3.736114] msm_nand: save CFG0 = e85408c0 CFG1 = 4745e
[ 3.736419] msm_nand: CFG0: cw/page=3 ud_sz=516 ecc_sz=10 spare_sz=0 num_addr_cycles=5
[ 3.737121] msm_nand: DEV_CMD1: f00f3000
[ 3.737609] msm_nand: NAND_EBI2_ECC_BUF_CFG: 1ff
[ 3.738372] 6 cmdlinepart partitions found on MTD device msm_nand
[ 3.738708] Creating 6 MTD partitions on "msm_nand":
[ 3.739257] 0x00001ff60000-0x000020000000 : "misc"
[ 3.753509] 0x000002c60000-0x000003160000 : "recovery"
[ 3.776397] 0x000003160000-0x0000033e0000 : "boot"
[ 3.794219] 0x0000033e0000-0x000009be0000 : "system"
[ 4.070312] 0x000009be0000-0x000009fe0000 : "cache"
[ 4.098876] 0x000009fe0000-0x000020000000 : "userdata"
No errors detected
Don't know if this helps or not. BTW, I'm using Firerats's custom MTD partitions, so I modified the boot parameters.

dbayub said:
Two things I've tried:
1. In the xda "hero" dev forum, there was a post that there was a problem with the newer (>.34) yaffs2 code, and you needed to boot and wipe using a 1.7 RA recovery. So, I copied the yaffs2 code from deca's .29 kernel. It then oopsed at 1017 in msm_fb, which was the ifdef'd line for HERO.
2. So, I added "&& !defined(CONFIG_MACH_HEROC)" to line 1016. It then still rebooted, but last_kmsg was different after "vsync on gpio 97 now 0":
<SNIP>
Don't know if this helps or not. BTW, I'm using Firerats's custom MTD partitions, so I modified the boot parameters.
Click to expand...
Click to collapse
yeah, I had that fixed in my tree, forgot to commit the || -> && change I didn't do that yaffs2 change, but I just tested it with identical results.

Sweet. I'll spend more time on it this weekend. Swamped with homework atm.
Hopefully we'll have something super stable!

Decad3nce said:
Sweet. I'll spend more time on it this weekend. Swamped with homework atm.
Hopefully we'll have something super stable!
Click to expand...
Click to collapse
Made some more progress:
http://android.pastebin.com/AWysQDNk

s0be, i think you're going to blow up the hero scene again. with deca and you working together there's been a lot of progress recently and i want to thank both of you. i really love my hero and you guys keep it feeling young.

AND HOW!!!!!
Sent from my HERO200 using XDA App

jmkarnai01 said:
AND HOW!!!!!
Sent from my HERO200 using XDA App
Click to expand...
Click to collapse
More commits
More Progress
http://android.pastebin.com/rqm0Vn1p

You guys are pure AWESOME!

S0be, i was wondering your opinion, once this kernel is completed and we get GB running smoothly, will the supposed 2.4 GB update break everything that is already working or just maybe the new stuff will have to be worked in properly?

Pocker09 said:
S0be, i was wondering your opinion, once this kernel is completed and we get GB running smoothly, will the supposed 2.4 GB update break everything that is already working or just maybe the new stuff will have to be worked in properly?
Click to expand...
Click to collapse
no clue
http://android.pastebin.com/SSRM5MKB

Dang sobe making progress good work man. Thanks!!!!!!!!!!!"!
Sent from my HTC Hero CDMA using XDA App

oostah said:
Dang sobe making progress good work man. Thanks!!!!!!!!!!!"!
Sent from my HTC Hero CDMA using XDA App
Click to expand...
Click to collapse
http://android.pastebin.com/qKr6wEtY
Some more progress, looks like just the smd and i2c errors are left to fix

Looking forward to this. And wow you work like super man lol but thank for the time and hard work.
Root-Hack-Mod-Always™

Just curious, will you guys be running AOSP's GB or will this kernel allow for a less tweaked version of GB? Thanks! Great Job!

The smd stuff is because it used to call both v1 and v2 alloc, and as long as one succeeded, it was OK. Now it's ifdef'd to use different code depending on if CONFIG_MSM_SMD_PKG3 is set or not. Looks like the package 4 code is what works on heroc. With that change, the smd code works.
[ 3.684967] smd_alloc_channel() cid=01 size=08192 'SMD_DIAG'
[ 3.686340] smd_alloc_channel() cid=02 size=08192 'SMD_RPCCALL'
etc. Then it's the i2c failures:
[ 3.841674] msm_i2c msm_i2c.0: Error during data xfer 1e (-5)
[ 3.852203] msm_i2c msm_i2c.0: error, status 63c8
and oops:
[ 4.861785] Internal error: Oops: 80000005 [#1] PREEMPT
[ 4.863433] last sysfs file:
[ 4.864318] Modules linked in:
[ 4.866058] CPU: 0 Not tainted (2.6.35.10-cyanogenmod #11)
[ 4.867706] PC is at 0x0
[ 4.868682] LR is at microp_i2c_probe+0xb70/0x1438
[ 4.869598] pc : [<00000000>] lr : [<c0217e64>] psr: 60000013
[ 4.869659] sp : cc219e10 ip : cc219d10 fp : cc219e74
[ 4.872100] r10: c040eef4 r9 : 00000000 r8 : 00000005
[ 4.873748] r7 : cc255da0 r6 : c040ea10 r5 : cc255d80 r4 : cc48a760
[ 4.874694] r3 : c040ea2c r2 : 00000002 r1 : cc219ce0 r0 : cc219e3c
[ 4.876342] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel

[ROOT][SECURITY] Root exploit on Exynos

EDIT: For general discussion about this topic, please post in the following location (and not here): http://forum.xda-developers.com/showthread.php?t=2057818
Now find a one-click root application at http://forum.xda-developers.com/showthread.php?t=2130276. More exploits coming.
Hi,
Recently discover a way to obtain root on S3 without ODIN flashing.
The security hole is in kernel, exactly with the device /dev/exynos-mem.
This device is R/W by all users and give access to all physical memory ... what's wrong with Samsung ?
Its like /dev/mem but for all.
Three libraries seems to use /dev/exynos-mem:
/system/lib/hw/camera.smdk4x12.so
/system/lib/hw/gralloc.smdk4x12.so
/system/lib/libhdmi.so
Many devices are concerned :
Samsung Galaxy S2
Samsung Galxy Note 2
MEIZU MX
potentialy all devices who embed exynos processor (4210 and 4412) which use Samsung kernel sources.
The good news is we can easily obtain root on these devices and the bad is there is no control over it.
Ram dump, kernel code injection and others could be possible via app installation from Play Store. It certainly exists many ways
to do that but Samsung give an easy way to exploit. This security hole is dangerous and expose phone to malicious apps.
Exploitation with native C and JNI could be easily feasible.
Edited
Some details :
/dev/exynos-mem seems to be used for graphic usage like camera, graphic memory allocation, hdmi.
By activating pid display in kmsg, surfaceflinger do mmap on the device (via one of the three shared libraries above ?? I have not see reference in binary to these libraires)
The operations allowed on the device are (from linux/drivers/char/mem.c) :
Code:
static const struct file_operations exynos_mem_fops = {
.open = exynos_mem_open,
.release = exynos_mem_release,
.unlocked_ioctl = exynos_mem_ioctl,
.mmap = exynos_mem_mmap,
}
and the default permissions (from linux/drivers/char/mem.c) :
Code:
#ifdef CONFIG_EXYNOS_MEM
[14] = {"exynos-mem", S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH
| S_IWOTH, &exynos_mem_fops},
#endif
ioctl request on /dev/exynos-mem permit to clean / flush L1 and L2 cache, set non cacheable page memory and set physical memory address for use with mmap.
Now the interesting part : mmap operation.
The only limit is to restrict access to lowmem (from linux/drivers/char/exynos-mem.c) :
Code:
/* TODO: currently lowmem is only avaiable */
if ((phys_to_virt(start) < (void *)PAGE_OFFSET) ||
(phys_to_virt(start) >= high_memory)) {
pr_err("[%s] invalid paddr(0x%08x)\n", __func__, start);
return -EINVAL;
}
The comment in above code could be frightening.
And an eye in Documentation/arm/memory.txt say :
Code:
Start End Use
--------------------------------------------------------------------------
PAGE_OFFSET high_memory-1 Kernel direct-mapped RAM region.
This maps the platforms RAM, and typically
maps all platform RAM in a 1:1 relationship.
In other words, this device only permit to own the physical memory including kernel code.
The question is why permissions are set to read/write for all in kernel AND in ueventd.smdk4x12.rc:
samsung developper in charge of this would lose his job
some samsung apps with basic rights need to access it (I doubt it)
a huge mistake
A simple patch could be to set permissions to 0660 or 0600 in ueventd.smdk4x12.rc, but I don't know how it would affect samsung applications/services.
In attachment, binary and source to obtain for root shell.

Removing either read or write permissions will kill the camera. I didn't see any other deterioration in anything else.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
My guess the best fix would be to limit the access to the DMA memory spaces which this thing actually needs, the definition of the different CMA areas are in /arch/arm/mach-exynos/mach-midas.c for the S3 and N2.
Front camera for example:
Code:
#ifndef CONFIG_USE_FIMC_CMA
{
.name = "fimc1",
.size = CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC1 * SZ_1K,
#if defined(CONFIG_MACH_GC1)
.start = 0x5ec00000,
#else
.start = 0x65c00000,
#endif
},
#endif
Generally all memory areas allocated through s5p_cma_region_reserve in /arch/arm/plat-s5p/reserve_mem.c would be treated as exceptions and everything else needs to be blocked.
Update: Low-level kernel fix for developers posted here.
A kernel based fix as I posted above is the only method to fix the security hole while also not breaking the camera. In all other cases if you are not able or willing to flash a kernel, use Chainfire's application.

Very interesting. Thanks for bringing that up. (Have also flagged some Samsung engineers to read this)
Also, I'm building an APK for this to make it easy.
EDIT: APK posted here: http://forum.xda-developers.com/showthread.php?t=2050297, download, install, run, and your device is rooted with SuperSU.
EDIT#2: This app now also lets you disable the exploit

@alephzain thanks for sharing the source code of the exploit: short, elegant, efficient, to me that's art
Your short documentation and clean writing style even made easier to learn from it.

Hey curio,
No need, here is a very quickly put together app in 5 mins that lets you toggle on/off world writability to /dev/exynos-mem
So you can toggle the fix off if you want to use the camera, then toggle it back on afterwards.
Github source: https://github.com/Ryan-ZA/exynosfix
APK Download: https://github.com/Ryan-ZA/exynosfix/raw/master/exynosfix.apk
Ryan
MOD EDIT: Removed attached download, as it is out of date compared to the linked download

jcase said:
Please explain how this is a remote exploit? This looks entirely local to me. Vulns happen, every vendor gets hit with them. Google does, Apple does Motorola does, HTC does, LG does, Samsung does, ASUS does, Nvidia, Qualcomm etc etc, it is all part of the game. Hell go look at the recent qualcomm disclosures, almost every qualcomm since 2009, wide open! Sh*t happens. Any device with root on it, be it exploit or whatever is open to permanent damage from malicious, want to nuke an htc with root? dd if=/dev/zero of=/dev/block/mmcblk0p4. Pantech/LG/Mostqualcoms hit all the bootloaders. Hell system user is enough on LG phones, and most other brands to brick them.
I'm not sure about rewards, but I have reported vulns and bugs to every major vendor, and the only three who ever respond to me are Google, Samsung and Motorola. All three respond promptly and polite, and occasionally follow up if requested. Vendor not getting back to you? [email protected] is quite good at getting them to respond, just tell them the vendor is not responding. More than once they have gotten a dialog with a vendor opened with me.
Understanding update timelines is another issue, vendor updates generally have to go through development, QA at the vendor (sent back if major issues found), then in the case of Sprint and other carriers, sent to carrier QA (returned to OEM if major issues found) . Major changes to the radio? Yep off to the FCC as well! Updates can take considerable time. Not excusing the "superbrick" bug, just pointing out a few weeks (or in the case of sprint or Vernon a few months) can be expected. Want faster updates? Buy an international device, and get a GSM carrier.
Click to expand...
Click to collapse
OK, we're getting into technicalities here, but I consider anything that can be exploited by a Market app without explicit user intervention beyond installing an app (reboot cycles, ADB, etc.) to be "remote". Adam covered how easy it is to bypass Bouncer at BABBQ, so relying on that is a bad idea.
Prior to this, all exploits (restoreRoot, mempodroid, etc) for ICS on Exynos4 devices required ADB to be involved. This doesn't.
And no, you can't cause permanent damage to an HTC with root. The example you provided isn't permanent damage, it can be repaired via JTAG at a service center. Superbrick is *permanent unrecoverable damage that requires a motherboard replacement - JTAG cannot bring a device that has been damaged back to operation*. That's a difference between 0 material costs and maybe 30 minutes of labor to repair at a service center and $200-300+ in material costs and significantly more labor.
And your "updates take considerable time" is bull****. Sprint FI27 was built on September 27 (check the kernel build date), 3 weeks after Samsung had the final version of their protection patch, and was deployed on Kies a matter of *days* later. They had an update scheduled, a patch ready to go for three weeks before the update was built, and they shipped without the patch. There's no excuse for that. At that time, it was an "open source problem" because it only affected custom firmwares, and any root exploits known required ADB. Their approach was dependent on an assumption that *an exploit like this would never happen* - which is a horrible assumption.
This exploit changes things - there is no a root exploit that can be used by an app straight from the market, in the background, with little to no user intervention.
As to the negative effects of 600 permissions on operation (such as killing camera) - as an interim, setting things to 660 instead of 666 makes things somewhat better protected but not as protected as they should be. I will run some tests later today to confirm that at least any old APK can't get privilege elevation if things are set so only the graphics group can diddle with the memory regions.

RyanZA said:
Hey curio,
No need, here is a very quickly put together app in 5 mins that lets you toggle on/off world writability to /dev/exynos-mem
So you can toggle the fix off if you want to use the camera, then toggle it back on afterwards. Will update this post shortly with github source.
Ryan
Click to expand...
Click to collapse
Yes what I also started writing allows to restore permissions on /dev/exynos-mem in case you need to use camera, I agree its useful!

fards said:
Camera is insisting on 666 on some builds.
Curious how some devices using same base code are using camera with diff permissions.
Neither my N7000 or N 8010 will play nicely with 600 or 660..
Click to expand...
Click to collapse
The assumption of similar base code isn't a good one... You'd be shocked how many deltas there are between I9100/I777/N7000 stock firmware codebases that shouldn't be there given how similar the devices are.
In the region of the system we're dealing with here (graphics memory allocation), there are significant differences in operation between Exynos 4210 and 4412. There are also significant deltas between the implementations in all of Samsung Mobile's devices and the official public reference source, and frequently deltas between Samsung's implementations for various handsets/tablets that shouldn't be there as you've discovered.
For example, the official reference source does allocations from FIMC1 memory regions in gralloc to support various graphics items. Nearly all of Mobile's implementations allocate ION memory instead of FIMC1 memory even when FIMC1 memory is requested (and yes, this change affects camera operation more than anything else.)
Thanks for the headsup on N80xx, I'll def. have to do a rebuild on N8013. It's pretty frequent for us to have brokenness that doesn't exist on I9300 and vice versa.

Hmm, odd... even when chmodded 660 system.graphics, the exploit appears to succeed on CM10.1 from within an ADB shell...
I need to look more closely at this.
Seems like the shell user is a member of the graphics group...
I think AndreiLux's approach he's working on may be the best.
Has anyone tested to see what the effect of 0600 is on hwaccel video playback? (Seems to be none on CM10.1).
Looks like it's anything that wants FIMC memory that needs exynos-mem, I'll double check ION, that should have failed...
Edit: Yeah, gralloc only accesses exynos-mem when attempting to access FIMC1 memory. I think camera is the main other place where FIMC is used. Actually, in any shipped handset, gralloc should never actually access exynos-mem - gralloc will give ION memory when you ask it for FIMC1 memory, and ION memory allocation doesn't use exynos-mem (hmm, unless libsecion does... I need to check that...)

Entropy512 said:
Hmm, odd... even when chmodded 660 system.graphics, the exploit appears to succeed on CM10.1 from within an ADB shell...
I need to look more closely at this.
Seems like the shell user is a member of the graphics group...
I think AndreiLux's approach he's working on may be the best.
Click to expand...
Click to collapse
Because your shell is in graphics group.

supercurio said:
Because your shell is in graphics group.
Click to expand...
Click to collapse
I was beginning to suspect that, thanks for confirming.
dennis.l said:
if this is a Samsung kernel issue would any of the custom kernel have the same flaws? otherwise would I be able to workaround the problem by installing a CM10 ROM instead of stock?
Click to expand...
Click to collapse
Right now older custom kernels will. CM's codebase was just patched earlier today to restrict that node to system.graphics 0660
It was done in the 10.1 branch, so it won't immediately affect all devices. We're working on transitioning all exynos4 devices over to 10.1 this week - it's about halfway done.

@alephzain, when running the exploit in an adb shell, sometimes the privilege escalation fails with:
Code:
[*] s_show->seq_printf format string found at: 0xC07A70A8
[*] sys_setresuid found at 0xC00945A0
[*] patching sys_setresuid at 0xC00945E4
[!] set user root failed: Operation not permitted
And it typically succeed after 1 or 2 more attempts.
Does it ring a bell?

ExynosAbuse APK updated to v1.10
I've just updated the ExynosAbuse APK to v1.10 !
This version allows you to disable the exploit (which may break camera), re-enable the exploit (if you need the camera) and to disable the exploit at boot (before any Android app runs). These options do require root (SuperSU or Superuser) to be installed as well. This is for people who actually *want* root. If you don't want root, you should use Supercurio's solution as it doesn't depend on being rooted it for dis/reenabling the exploit.
http://forum.xda-developers.com/showthread.php?t=2050297

Voodoo Instant fix for Exynos Mem Abuse vulnerability released.
I'm glad I have a blog, because things tend to disappear here ^^
Edit: Please use the following thread to discuss this specific solution: http://forum.xda-developers.com/showthread.php?t=2051290

RyanZA said:
Hey curio,
No need, here is a very quickly put together app in 5 mins that lets you toggle on/off world writability to /dev/exynos-mem
So you can toggle the fix off if you want to use the camera, then toggle it back on afterwards.
Github source: https://github.com/Ryan-ZA/exynosfix
APK Download: https://github.com/Ryan-ZA/exynosfix/raw/master/exynosfix.apk
Ryan
Click to expand...
Click to collapse
As per requests, I added in 'fix vulnerability on boot' functionality for those who like an open source fix.
Nice work on that app, curio.

Sooooo....
Here's a low-level fix for the kernel.
Source @ https://github.com/AndreiLux/Perseus-S3/commit/fb36195dab87e002721c7d1a8294a400c6b40a71
Edit: Follow-up commit for Note 2 (Possibly N8000 too) users @ https://github.com/AndreiLux/Perseus-S3/commit/81c95f6046880be48ef377ebae4e42c791f0813e
I did what I said in the first post. The mmap function checks the given memory addresses against all of the current CMA memory spaces on the device and denies access if the space it out of bound of any of the defined blocks. Furthermore on my S3 I, for now, couldn't find anything breaking beyond the main camera. So I added an additional condition that checks that the accessed memory block is "s3c-fimc" (The camera DMA block) and ignores the other blocks. The whole thing is totally neutered if CONFIG_CMA_DMA isn't used in the device configuration (Note 2 / Exynos 4412 devices with 2GB RAM). Edit: Fix works now the same for all devices.
Defined memory spaces:
Code:
[ 0.000000] c0 cma: CMA: reserved 16 MiB at 65800000
[ 0.000000] c0 [cma_region_descriptor_add] adding [s3c-fimc] (0x65800000)-(0x00f00000)
[ 0.000000] c0 cma: CMA: reserved 40 MiB at 5c800000
[ 0.000000] c0 [cma_region_descriptor_add] adding [s3c-mfc] (0x5c800000)-(0x02800000)
....
....
[ 0.000000] c0 S5P/CMA: Reserved 0x70000000/0x00a00000 for 'fimc_is'
[ 0.000000] c0 [cma_region_descriptor_add] adding [fimc_is] (0x70000000)-(0x00a00000)
[ 0.000000] c0 S5P/CMA: Reserved 0x71700000/0x00800000 for 'fimd'
[ 0.000000] c0 [cma_region_descriptor_add] adding [fimd] (0x71700000)-(0x00800000)
[ 0.000000] c0 S5P/CMA: Reserved 0x6c300000/0x03d00000 for 'fimc0'
[ 0.000000] c0 [cma_region_descriptor_add] adding [fimc0] (0x6c300000)-(0x03d00000)
[ 0.000000] c0 S5P/CMA: Reserved 0x71600000/0x00100000 for 'srp'
[ 0.000000] c0 [cma_region_descriptor_add] adding [srp] (0x71600000)-(0x00100000)
[ 0.000000] c0 [cma_region_descriptor_add] adding [mfc-normal] (0x64000000)-(0x00400000)
[ 0.000000] c0 S5P/CMA: Reserved 0x64000000/0x00400000 for 'mfc-normal'
[ 0.000000] c0 [cma_region_descriptor_add] adding [mfc-normal] (0x64000000)-(0x00400000)
[ 0.000000] c0 S5P/CMA: Reserving 0x6800000 for secure region aligned by 0x4000000.
[ 0.000000] c0 S5P/CMA: Reserved 0x5c000000/0x06800000 for 'secure_region'
[ 0.000000] c0 S5P/CMA: Reserved 0x5c000000/0x00800000 for 'sectbl'
[ 0.000000] c0 [cma_region_descriptor_add] adding [sectbl] (0x5c000000)-(0x00800000)
[ 0.000000] c0 S5P/CMA: Reserved 0x5c100000/0x03100000 for 'mfc-secure'
[ 0.000000] c0 [cma_region_descriptor_add] adding [mfc-secure] (0x5c100000)-(0x03100000)
[ 0.000000] c0 S5P/CMA: Reserved 0x5f200000/0x02f00000 for 'ion'
[ 0.000000] c0 [cma_region_descriptor_add] adding [ion] (0x5f200000)-(0x02f00000)
Running the exploit:
Code:
[email protected]:/ $ export PATH=/data/local/bin:$PATH
[email protected]:/ $ ./exynos-abuse
[!] Error mmap: Invalid argument|00000004
Behind the scenes during that:
Code:
[ 119.290791] c1 [exynos_mem_open:50] private_data(0xd0340b80)
[ 119.290889] c1 [exynos_mem_mmap] requesting access to (0x40000000)-(0x41000000)
[ 119.290960] c1 [exynos_mem_mmap] Checking space paddr(0x65800000)-(0x66700000) from 's3c-fimc'
[ 119.291046] c1 [exynos_mem_mmap] Checking space paddr(0x5c800000)-(0x5f000000) from 's3c-mfc'
[ 119.291299] c1 [exynos_mem_mmap] Checking space paddr(0x70000000)-(0x70a00000) from 'fimc_is'
[ 119.291386] c1 [exynos_mem_mmap] Checking space paddr(0x71700000)-(0x71f00000) from 'fimd'
[ 119.291465] c1 [exynos_mem_mmap] Checking space paddr(0x6c300000)-(0x70000000) from 'fimc0'
[ 119.291545] c1 [exynos_mem_mmap] Checking space paddr(0x71600000)-(0x71700000) from 'srp'
[ 119.291631] c1 [exynos_mem_mmap] Checking space paddr(0x64000000)-(0x64400000) from 'mfc-normal'
[ 119.291711] c1 [exynos_mem_mmap] Checking space paddr(0x64000000)-(0x64400000) from 'mfc-normal'
[ 119.291801] c1 [exynos_mem_mmap] Checking space paddr(0x5c000000)-(0x5c800000) from 'sectbl'
[ 119.291888] c1 [exynos_mem_mmap] Checking space paddr(0x5c100000)-(0x5f200000) from 'mfc-secure'
[ 119.291967] c1 [exynos_mem_mmap] Checking space paddr(0x5f200000)-(0x62100000) from 'ion'
[ 119.292034] c1 [exynos_mem_mmap] invalid paddr(0x40000000)-(0x41000000), accessing outside of DMA spaces
[ 119.292798] c1 [exynos_mem_release:58] private_data(0xd0340b80)
I didn't care about the permissions set to the sysfs interface as they don't matter anymore.
I'll be deploying the fix tomorrow throughout my kernels.
The only things that needs to be checked by then is if something else breaks, as HDMI or so. I can't test any of that since I don't have a dongle. In that case anyway the kernel log will tell you what other memory space is accessed and I can open that one up too if needed.
Note: Galaxy S2 / 4210 developers may have to add cma_region_descriptor_add calls to from wherever the memory blocks are defined (Machine file definition or arch/arm/plat-s5p/reserve_mem.c). My commit will work as is on S3 and N2 sources.
I'm off to bed.

Chainfire said:
and to disable the exploit at boot (before any Android app runs).
Click to expand...
Click to collapse
supercurio said:
Cannot protect efficiently against some potential attacks (typically, on boot).
Click to expand...
Click to collapse
First, thank you both for the hard work and quick release.
The main question here is, how efficient is the current implementation in both applications, regarding the protection at start up?
As long as I understand Chainfire somehow ensures that the fix will be applied before running any other (normal) application. Is it possible to install a new application, which to put itself on top of execution chain and exploit the hole, before your application is able to do a 0600 chmod?
If I understand correctly the supercurio's app doesn't promise anything on that matter?! If that is the case, then I guess the recommended app (for rooted phones) will be the Chainfire's solution, right?

julandroid said:
First, thank you both for the hard work and quick release.
The main question here is, how efficient is the current implementation in both applications, regarding the protection at start up?
As long as I understand Chainfire somehow ensures that the fix will be applied before running any other (normal) application. Is it possible to install a new application, which to put itself on top of execution chain and exploit the hole, before your application is able to do a 0600 chmod?
If I understand correctly the supercurio's app doesn't promise anything on that matter?! If that is the case, then I guess the recommended app (for rooted phones) will be the Chainfire's solution, right?
Click to expand...
Click to collapse
Correct.
At the moment, Supercurio's method relies on Android starting it at boot, using the same method any Android app uses to launch at boot. There is no guaranteed order of these apps being launched, and as such, a malicious app could be executing malicious code before the exploit is disabled.
RyanZA's method relies on the same mechanism as well and as such is still vulnerable. Furthermore, unlike Supercurio's and my own patch, RyanZA's patch chmod's to 0600 while ours chmod to 0400 or 0000. With 0600, system user can still run the exploit, so chaining a half-exploit that only gives system user followed by ExynosAbuse may still grant an attacker root access.
My method requires proper root and modifies /system, and disabling the exploit is done before any normal Android app (like those installed from the Play store) have a chance to execute their code. As long as you tell my app to disable the exploit at boot before you install a malicious app, and providing you do not grant a malicious app root (through SuperSU), this should protect against any exploit. Also note that after enabling applying the patch at boot, you can unroot in SuperSU again (SuperSU --> Settings --> Full Unroot) and the patch will keep working, but you'll be unrooted again (if you don't want root). On some devices it takes a reboot for SuperSU to truly disappear after that, by the way.
With my patch, I do advise testing the exploit was disabled after a reboot by running ExynosAbuse again, and verifying both checkboxes next to "Disable exploit" and "Disable exploit on boot" are enabled. These auto-detect the current state, and if the patch on boot was succesful both will be checked.

Chainfire said:
Correct.
At the moment, Supercurio's method relies on Android starting it at boot, using the same method any Android app uses to launch at boot. There is no guaranteed order of these apps being launched, and as such, a malicious app could be executing malicious code before the exploit is disabled.
RyanZA's method relies on the same mechanism as well and as such is still vulnerable. Furthermore, unlike Supercurio's and my own patch, RyanZA's patch chmod's to 0600 while ours chmod to 0400. With 0600, system user can still run the exploit, so chaining a half-exploit that only gives system user followed by ExynosAbuse may still grant an attacker root access.
My method requires proper root and modifies /system, and disabling the exploit is done before any normal Android app (like those installed from the Play store) have a chance to execute their code. As long as you tell my app to disable the exploit at boot before you install a malicious app, and providing you do not grant a malicious app root (through SuperSU), this should protect against any exploit. Also note that after enabling applying the patch at boot, you can unroot in SuperSU again (SuperSU --> Settings --> Full Unroot) and the patch will keep working, but you'll be unrooted again (if you don't want root). On some devices it takes a reboot for SuperSU to truly disappear after that, by the way.
With my patch, I do advise testing the exploit was disabled after a reboot by running ExynosAbuse again, and verifying both checkboxes next to "Disable exploit" and "Disable exploit on boot" are enabled. These auto-detect the current state, and if the patch on boot was succesful both will be checked.
Click to expand...
Click to collapse
As a preliminary quick-fix the chmod could also be handled in ramfs to ensure it's applied as soon as possible in the boot process.
By the way chmodding to 600 didn't brake any of both cameras on a Samsung 4.1.2 based ROM using the old libs with an update 6 kernel on my dev. S3. Will check if it's also behaving like this on 4.1.1 later today.
JP.
Sent from my custom Paranoid Android 2.54 / Yank555.lu CM10 kernel v1.3b Aroma (Linux 3.0.56) powered Galaxy S3 i9300 using Tapatalk 2

Yank555 said:
As a preliminary quick-fix the chmod could also be handled in ramfs to ensure it's applied as soon as possible in the boot process.
By the way chmodding to 600 didn't brake any of both cameras on a Samsung 4.1.2 based ROM using the old libs with an update 6 kernel on my dev. S3. Will check if it's also behaving like this on 4.1.1 later today.
Click to expand...
Click to collapse
Correct. Modifying it in initramfs would be even quicker, but a generic app can't do that. Also chmod to 0400, not 0600.

[Q] Random rebooting

Hi,
I recently bought a Nexus 5 in Antwerp, Belgium (about three weeks ago). The build number is KOT49H. The first few days I didn't receive a reboot but after downloading a couple of apps, my phone rebooted about 4 to 5 times a day. I decided to RMA the phone and since an employee from the store I bought it from said I didn't need to store it back to original settings I just deleted my personal information and some apps. Then the reboots just weren't as active as before, I received one or two that week and decided to just let it slide for another week or so. Now I rooted my phone for viper4android and to check the last_kmgs files and noticed the reboots are because of kernel panic.
[ 2591.876665] Kernel panic - not syncing: EXT4-fs panic from previous error
[ 2591.876667]
[ 2591.876788] [<c010de1c>] (unwind_backtrace+0x0/0x144) from [<c09ffa4c>] (dump_stack+0x20/0x24)
[ 2591.876864] [<c09ffa4c>] (dump_stack+0x20/0x24) from [<c0a0045c>] (panic+0x9c/0x21c)
[ 2591.876940] [<c0a0045c>] (panic+0x9c/0x21c) from [<c030f2d8>] (__ext4_abort+0xe0/0xf4)
[ 2591.876984] [<c030f2d8>] (__ext4_abort+0xe0/0xf4) from [<c030f664>] (ext4_journal_start_sb+0xa0/0x1a4)
[ 2591.877063] [<c030f664>] (ext4_journal_start_sb+0xa0/0x1a4) from [<c02fcb0c>] (ext4_rename+0x48/0x728)
[ 2591.877143] [<c02fcb0c>] (ext4_rename+0x48/0x728) from [<c0273334>] (vfs_rename+0x350/0x4c4)
[ 2591.877219] [<c0273334>] (vfs_rename+0x350/0x4c4) from [<c027366c>] (sys_renameat+0x1c4/0x1d4)
[ 2591.877295] [<c027366c>] (sys_renameat+0x1c4/0x1d4) from [<c02736a8>] (sys_rename+0x2c/0x30)
[ 2591.877341] [<c02736a8>] (sys_rename+0x2c/0x30) from [<c0107300>] (ret_fast_syscall+0x0/0x30)
[ 2592.877756] Rebooting in 5 seconds..
[ 2597.879359] Going down for restart now
[ 2597.880123] Calling SCM to disable SPMI PMIC arbiter
No errors detected
Boot info:
Last boot reason: kernel_panic
Click to expand...
Click to collapse
It also seems the reboots are almost always in the weekend when I am at my mother's house (in the week I live in a student room).
So if anyone has some advice or needs more information, just ask.
Thanks a lot.

Niurez said:
Hi,
I recently bought a Nexus 5 in Antwerp, Belgium (about three weeks ago). The build number is KOT49H. The first few days I didn't receive a reboot but after downloading a couple of apps, my phone rebooted about 4 to 5 times a day. I decided to RMA the phone and since an employee from the store I bought it from said I didn't need to store it back to original settings I just deleted my personal information and some apps. Then the reboots just weren't as active as before, I received one or two that week and decided to just let it slide for another week or so. Now I rooted my phone for viper4android and to check the last_kmgs files and noticed the reboots are because of kernel panic.
It also seems the reboots are almost always in the weekend when I am at my mother's house (in the week I live in a student room).
So if anyone has some advice or needs more information, just ask.
Thanks a lot.
Click to expand...
Click to collapse
Well..... If you had a phone and these problems happened because of "apps and viper4android" and then you got another phone and did the same thing and get the same result then it is obviously something you are doing. Did it do this before you loaded your apps and viper4android? What method did you use to root/ how did you do it? I highly doubt the time of the week has anything to do when it reboots but I could be wrong.
A kernel panic is defined as "A kernel panic is an action taken by an operating system upon detecting an internal fatal error from which it cannot safely recover."
You are obviously doing something that it does not like.
I searched some of the lines of code and compared it to this thread here: http://forum.xda-developers.com/showthread.php?t=2553949
Try loading a different kernel. It doesn't matter anyone and see if that fixes the problem, you are rooted so it should take three minutes.

mistahseller said:
Well..... If you had a phone and these problems happened because of "apps and viper4android" and then you got another phone and did the same thing and get the same result then it is obviously something you are doing. Did it do this before you loaded your apps and viper4android? What method did you use to root/ how did you do it? I highly doubt the time of the week has anything to do when it reboots but I could be wrong.
Click to expand...
Click to collapse
Well it started before I rooted the phone. The apps I do use are nothing too special just the regular games and chat services that almost any normal smartphone user has installed. The method I used to root was in a thread I found on this forum and on the first page of google. Well, my phone hasn't rebooted once when I was at my student room and has rebooted about 4 times this day when I am at my mom's. And I didn't receive another phone yet. This is still the phone I bought originally from Mediamarkt in Antwerp.

Niurez said:
Well it started before I rooted the phone. The apps I do use are nothing too special just the regular games and chat services that almost any normal smartphone user has installed. The method I used to root was in a thread I found on this forum and on the first page of google. Well, my phone hasn't rebooted once when I was at my student room and has rebooted about 4 times this day when I am at my mom's. And I didn't receive another phone yet. This is still the phone I bought originally from Mediamarkt in Antwerp.
Click to expand...
Click to collapse
I edited my previous post and may have a solution, try and load a different kernel since you are rooted.

mistahseller said:
I edited my previous post and may have a solution, try and load a different kernel since you are rooted.
Click to expand...
Click to collapse
Also the reboots happen when the phone is idle. It happened like two or three times the phone froze while using Google All Access and just rebooted. I am pretty sure the reboots aren't because of my faulty usage.
I will try the different kernel but I still feel not pretty comfortable that the original kernel just reboots. Maybe RMA is my only solution? Thing is the employee from Mediamarkt said I'd miss my phone for minimum three weeks. I don't even own my phone that long.

kernel panic is because of a different error. it can be caused by just about anything. in the partial last_kmsg that you posted, you didnt include the error, only the outcome of the error. chances are that its an app causing it though. yes, apps cause random reboots. there are too many that arent written very well. i suggest wiping your device and not adding any apps for a day. if you dont get any random reboots, add one app at a time until your phone starts rebooting. then youll know which app it is and isnt.

simms22 said:
kernel panic is because of a different error. it can be caused by just about anything. in the partial last_kmsg that you posted, you didny include the error, only the outcome of the error. chances are that its an app causing it though. yes, apps cause random reboots. there are too many that arent written very well. i suggest wiping your device and not adding any apps for a day. if you dont get any random reboots, add one app at a time until your phone starts rebooting. then youll know which app it is and isnt.
Click to expand...
Click to collapse
This is the last zip file syslog provided me. Hope it has more information.

Niurez said:
This is the last zip file syslog provided me. Hope it has more information.
Click to expand...
Click to collapse
looks ike an i/o error. it had trouble transferring data to a sector. i dont know what would have caused it. an app issue, a corrupted sector, whatever it was the phone doesnt like it.
id try running the phone without any installed apps for a day, see if it still reboots. if it doesnt, it was an app. if it still reboots, id wipe out the phone completely and flash the factory image. its also possible that a sector is corrupted somehow, or the data in it. a flash of the factory image should take care of it.
[ 2591.685522] mmc1: data txfr (0x00100000) error: -110 after 671 ms
[ 2591.685634] sdhci: =========== REGISTER DUMP (mmc1)===========
[ 2591.685674] sdhci: Sys addr: 0x80000008 | Version: 0x00003802
[ 2591.685745] sdhci: Blk size: 0x00007200 | Blk cnt: 0x00000008
[ 2591.685785] sdhci: Argument: 0x003ea888 | Trn mode: 0x0000002b
[ 2591.685857] sdhci: Present: 0x01e80100 | Host ctl: 0x00000035
[ 2591.685897] sdhci: Power: 0x0000000b | Blk gap: 0x00000000
[ 2591.685967] sdhci: Wake-up: 0x00000000 | Clock: 0x00000007
[ 2591.686006] sdhci: Timeout: 0x0000000c | Int stat: 0x00000000
[ 2591.686077] sdhci: Int enab: 0x03ff800b | Sig enab: 0x03ff800b
[ 2591.686116] sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
[ 2591.686186] sdhci: Caps: 0x642dc8b2 | Caps_1: 0x00008007
[ 2591.686257] sdhci: Cmd: 0x0000193a | Max curr: 0x00000000
[ 2591.686296] sdhci: Resp 1: 0x00000000 | Resp 0: 0x00000900
[ 2591.686367] sdhci: Resp 3: 0x00000900 | Resp 2: 0x00000000
[ 2591.686406] sdhci: Host ctl2: 0x00000003
[ 2591.686445] sdhci: ADMA Err: 0x00000003 | ADMA Ptr: 0x35a40008
[ 2591.686517] mmc1: clk: 200000000 clk-gated: 0 claimer: mmcqd/1 pwr: 10
[ 2591.686557] mmc1: rpmstatus[pltfm](runtime-suspend:usage_count:disable_depth)(0:0:0)
[ 2591.686629] sdhci: ===========================================
[ 2591.690787] mmcblk0: error -110 transferring data, sector 4106376, nr 8, cmd response 0x900, card status 0x100c02
[ 2591.690868] end_request: I/O error, dev mmcblk0, sector 4106376
[ 2591.690912] end_request: I/O error, dev mmcblk0, sector 4106376
[ 2591.691009] Aborting journal on device mmcblk0p28-8.
[ 2591.691995] journal commit I/O error
[ 2591.692242] done.
[ 2591.705472] Freezing user space processes ... (elapsed 0.001 seconds) done.
[ 2591.707353] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[ 2591.708900] Suspending console(s) (use no_console_suspend to debug)
[ 2591.785532] PM: suspend of devices complete after 74.713 msecs
[ 2591.786542] PM: late suspend of devices complete after 1.004 msecs
[ 2591.787851] PM: noirq suspend of devices complete after 1.302 msecs
[ 2591.788063] Disabling non-boot CPUs ...
[ 2591.788159] msm_pm_enter
[ 2591.788159] msm_pm_enter: power collapse
[ 2591.788159] msm_pm_enter: return
[ 2591.789882] PM: noirq resume of devices complete after 1.097 msecs
[ 2591.791208] PM: early resume of devices complete after 0.800 msecs
[ 2591.867621] PM: resume of devices complete after 76.407 msecs
[ 2591.869839] Restarting tasks ... done.
[ 2591.875706] EXT4-fs error (device mmcblk0p28): ext4_journal_start_sb:328: Detected aborted journal
[ 2591.875851] EXT4-fs (mmcblk0p28): Remounting filesystem read-only
[ 2591.876665] Kernel panic - not syncing: EXT4-fs panic from previous error
Click to expand...
Click to collapse

simms22 said:
looks ike an i/o error. it had trouble transferring data to a sector. i dont know what would have caused it. an app issue, a corrupted sector, whatever it was the phone doesnt like it.
id try running the phone without any installed apps for a day, see if it still reboots. if it doesnt, it was an app. if it still reboots, id wipe out the phone completely and flash the factory image. its also possible that a sector is corrupted somehow, or the data in it. a flash of the factory image should take care of it.
Click to expand...
Click to collapse
Thanks, the thing is though that it rebooted three times while laying on my nightstand this day, every time I checked to see what time it was it was on the sim lock screen. Now during the day with average use (only using whatsapp and all access) it hasn't rebooted a single time. If there was a way to ensure a reboot I seriously don't know how to. If a flash of the factory image would be the final step, it may be in my best interest to start with that immediately instead of trying one day without apps? As I sometimes don't register a single reboot in four days.

Niurez said:
Thanks, the thing is though that it rebooted three times while laying on my nightstand this day, every time I checked to see what time it was it was on the sim lock screen. Now during the day with average use (only using whatsapp and all access) it hasn't rebooted a single time. If there was a way to ensure a reboot I seriously don't know how to. If a flash of the factory image would be the final step, it may be in my best interest to start with that immediately instead of trying one day without apps? As I sometimes don't register a single reboot in four days.
Click to expand...
Click to collapse
i think a day without apps first would be best, at least it would tell us if it is an app or not. one time on my gnex, i started getting random reboots when there were none before. about 3 days worth of reboots had me confused. i was about to flash the factory img, but i remembered i installed an app the day before the reboots started. even though i only opened it one time since i installed it, i decided to try removing it first. so i removed it, and never had a random reboot on my gnex since.

simms22 said:
i think a day without apps first would be best, at least it would tell us if it is an app or not. one time on my gnex, i started getting random reboots when there were none before. about 3 days worth of reboots had me confused. i was about to flash the factory img, but i remembered i installed an app the day before the reboots started. even though i only opened it one time since i installed it, i decided to try removing it first. so i removed it, and never had a random reboot on my gnex since.
Click to expand...
Click to collapse
Oh ok, I'll try this as soon as I'm done with my finals monday since I still use whatsapp quite a lot to discuss studying material. I also only got like 5 apps. The only apps that aren't recognized worldwide might be "De Lijn" app, which I use to check the bus times and "MyMobistar" to check information about my provider. Could this also be because something is faulty in my phone itself and that the only resolution would be to RMA it?

Niurez said:
Oh ok, I'll try this as soon as I'm done with my finals monday since I still use whatsapp quite a lot to discuss studying material. I also only got like 5 apps. The only apps that aren't recognized worldwide might be "De Lijn" app, which I use to check the bus times and "MyMobistar" to check information about my provider. Could this also be because something is faulty in my phone itself and that the only resolution would be to RMA it?
Click to expand...
Click to collapse
its possible. if it still happens after flashing the factory img, and some time without any apps installed, then id say the phones hardware is faulty, and rma it.

simms22 said:
its possible. if it still happens after flashing the factory img, and some time without any apps installed, then id say the phones hardware is faulty, and rma it.
Click to expand...
Click to collapse
Ok, I'll keep you updated.
Much thanks.

Niurez said:
Ok, I'll keep you updated.
Much thanks.
Click to expand...
Click to collapse
Hi! I'm facing same problem as you: random reboots when not using the phone.
Even my bugreport shows something similar to yours.
Did you resolve it?

[ROM & discussion][7.1.2_r11][Grouper|Tilapia][3May2017]AOSP - UNOFFICIAL

In Android ROMs' developments, I always start with AOSP. It is the root and if I want to do it right, I have to make it work for AOSP first. Putting the AOSP tests in my kernel thread is getting messy. As I would continue my work here for a while. Starting a thread for AOSP seems reasonable.
Here is for sharing of experiences and discussions.
There would be no nightly, weekly or monthy. I would follow the releases of AOSP and keep it as genuine as possible. If you are looking for a feature, there are many nice ROMs out there.
Known Issues:
　1. AOSP Camera App　The AOSP Camera2 app is not working with the Nexus 7 (2012) which is the only (I think) Nexus device with a Front Camera but not the Back Camera. The new Camera2 app set the back camera as default. I can make the preview shown by a simple overlay configs. But, make it really work would be quite a work. In the app market(s), there are many camera apps already taking care of that and would work flawlessly. I see no reason to waste time on that.​　2. "E:unknown command [log]"　If you got this message when flashing, don't panic. It's the new "block_image_update()" in recovery cause that. It would do no harm and it would be gone in the next TWRP.​　3 Please report.
Tips:
　1. DT2W　At deep sleep, the idled CPU takes time to resume. If the taps are too close, it might not be recognized. Delay the duration between taps would give you better results.​　2. Built-in File Explorer　There is an built-in file explorer in AOSP. We can explore the files as well as installing apks.
Its in: Settings > Storage > Explore (under the storage you want. In case of Nexus 7, only the internal and OTG exist.)​Change log:
Code:
[COLOR="Blue"]2017/5/3[/COLOR]
　- Android-7.1.2_r11 (NHG47L)
[COLOR="Blue"]2017/4/9[/COLOR]
　- Android-7.1.2_r5 (N2G47J)
　- PerformanceControl: boot up settings fixed
　- Fix Wifi hotspot
　- Performance patches
[COLOR="Blue"]2017/3/8[/COLOR]
　- Android-7.1.1_r28 (N6F26U)
[COLOR="Blue"]2017/2/8[/COLOR]
　- Android-7.1.1_r21 (NOF26W)
[COLOR="Blue"]2017/1/6[/COLOR]
　- Android-7.1.1_r13 (N6F26Q)
　- Camera: Fix video recording
[COLOR="Blue"]2016/12/16[/COLOR]
　- Android-7.1.1_r6 (NMF26Q)
　- SEPolicy update
[COLOR="Blue"]2016/12/7[/COLOR]
　- Android-7.1.1_r4 (NMF26O)
　- Fix the Camera
[COLOR="Blue"]2016/11/11[/COLOR]
　- Android-7.1.0_r7 (NDE63X)
[COLOR="Blue"]2016/10/24[/COLOR]
　- Android-7.1.0_r4 (NDE36P)
　- Remove every recovery related resources
[COLOR="Blue"]2016/10/14[/COLOR]
　- Android-7.0.0_r14 (NBD90Z)
　- Shield the occasional crash in MTP Document provider
　- USB and Bluetooth Tethering support enabled
[COLOR="Blue"]2016/9/23[/COLOR]
　- Android-7.0.0_r6 (NRD90U)
　- latest DC kernel (Android-7.0 branch)
　- PerformanceControl: version 2.1.6
　- Find a way to fix the hwcomposer for video/audio playback, need to review later
　- A few sepolicy patches for Gapps and Mediaserver
　- SELinux: Enforcing
Downloads: :highfive:
　Hosts: Android File Host　MEGA　mirror: 百度网盘
　Note: I only tested it in TWRP 3.0.2.
　 　 　PerformanceControl app requires ROOT access.
　 　 　Root access can be obtained by the systemless SuperSU from @Chainfire.
　Gapps: opengapps (pico) and BaNKs Gapps for 7.0 are tested
Sources:
　Sources in github
Credits: :good:
　** Definitely the AOSP
　** The AndroidFielHost provide a FREE host with no limits and expiration.
　** All the developers who help the Nexus 7 (2012) development
　** All those who donate and/or help the developers. Giving us the resources and reason to carry on.
Donations: :angel:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}

Discussions
Anyone has any idea are welcome to post here
DT2W
Sometimes it won't wakeup after a long DEEP_SLEEP
When volume buttons are also enabled for wakeup. It won't work too. Seems there are situations "soft pwr button press" won't work.
Fail after reboot
Code:
Supported API: 3
E: unknown fs_type "f2fs" for /cache
E: Can't mount /cache/recovery/last_locale
Some of you might encounter the above message after reboot. I never encountered before but there is definitely something wrong.
@millosr found that it was the recovery being replaced. I think that make sense and I want to study why.
I looked into the source. In the original AOSP, an OTA might come with a recovery patch. Stated in the build/core/Makefile "boot.img + recovery-from-boot.p + recovery-resource.dat = recovery.img"
It would generate the "recovery.img by the above formula itself. Custom ROMs usually won't carry a recovery and this part was usual ignored.
There is a warning in TWRP before reboot. Some of you might not read clearly and slide to continue immediately. In that case, the above mentioned recovery.img will be generated and flashed to the /recovery partition. Everything seems normal but after reboot.
When the script kick in, it would execute the "new" recovery. As a normal recovery, it would load the fstab and try to mount the partitions. The current fstab version is API 3. Almost all ROMs (no matter how close to AOSP) would have F2FS support. When we open a typical fstab:
Code:
/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 ro wait
/dev/block/platform/sdhci-tegra.3/by-name/CAC /cache f2fs noatime,nosuid,nodev,nodiratime,discard,inline_xattr,inline_data,inline_dentry wait,check
/dev/block/platform/sdhci-tegra.3/by-name/CAC /cache ext4 noatime,nosuid,nodev,nomblk_io_submit,journal_async_commit,errors=panic wait,check
Note that the second line is the declaration for the /cache in f2fs. Stock AOSP recovery doesn't support f2fs. That's why the above error shown. Since it fail to mount /cache, the last_locale is not loaded and recovery would hang.
How to recover?
Naturally, you have to flash TWRP again.
First of all, you need to boot into bootloader (fastboot mode)
Some init.xxx.rc might start adbd earlier and in this case "adb reboot bootloader" would do the job.
If adbd was not started before the hang, the command won't work. In this case you can only use the pwr+vol. down combination.
If it is still hanging, the buttons might not work. Press the power button continuously might lead to repeatedly reboot. It is better to make sure the device is OFF first.
1. Connect to a charger.
2. Press the power button until you see the charging image
3. Release the power button immediately.
4. After that, press the volume down button first, and then the power button.
It would go to the bootloader.
Note: /system is not really formatted during flashing. To make sure no residue left in /system, it is better to wipe the /system before flashing.
For ROM builders, there is a flag BOARD_USES_FULL_RECOVERY_IMAGE. Set it to true will stop the generation of recovery-resource.dat (in /system/etc) and break the above formula.

Does D2TW require the digitizer to remain permanently on? Trying to guage the impact of such a feature before I turn it on.

Nintonito said:
Does D2TW require the digitizer to remain permanently on? Trying to guage the impact of such a feature before I turn it on.
Click to expand...
Click to collapse
obviously.
---------- Post added at 09:52 AM ---------- Previous post was at 09:46 AM ----------
@daniel_hk good to see a separate thread. Will test this build this weekend as i am already on grouper.

：手指划线：

Thanks for bringing nougat to our beloved Nexus 7!!!
I just flashed but no matter which gapps I use, I can't make playstore and google play services installed.
Any hints?
Thanks.

ho0o0o11111 said:
Thanks for bringing nougat to our beloved Nexus 7!!!
I just flashed but no matter which gapps I use, I can't make playstore and google play services installed.
Any hints?
Thanks.
Click to expand...
Click to collapse
If you want anyone to help, you have to provide details.
The tested Gapps' are listed in OP. "No matter which gapps" ?
Can you tell us which one and version you actually tried?
What's your flashing procedures? etc.

daniel_hk said:
If you want anyone to help, you have to provide details.
The tested Gapps' are listed in OP. "No matter which gapps" ?
Can you tell us which one and version you actually tried?
What's your flashing procedures? etc.
Click to expand...
Click to collapse
Procedures (clean flash)
- rom
- gapps
- supersu
- reboot
- no playstore/play services have been installed after reboot
I used explorer to check and found that those gapps are installed (e.g. Vending.apk) but their sizes are all in 0kb.
the gapps I used were opengapps PICO and Banks. (I tried both. All after clean flash)
Finally I got playstore installed as follows
- flash rom/gapps/supersu
- reboot
- uninstall some system apps I don't need
- flash gapps again
then the playstore appears in app drawer. (And it works)
However, I have another big problem after reboot.
My device is now stuck in bootloop after splashscreen.
It just shows message as follows and I can't enter recovery/bootloader.
Supported API: 3
E: unknown fs_type "f2fs" for /cache
E: Can't mount /cache/recovery/last_locale
In the following page I found a solution "adb reboot bootloader" but I can't even enter bootloader/fastboot mode.
http://forum.xda-developers.com/nex...ip-linux-tegra-nv-3-4-bringup-t3128195/page46
still trying...
Any helps would be appreciated.
Thanks.

ho0o0o11111 said:
Procedures (clean flash)
- rom
- gapps
- supersu
- reboot
- no playstore/play services have been installed after reboot
I used explorer to check and found that those gapps are installed (e.g. Vending.apk) but their sizes are all in 0kb.
the gapps I used were opengapps PICO and Banks. (I tried both. All after clean flash)
Finally I got playstore installed as follows
- flash rom/gapps/supersu
- reboot
- uninstall some system apps I don't need
- flash gapps again
then the playstore appears in app drawer. (And it works)
However, I have another big problem after reboot.
My device is now stuck in bootloop after splashscreen.
It just shows message as follows and I can't enter recovery/bootloader.
Supported API: 3
E: unknown fs_type "f2fs" for /cache
E: Can't mount /cache/recovery/last_locale
In the following page I found a solution "adb reboot bootloader" but I can't even enter bootloader/fastboot mode.
http://forum.xda-developers.com/nex...ip-linux-tegra-nv-3-4-bringup-t3128195/page46
still trying...
Any helps would be appreciated.
Thanks.
Click to expand...
Click to collapse
I think you are not using the Official TWRP. There are similar reports having the same problem for other MM ROMs too.
You may try the Official TWRP 3.0.2 here (follow the link if you have a Tilapia) and flash everything again.
You might have corrupted your /cache and /data. It is better format them (to ext4 or f2fs) in the Official TWRP again.
Good luck!

daniel_hk said:
I think you are not using the Official TWRP. There are similar reports having the same problem for other MM ROMs too.
You may try the Official TWRP 3.0.2 here (follow the link if you have a Tilapia) and flash everything again.
You might have corrupted your /cache and /data. It is better format them (to ext4 or f2fs) in the Official TWRP again.
Good luck!
Click to expand...
Click to collapse
Thanks for your suggestion but the TWRP I used were downloaded from TWRP's official website, so I supposed it is official version.
I can't flash TWRP again as I am still struggling to enter bootloader mode.

ho0o0o11111 said:
Thanks for your suggestion but the TWRP I used were downloaded from TWRP's official website, so I supposed it is official version.
I can't flash TWRP again as I am still struggling to enter bootloader mode.
Click to expand...
Click to collapse
Which version? eariler version might have a wrong fstab which have issue on f2fs.
Make sure you got the latest version 3.0.2
You can't go to boot loader?
That means you press pwr+vol down and it won't reboot to bootloader?
That's strange.
"adb reboot bootloader" only work if the adbd is up. That means you can use "adb devices" to check the existance of your device.
You may try this:
1. connect to the charger
2. pressing the pwr button for > 8 seconds.
See if the tablet reboot. If yes, it would boot into charging mode. Pwr+vol down again would work.
If it doesn't reboot after you pressed say 20 seconds, you need to remove the battery.
Good luck!

@daniel_hk
Thanks for the new AOSP build Daniel. Nice work fixing the hardware decoder, my Netflix is now working and I was able to play one of my MP4 movies with BS Player in HW mode. I've been changing back and forth between your first AOSP 7 build and your DU 7 build with dirty flashes. With this build I decided to clean flash and at first things were very sluggish but settled down after a reboot and probably after Google finished whatever it does in the background. LOL Aside from a few occasional random force closes, it's running pretty well.
A couple of observations:
As mentioned, I did a clean install with this build. I'm using official TWRP 3.02 and installed the rom and 7.0 Open Gapps nano 20160915 at the same time and when it booted up for the first time, there were no gapps installed. I powered down and then went back into TWRP and reflashed the gapps, this time they were there upon reboot. Surprisingly, I didn't have to set permissions for Google Play or Play Store, as they were already correctly set??? I did run into a snag when trying to download apps from PS, clearing the data for the download manager app solved that problem for me.
I installed a camera app (HD Camera) from Play Store and it works but when I use my phone's camera, it reminds me how crappy the N7 camera is. LOL
After setting things up, I wanted to try phhsuperuser (no Magisk) to root and it went fine. All of my apps that require root worked...except Titanium Backup. I tried uninstalling/reinstalling both phhsuperuser and Titanium but couldn't get it to work. I rely on Titanium quite a bit, so I flashed Supersu 2.78 and all's well.
Thanks again.
Mike T

Do games work on this rom?

Hi,
This is the best 7.0 ROM so far !!!
Smooth, video HW decoding is working, games work perfect.
As webdroidmt said I also had to reflash GAPPS to have GAPPS installed and i had to give proper permissions on Google Play service to stop seeing the "google play service stop" message.
All Apps/games that i installed are working properly.
Thanks Daniel_hk for your work

Many thanks Works like a charm !
Is SEpolicy restrictive in your build? (I cannot see it from Settings -> about tablet)
.
Can you post your manifest on Your Github for easier building ?

Hi, currently testing your ROM, looks awesome!
When Browsing the web with Chrome, loads and loads of SELinux denials, mostly when the page loads:
Code:
09-26 13:34:20.990 4424 4424 W Thread-4: type=1400 audit(0.0:174): avc: denied { ioctl } for path="socket:[45348]" dev="sockfs" ino=45348 ioctlcmd=8b1b scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:r:untrusted_app:s0:c512,c768 tclass=udp_socket permissive=0
This message times * 100 for every page load.

paasoares said:
Hi,
This is the best 7.0 ROM so far !!!
Smooth, video HW decoding is working, games work perfect.
As webdroidmt said I also had to reflash GAPPS to have GAPPS installed and i had to give proper permissions on Google Play service to stop seeing the "google play service stop" message.
All Apps/games that i installed are working properly.
Thanks Daniel_hk for your work
Click to expand...
Click to collapse
In any case, it's a good practice to read the console after flash anything. There might already be essential messages which not necessarily in red.
I also experience SuperSU need to flash again. I just found out something that might help. Seems SuperSU would use the cache to start a checking process in the next boot. I don't know if it would help gapps too.
1. Try factory reset before flashing.
2. Flash ROM+Gapps+SuperSU
3. After that don't do wipe cache/d-cahce again. (factory reset already include this action)
Good luck!
3yan said:
Many thanks Works like a charm !
Is SEpolicy restrictive in your build? (I cannot see it from Settings -> about tablet)
.
Can you post your manifest on Your Github for easier building ?
Click to expand...
Click to collapse
I think you meant "Enforcing". Yes, it is enforcing. Only some Custom ROM would show this in About but not AOSP.
There is a shell command "getenforce" which you can check the SEPolicy status.
If you read the OP, you would know its an AOSP without any mod/tweak, just porting. You can get the manifest and all the helps in https://source.android.com.
Good luck!
fat-lobyte said:
Hi, currently testing your ROM, looks awesome!
When Browsing the web with Chrome, loads and loads of SELinux denials, mostly when the page loads:
Code:
09-26 13:34:20.990 4424 4424 W Thread-4: type=1400 audit(0.0:174): avc: denied { ioctl } for path="socket:[45348]" dev="sockfs" ino=45348 ioctlcmd=8b1b scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:r:untrusted_app:s0:c512,c768 tclass=udp_socket permissive=0
This message times * 100 for every page load.
Click to expand...
Click to collapse
Chrome has many versions and it should not be an untrusted app. I'm testing the CarbonROM which has a bloated Chrome and being treated as isolated app. It might take time for those UID's being properly handled.
I already included some extra permissions which would be include in my later builds.
Anyway, we would encounter denials more often in apps. That's what newer Android intent to do.

Code:
09-26 19:14:02.119 189 344 D hwcomposer: hotplug_thread: processing control fd
09-26 19:14:02.119 189 344 I hwcomposer: hotplug: connected = 0
09-26 19:14:03.469 503 579 W AlarmManager: Unrecognized alarm listener [email protected]
09-26 19:14:03.469 503 579 E WifiScanner: listener cannot be found
09-26 19:14:03.478 677 677 E wpa_supplicant: wlan0: Failed to schedule PNO
09-26 19:14:03.481 503 581 E SupplicantWifiScannerImpl: PNO state change to true failed
09-26 19:14:03.481 503 581 E SupplicantWifiScannerImpl: Failed to start PNO scan
09-26 19:14:03.484 503 581 W SupplicantWifiScannerImpl: No PNO scan running
09-26 19:14:03.486 503 579 E WifiConnectivityManager: PnoScanListener onFailure: reason: -1 description: pno scan failed
This is repeated every 5 minutes during deep sleep. I'm not an expert, but this probably doesn't help with battery drain
I'm also having some touch sensitivity issues when coming out of deep sleep or off the charger. I have to do some more testing, then I will have more details.

I wanted to try this 'Sept 23' ROM as it should play video OK: in the end I got it to work, and I can now indeed play video in some video based apps that did not work before. I used the older DU ROM and also the nAOSP ROM of millosr. There video does not work yet.
But with this Sept23 ROM I had a fight with Gapps to get it to work... First the Gapps I normally use failed to install in TWRP. At least, that is what I think I saw: the progress bar suddenly jumps ahead as if the install process was broken off somehow. So I again clean wiped all and now used opengaps-pico. That installed fine, but on first boot, no gapps. So I again installed opengapps and now finally I had working playstore. Strange, I never ran into something like this before (I am mostly active on Xperia S with nAOSP).
But the story ends well, as my video now works: great job !

fat-lobyte said:
Code:
09-26 19:14:02.119 189 344 D hwcomposer: hotplug_thread: processing control fd
09-26 19:14:02.119 189 344 I hwcomposer: hotplug: connected = 0
09-26 19:14:03.469 503 579 W AlarmManager: Unrecognized alarm listener [email protected]
09-26 19:14:03.469 503 579 E WifiScanner: listener cannot be found
09-26 19:14:03.478 677 677 E wpa_supplicant: wlan0: Failed to schedule PNO
09-26 19:14:03.481 503 581 E SupplicantWifiScannerImpl: PNO state change to true failed
09-26 19:14:03.481 503 581 E SupplicantWifiScannerImpl: Failed to start PNO scan
09-26 19:14:03.484 503 581 W SupplicantWifiScannerImpl: No PNO scan running
09-26 19:14:03.486 503 579 E WifiConnectivityManager: PnoScanListener onFailure: reason: -1 description: pno scan failed
This is repeated every 5 minutes during deep sleep. I'm not an expert, but this probably doesn't help with battery drain
I'm also having some touch sensitivity issues when coming out of deep sleep or off the charger. I have to do some more testing, then I will have more details.
Click to expand...
Click to collapse
Did you set "keep wi-fi on during deep sleep" to NEVER?
My tablet drain 5% during this night (about 8 hours), so i guess this is normal/acceptable

[ROM][7.1.2][i9305]Unofficial LineageOS 14.1 by Exynos4 Team

[ROM][7.1.2][i9305]Unofficial LineageOS 14.1 by Exynos4 Team
Code:
/*
* Your warranty is now void.
*
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this ROM
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at me for messing up your device, I will laugh at you.
*/
What is Exynos4 Team?
The Exynos4 team is composed of the current maintainers for T0LTE/T0LTEKOR for both LineageOS and Resurrection Remix.
(@Option58, @kozmo21 and @PoisonNinja)
Difference between this and official Lineage 14.1
This is more like a bleeding edge build. Upcoming changes/fixes will show up here first, and eventually make it into Lineage official. So, if you want the latest and greatest changes for the Note 2 and than ported to the i9305, if possible, flash this instead of official.
Due to LineageOS rules, if you are switching between official and unofficial builds you will have to clean flash.
Exynos4 Team like to say thanks to:
The great developer community out there. We've had a lot of help from other people.
- the LineageOS team
- the Galaxy S3 LineageOS maintainer github.com/fourkbomb.
- the NamelessROM project github.com/namelessrom.
- xda users for testing and bug reports.
And I want to say thanks to:
PoisonNinja and Option58, who helped me a lot to set up the device tree and vendor blobs for that Exynos4 rom,
which is mainly created or grown out of the hwc idea.
and credits to @p.a.n for his work and providing his changes and patches.
Working
Graphics
Wifi
Data
RIL
Bluetooth (?!?)
Sensors
Vibration
Camera
NFC
Audio
Video Playback
Not working/Bugs/Unknown
[*]GPS is not working currently Fix is in second post!!
Bluetooth audio (may or may not work for you), please check and report back
MTP crashes when uninstalling an app
Installation
Read the FAQ to familiarize yourself with any issues that may come up
Make sure you're using the latest TWRP version
Download and copy latest rom version to the phone, preferably on internal storage
Factory reset in TWRP (Very important! Do not skip)
Format system, cache, dalvik, data
Flash unofficial LineageOS 14.1
Flash Gapps
Optional: Flash root package
Reboot
Be patient. The first boot will take between 5 - 15 minutes.
See the FAQ to avoid common issues
For updates, it's OK to dirty flash. If you experience any issues however, it is recommended that you clean flash.
Download
lineage-14.1-20170618-UNOFFICIAL-i9305-HWC.zip: June 18, 2017
6/18/2017 (i9305)
Sync with the latest Lineage sources
Hardware composer fixes
[*] Switch back to proprietary RIL 4.4 blobs
Properly fixed screencast
Lots of security patches in the kernel
Temporarily switched SELinux to permissive
XDA:DevDB Information
LineageOS 14.1 by Exynos4 Team, ROM for the Samsung SIII LTE (i9305)
Contributors
PoisonNinja, Option58, kozmo21, LineageOS team
Source Code: https://github.com/Exynos4
ROM OS Version: 7.x Nougat
Based On: LineageOS
Version Information
Status: Beta
Created 2017-06-18
Last Updated 2017-06-18

Just a few info
Root
LineageOS removed builtin root, so you need to flash the root package linked above.
Please test especially calls, incoming and outgoing, mobile data and bluetooth.
The rom/build is based on pans vendor proprietary (ril) blobs and should improve our ril and hopefully fix our reboot problem.
Kernel is set to permissive at the moment. Stickt version also ok.
Please also test bluetooth (audio transfer), because I am not sure, whether it works correct.
GPS is currently not working. Will try to fix that with one of the next builds.
Edit: previous GPS fix is working and solve the problem. Changes will be added in next update.
You can also find it here attached fixed in version: 0702
Other than the HWC and blob changes, the rom is based on pure lineageos sources/repos.

if I need another one

I'm getting bootloops with that build (it doesn't reach far enough for adb to pull the logs). I tried building a build with older blobs yesterday. My build was getting SIGSEGV caused by ks. I'll try building a non hwc version using your blobs and i9305 repository.

I also noticed some reboots, but none anymore during the last night. So I assume that the reboots could not be solved with changing the blobs and also not with that different ril sources/blobs. I doubt that the reboots will be gone with a non hwc version, but we will see. Beside of that are the other things working? Calls, mobile data etc?

Non hwc version booted ok. at_distributor is having problems :
Code:
06-19 03:06:25.941 2812 2812 F libc : CANNOT LINK EXECUTABLE "/system/bin/at_distributor": cannot locate symbol "supportExpandedNV" referenced by "/system/bin/at_distributor"...
06-19 03:06:25.941 2812 2812 F libc : Fatal signal 6 (SIGABRT), code -6 in tid 2812 (at_distributor)
but RIL works anyway (at least SMS). I'll try replacing it with stock i9305 at_distributor. I've got one reboot but I didn't launch logcat/kmsg before and had only short last_kmsg. We should try replacing the blobs with the stock i9305 ones because for now they are mixed. We could give a shot to persist.radio.apm_sim_not_pwdn=1 in system.prop too. I haven't tested anything beside RIL reboots (I'm testing it during night and hoping it will manage to reboot before next day because for daily usage I'm going back to the last stable rom).

Many thanks and when you managed to solve the mix up and your tests are ok, it would be good, if you can upload your changes to github. Think it doesn't make sense that we do all the work twice
Edit: seems to be again or still:
Code:
Kernel panic - not syncing: Fatal exception
and I think caused because of:
Code:
<6>[ 184.685341] c0 mdm_hsic_pm_notify_event: unblock request
<6>[ 184.685375] c0 notify_modem_fatal or shutdown
<6>[ 184.685403] c0 ap2mdm_status is high
<6>[ 184.685425] c0 ap2mdm_errfatal is high
<6>[ 184.685449] c0 mdm2ap_status is low
<6>[ 184.685471] c0 mdm2ap_errfatal is low
<6>[ 184.685492] c0 During shutdown, return notify_modem_fatal

rodman01 said:
Many thanks and when you managed to solve the mix up and your tests are ok, it would be good, if you can upload your changes to github. Think it doesn't make sense that we do all the work twice
Edit: seems to be again or still:
Code:
Kernel panic - not syncing: Fatal exception
and I think caused because of:
Code:
<6>[ 184.685341] c0 mdm_hsic_pm_notify_event: unblock request
<6>[ 184.685375] c0 notify_modem_fatal or shutdown
<6>[ 184.685403] c0 ap2mdm_status is high
<6>[ 184.685425] c0 ap2mdm_errfatal is high
<6>[ 184.685449] c0 mdm2ap_status is low
<6>[ 184.685471] c0 mdm2ap_errfatal is low
<6>[ 184.685492] c0 During shutdown, return notify_modem_fatal
Click to expand...
Click to collapse
Don't worry, I'll upload when I have something that's worth uploading. If you got
Code:
<6>[ 184.685425] c0 ap2mdm_errfatal is high
then the issue is still there.
Update
at_distributor from stock references the same function (supportExpandedNV) so the problem rather doesn't lie in the at_distributor itself but in a missing file that contains the missing function.
Update 2
Replacing ks blob with i9305 stock one alone won't work. That leads to the problem that @p.a.n had (https://forum.xda-developers.com/showpost.php?p=64395738&postcount=218) (https://forum.xda-developers.com/showpost.php?p=64448961&postcount=269)

mtr_ said:
Update 2
Replacing ks blob with i9305 stock one alone won't work. That leads to the problem that @p.a.n had (https://forum.xda-developers.com/showpost.php?p=64395738&postcount=218) (https://forum.xda-developers.com/showpost.php?p=64448961&postcount=269)
Click to expand...
Click to collapse
There is a simple solution (or hack to be more precise) to this and I believe I`ve also described it somewhere here - open the ks binary with some binary editor, find the connect string (it should be there twice) and replace it something else with the same length (I used xonnect).
This is a linker related problem, ks contains symbol connect, which replaces connect from libc (I hope it is there, if not it is some other system library), but with a totally different functionality, which causes a crash. Don`t ask me why this is happening in one environment and in other (the old one), I don`t know.

Maybe this last_kmsg looks better now?
Code:
Samsung S-Boot 4.0 for GT-I9305 (Sep 12 2014 - 13:40:58)
EXYNOS4412(EVT 1.1) / 2044MB / 0MB / Rev 2 / I9305XXUFNI3 /(PKG_ID 0xb070018)
BOOTLOADER VERSION : I9305XXUFNI3
PMIC rev = PASS2(4)
BUCK1OUT(vdd_mif) = 0x05
BUCK3DVS1(vdd_int) = 0x20
cardtype: 0x00000007
SB_MMC_HS_52MHZ_1_8V_3V_IO
mmc->card_caps: 0x00000311
mmc->host_caps: 0x00000311
[mmc] capacity = 30777344
MODEL_NAME:{{GT-I9305}}
eMMC_SERIAL_NUMBER:{{1501004D4147344642F74A00ABD19F03}}
- read_bl1
pit_check_signature (PIT) valid.
initialize_ddi_data: usable! (4:0xe)
[RPMB] emmc_rpmb_open:
Get DATA success.
[RPMB] emmc_rpmb_close:
initialize_rpmb_data: usable! (GT-I9305:VERSION_-+A3)
PARAM ENV VERSION: v1.0..
set_charger_current: chg curr(3f), in curr(17)
set_charger_state: buck(1), chg(1), reg(0x05)
microusb_get_attached_device: STATUS1:0x3f, 2:0x00
set_auto_current: ta_state(0), curr(700)
init_fuelgauge: fuelgauge power ok
init_fuelgauge: POR status
fuelgauge_por: POR start: vcell(3975), vfocv(4026), soc(79)
fuelgauge_por: update SDI M0 parameter
fuelgauge_por: RCOMP(0x0063), TEMPCO(0x0930)
fuelgauge_por: POR finish: vcell(3977), vfocv(4085), soc(73)
get_table_soc: vcell(3976) is caculated to t-soc(75.735)
init_fuelgauge: start: vcell(3976), vfocv(4081), soc(73), table soc(75)
init_fuelgauge: finish: vcell(3976), vfocv(4081), soc(73), table soc(75)
init_microusb_ic: before MUIC: CDETCTRL:0x2d
init_microusb_ic: after MUIC: CDETCTRL:0x2d
init_microusb_ic: MUIC: CONTROL1:0x00
init_microusb_ic: MUIC: CONTROL1:0x00
init_microusb_ic: MUIC: CONTROL2:0x3b
init_microusb_ic: MUIC: CONTROL2:0x3b
PMIC_ID = 0x02
PMIC_IRQSRC = 0x00
PMIC_IRQ1 = 0x02
PMIC_IRQ2 = 0x00
PMIC_IRQ1M = 0xff
PMIC_IRQ2M = 0xff
PMIC_STATUS1 = 0x13
PMIC_STATUS2 = 0x00
PMIC_PWRON = 0x01
PMIC_RTCINT = 0x11
PMIC_RTCINTM = 0x3f
s5p_check_keypad: 0x100000
s5p_check_reboot_mode: INFORM3 = 0 ... skip
s5p_check_upload: MAGIC(0xc1d0c0d6), RST_STAT(0x10000)
microusb_get_attached_device: STATUS1:0x3f, 2:0x00
s5p_check_download: 0
microusb_get_attached_device: STATUS1:0x3f, 2:0x00
check_pm_status: charger is not detected
check_pm_status: voltage(3978) is ok
cmu_div:1, div:7, src_clk:800000000, pixel_clk:38102400
s5p_dsim_display_config: VIDEO MODE
a2, 60, 90,
<start_checksum:481>CHECKSUM_HEADER_SECTOR :4096
<start_checksum:483>offset:50, size:6296
<start_checksum:485>CHECKSUM_HEADER_INFO : NeedChecksum:0 PartNo:20
Not Need Movinand Checksum
Movinand Checksum Confirmation Pass
[mobi_drv] add: 0x43e52500, size: 3933
MobiCore INIT response = 0
MobiCore RTM has initialized!
MobiCore IDLE flag = 0
MobiCore driver address 43e52500, size = 3933
MobiCore RTM Notified back!
MobiCore Driver loaded and RTM IDLE!
MobiCore RTM has been uninitialized!
load_kernel: loading boot image from 106496..
Verify_Binary_Signature: failed.
pit_check_signature (BOOT) invalid.
Set invalid sign flag
No need to update kernel type.
SMC Num = 0x83000001
mobismc success!!! [ret = 0]
[s5p_check_sboot_version_rpmb]cur_version:VERSION_-+A3, rpmb_version:VERSION_-+A3
rpmb_version:51, cur_version:51
ATAG_CORE: 5 54410001 0 0 0
ATAG_MEM: 4 54410002 20000000 40000000
ATAG_MEM: 4 54410002 20000000 60000000
ATAG_MEM: 4 54410002 20000000 80000000
ATAG_MEM: 4 54410002 1FC00000 A0000000
ATAG_SERIAL: 4 54410006 42f74a00 abd19f03
ATAG_INITRD2: 4 54420005 42000000 17b548
ATAG_REVISION: 3 54410007 2
check_rustproof [0]
ATAG_CMDLINE: b1 54410009 'console=ram loglevel=4 androidboot.baseband=mdm sec_debug.level=0 sec_watchdog.sec_pet=5 androidboot.debug_level=0x4f4c [email protected] [email protected] [email protected] s3cfb.bootloaderfb=0x5ec00000 lcdtype=96 consoleblank=0 lpj=3981312 vmalloc=176m oops=panic pmic_info=67 cordon=471c411f44a4d1cb9c99510ec7e578a1 connie=GT-I9305_OPEN_EUR_10e569b8255514f00b8793d908e78a26 androidboot.emmc_checksum=3 androidboot.boot_salescode= androidboot.odin_download=1 androidboot.bootloader=I9305XXUFNI3 androidboot.selinux=enforcing androidboot.warranty_bit=1 androidboot.sec_atd.tty=/dev/ttySAC2 androidboot.serialno=42f74a00abd19f03 snd_soc_core.pmdown_time=1000'
ATAG_NONE: 0 0
Starting kernel at 0x40008000...
SWITCH_SEL(3)

p.a.n said:
There is a simple solution (or hack to be more precise) to this and I believe I`ve also described it somewhere here - open the ks binary with some binary editor, find the connect string (it should be there twice) and replace it something else with the same length (I used xonnect).
This is a linker related problem, ks contains symbol connect, which replaces connect from libc (I hope it is there, if not it is some other system library), but with a totally different functionality, which causes a crash. Don`t ask me why this is happening in one environment and in other (the old one), I don`t know.
Click to expand...
Click to collapse
Thanks for hint, I know that you don't work on i9305 anymore. Isn't that connect that comes internally in ks used somewhere ? After all they had to have a reason to place an internal function like that. After you left the development, it seems that the current ks that is being used in LineageOS based roms seems to be taken from other device. The current situation is as follows: the modem crashes from time to time, ks during that crash is having issues during SAHARA protocol file transfer. I don't know whether it is the modem that causes the ks crash, or ks that causes modem crash.
rodman01 said:
Maybe this last_kmsg looks better now?
Click to expand...
Click to collapse
The pasted log contains only what happened after reboot. It shows the next boot. If you wanted to show a crash, it isn't saved. It could be truncated, because last_kmsg has limited buffer (for most of the modem issues it was just too small to show everything). You can use the methods to capture logs I posted somewhere else.

yes I noticed this too after pulling another one.
But with my current used blobs I do not have that:
Code:
<6>[ 184.685425] c0 ap2mdm_errfatal is high
anymore, but still reboots and:
Code:
<6>[ 1581.571051] c0 mdm_subsys_powerup: mdm modem restart timed out.
<0>[ 1581.571210] c0 Kernel panic - not syncing: subsystem_restart_wq_func[eac9d720]: Failed to powerup external_modem!

rodman01 said:
yes I noticed this too after pulling another one.
But with my current used blobs I do not have that:
Code:
<6>[ 184.685425] c0 ap2mdm_errfatal is high
anymore, but still reboots and:
Code:
<6>[ 1581.571051] c0 mdm_subsys_powerup: mdm modem restart timed out.
<0>[ 1581.571210] c0 Kernel panic - not syncing: subsystem_restart_wq_func[eac9d720]: Failed to powerup external_modem!
Click to expand...
Click to collapse
Still not good. Have you tried modyfing the stock ks as @p.a.n wrote ? I think that the blobs can be swapped on already installed Android, without recompiling everything. Doing adb push should work too. Something like: adb root, adb remount, adb push, reboot.

I know that this is not good.
No I haven't, I have no such editor and haven't searched for it. Have you tried that already?

rodman01 said:
I know that this is not good.
No I haven't, I have no such editor and haven't searched for it. Have you tried that already?
Click to expand...
Click to collapse
Any hex editor should be enough (for Windows you could try https://mh-nexus.de/en/hxd/ ). I haven't tried yet, I returned to stock rom.

mtr_ said:
Thanks for hint, I know that you don't work on i9305 anymore. Isn't that connect that comes internally in ks used somewhere ? After all they had to have a reason to place an internal function like that. After you left the development, it seems that the current ks that is being used in LineageOS based roms seems to be taken from other device. The current situation is as follows: the modem crashes from time to time, ks during that crash is having issues during SAHARA protocol file transfer. I don't know whether it is the modem that causes the ks crash, or ks that causes modem crash.
Click to expand...
Click to collapse
I actually do work on it, just don`t publish, since I was under impression that the official version is fine and the problem you are describing here is caused by old version of modem. I didn`t want to change it, so I solved the problem by using the KitKat RIL with the modification I mentioned.
As far as I know the connect symbol in the ks binary is used only internaly (and shouldn`t be exported at all). It seems like a simple name colision, which was handled differently in KitKat. I`ve been using the modified ks for a long time and it doesn`t seem to have any negative side effect.
I`ll try to put together all the changes against the official code I have and publish again some of my builds. LineageOS 14.1 is quite stable on my device, so I hope this will help you. I just cannnot promise, when this will be, since I am pretty bussy now (more I`ve ever been).

I am uploading at the moment a new test build, where in my logcat no at distributor error and no SIGABRT error or message is to be seen at the moment. Maybe someone is around who is willing to test it....?!?

New test build is uploaded now.
Its based on todays leos sources and nameless/crazyweasel 3.0 vendor/blobs.
Download
lineage-14.1-20170621-UNOFFICIAL-i9305-hwc.zip: https://www.androidfilehost.com/?fid=673368273298966239
Please report back about reboots and or any other error or bug.
GPS is fixed and should work now.

p.a.n said:
I actually do work on it, just don`t publish, since I was under impression that the official version is fine and the problem you are describing here is caused by old version of modem. I didn`t want to change it, so I solved the problem by using the KitKat RIL with the modification I mentioned.
Click to expand...
Click to collapse
Lucky. It seems that by doing that you avoided the RIL problems (and thus saved time ). The thing worth mentioning is that there are quite new stock releases available (I9305XXSFQ series).
rodman01 said:
New test build is uploaded now.
Its based on todays leos sources and nameless/crazyweasel 3.0 vendor/blobs.
Please report back about bootloops and or any other error or bug.
GPS is fixed and should work now.
Click to expand...
Click to collapse
Tested, unfortunately bootloops. Did you try it after a dirty flash or a clean one ?
I made a non hwc build with https://github.com/CrazyWeasel/proprietary_vendor_samsung/tree/n-3.0/i9305 and modified ks from https://github.com/p-an/android_device_samsung_i9305/blob/cm-14.1/proprietary/system/bin/ks . ks works, at_distributor doesn't whine about missing symbol, but that it can't connect to ATD.
Code:
06-22 04:24:28.916 5290 5290 V AT_Distributor_diag: can't connect to atd socket
06-22 04:24:29.046 5293 5293 V AT_Distributor_diag: ConnectToATD
I was running the build for an hour, so not long enough to tell whether the modem issue appears. 4:50 AM, time to get back to stock

I had a reboot during the night too. And now, since the last half an hour, several reboots again. So I would say, this test version is almost unusable at the moment. Did a clean flash after changing to crazyweasel blobs.