Database Develop

[DEV] Coburn's Tattoo Hacking Corner - Mount Points, Fastboot and more - Take a peek!

Before I start, can we please keep the n00bish comments away from this thread. I have experience in doing this, and if I/we find a solution to this rooting drama, I'll post a how-to. A simple "Thanks, this will keep my fingers crossed" post is all that's enough to spark a chain reaction and fuel the fire knowing that we've got a strong user base that can help us test out our hacks.
Let's get down to business, shall we?
Mount Points:
This is the list of mount points that can be retrieved by issuing a simple 'mount' command on the adb shell, while your device is in USB Debugging (Settings > Applications > Development). Or in a terminal emulator.
rootfs / rootfs ro 0 0
[X]tmpfs /dev tmpfs rw,mode=755 0 0
devpts /dev/pts devpts rw,mode=600 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
[!] tmpfs /sqlite_stmt_journals tmpfs rw,size=4096k 0 0
[!!]/dev/block/mtdblock3 /system yaffs2 ro 0 0
/dev/block/mtdblock5 /data yaffs2 rw,nosuid,nodev 0 0
/dev/block/mtdblock4 /cache yaffs2 rw,nosuid,nodev 0 0
/dev/block//vold/179:1 /sdcard vfat rw,dirsync,nosuid,nodev,noexec,uid=1000,gid=1015,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8 0 0
Click to expand...
Click to collapse
I've added [X], [!] and [!!] to point out what we can do. The one with the cross is a no-go, despite being a tmpfs (TeMPorary File System), we can't write to it, and /dev/shm doesn't exist either. /dev/shm is commonly on Linux systems, a ram drive - anything written there goes bye-byes on reboot.
The second one, /sqlite_stmt_journals, which is mounted as RW, aka Read Write. Yes, we can run shell scripts, you do 'sh myscript.sh' from a terminal emulator or the adb shell to get them to run. Surpise - No noexec (no executables) flag, we can *possibly* run some custom non-root software! Downside? Only 4MB to play with. Shoot.
The second one, is the main target. /system is where Android is held, locked up in a RO filesystem. RO is Read Only. In other words, we can look but can't touch. (Bummer.) This is where we try to get into (with superuser apk and such), but it restricts us. If we can remount this sucker RW... Well, I did try:
$ mkdir /sdcard/test && mount -t yaffs2 -o rw /dev/block/mtdblock /sdcard/test
mkdir failed for /sdcard/test, File exists
$ mount -t yaffs2 -o rw /dev/block/mtdblock3 /sdcard/test
mount -t yaffs2 -o rw /dev/block/mtdblock3 /sdcard/test
mount: Operation not permitted
$ mount -t yaffs2 -o ro /dev/block/mtdblock3 /sdcard/test
mount -t yaffs2 -o ro /dev/block/mtdblock3 /sdcard/test
mount: Operation not permitted
$
Click to expand...
Click to collapse
...But it failed. /sdcard/test was the mount point on my sdcard that I wanted it to be accessed from, so I could just simply go "bang bang bang woot! GOLD! ". But no. Silly HTC.
Teh fastboot way of life:
Power off your HTC Tattoo and hold VOL Down while pressing the End Call/Power Button to enter the bootloader menu. Let the device scan for some DIAG ramdisk images (Test/Diagnostics mode?). After that, press the back button to enter the fastboot USB menu. While there, open a command prompt (on PC), change to the path where you downloaded fastboot (you can nab the said tool by downloading modaco's superboot 1.2 zip file in a thread in this category). Replace fastboot-windows with fastboot-linux, etc.
C:\Users\Coburn\Downloads\Tattoo>fastboot-windows oem boot tattoo.superboot.img
... INFOsetup_tag addr=0xA0000100 cmdline add=0x8D05E538
INFOTAG:Ramdisk OK
INFOTAG:smi ok, size = 0
INFOTAG:hwid 0x1
INFOTAG:skuid 0x1FC04
INFOTAG:hero panel = 0x0
INFOTAG:engineerid = 0x0
INFOMCP dual-die
INFOMCP dual-die
INFOTAG:mono-die = 0x0
INFODevice CID is not super CID
INFOCID is VODAP001
INFOsetting.cid::VODAP001
INFOserial number: HT99SLG03779
INFOcommandline from head: no_console_suspend=1 console=null
INFOcommand line length =404
INFOactive commandline: board_bahamas.disable_uart3=0 board_baha
INFOmas.usb_h2w_sw=0 board_bahamas.disable_sdcard=0 diag.enabled
INFO=0 board_bahamas.debug_uart=0 smisize=0 androidboot.baseban
INFOd=3.35.07.20 androidboot.cid=VODAP001 androidboot.carrier=VO
INFODA-UK androidboot.mid=CLIC10000 androidboot.keycaps=qwerty a
INFOndroidboot.mode=normal androidboot.serialno=HT99SLG03779 and
INFOroidboot.bootloader=0.52.0001 no_console_suspend=1 console=n
INFOull
INFOaARM_Partion[0].name=misc
INFOaARM_Partion[1].name=recovery
INFOaARM_Partion[2].name=boot
INFOaARM_Partion[3].name=system
INFOaARM_Partion[4].name=cache
INFOaARM_Partion[5].name=userdata
INFOpartition number=6
INFOValid partition num=6
INFO0
INFO0
INFO69466957
INFO69784520
INFO69007473
INFO7473
INFO0
INFO0
INFO0
INFO0
INFO0
INFO0
[....]
FAILED (status read failed (Too many links))
Click to expand...
Click to collapse
Oh my! Look at that! Did I just get a kernel parameter dump?! I tried the oem boot method using paul's superboot boot.img, and that's the data that it spat back. When it rebooted, it did the vibration like it would do on a cold boot. There was a lot of INFO0s though... Then it died with "Too many links". Aww. A Misc Partition?! WHAT?! Who knows what's there... (HTC, what are you hiding from us that you shouldn't be?)
Also, if we can force a custom kernel parameter with the "fastboot -c <something to make kernel remount system rw> oem boot" command, we may have a idea.
reboot-bootloader doesn't seem to work... "FAILED: remote (not allow)."
See below:
usage: fastboot [ <option> ] <command>
commands:
update <filename> reflash device from update.zip
flashall flash boot + recovery + system
flash <partition> [ <filename> ] write a file to a flash partition
erase <partition> erase a flash partition
getvar <variable> display a bootloader variable
boot <kernel> [ <ramdisk> ] download and boot kernel
flash:raw boot <kernel> [ <ramdisk> ] create bootimage and flash it
devices list all connected devices
reboot reboot device normally
reboot-bootloader reboot device into bootloader
options:
-w erase userdata and cache
-s <serial number> specify device serial number
-p <product> specify product name
-c <cmdline> override kernel commandline
-i <vendor id> specify a custom USB vendor id
Click to expand...
Click to collapse
I'm tapped. I hope this helps us in any way, it took about an hour to type (and copy/paste from CMD on Windows 7).
Remember: It's our phone, not theirs. We're breaking free - if Android is open source, why isn't the hardware?
Cheers (and please don't forget to buy me a coffee! ),
Coburn64.

Thanks coburn and f..k HTC

Good investigative work!
One point tho...
Coburn64 said:
The second one, /sqlite_stmt_journals, which is mounted as RW, aka Read Write. Yes, we can run shell scripts, you do 'sh myscript.sh' from a terminal emulator or the adb shell to get them to run. Surpise - No noexec (no executables) flag, we can *possibly* run some custom non-root software! Downside? Only 4MB to play with. Shoot.
Click to expand...
Click to collapse
What does this allow that we can't already do on /data? We can already push executables to /data/local and chmod and execute them... I believe this approach has already been tried for trying asroot2, try3 etc. exploits and the like.
The Tattoo seems pretty tight (altho of course nothing is impenetrable), our best bet is likely to be a leak of a S-OFF bootloader or an as yet unpatched kernel exploit?
P

List of options for "fastboot oem":
Code:
$ ./fastboot.exe oem h
... INFOcommand list
INFOkeytest
INFOheap
INFOboot
INFOreset
INFOpowerdown
INFOrebootRUU
INFOenableqxdm
INFOrtask
INFOtask
OKAY
rebootRUU is particulary usefull, it enables RUU mode without having to go through "adb shell reboot oem-78".

@modaco: Every time I tried to write something in /data/local, I kept getting the message "Permission Denied" like I didn't have write permissions or anything. How did you manage to do this?
@mainfram3: Nice work! I know 'fastboot oem boot' reboots the phone to flashed ROM (even if you try to force a custom image down it's throat) but this is rather interesting.
I wonder what 'fastboot oem enableqxdm' does? I'll try it out tonight...
EDIT: Looking at some exploits, there's a 2.4/2.6 kernel "sock_sendpage() NULL pointer dereference" exploit here on milw0rm.com. Does anyone know what kernel source version on HTC's Dev site is?

enable qxdm enables support for the Qualcomm qxdm debug tool.
Hmmm, like I say, I don't have a tattoo yet, but you can normally write to /data/local. Strange!
P

Coburn64 said:
EDIT: Looking at some exploits, there's a 2.4/2.6 kernel "sock_sendpage() NULL pointer dereference" exploit here on milw0rm.com. Does anyone know what kernel source version on HTC's Dev site is?
Click to expand...
Click to collapse
That's a very nice find! From the source, Linux kernel versions from 2.4.4 to 2.4.37.4, and from 2.6.0 to 2.6.30.4 are vulnerable. Our Tattoos are running 2.6.29
We need a skilled kernel developer to port this to the Android, since the exploit relies on low level assembly code :S

mainfram3 said:
That's a very nice find! From the source, Linux kernel versions from 2.4.4 to 2.4.37.4, and from 2.6.0 to 2.6.30.4 are vulnerable. Our Tattoos are running 2.6.29
We need a skilled kernel developer to port this to the Android, since the exploit relies on low level assembly code :S
Click to expand...
Click to collapse
Confirmed, we're running 2.6.29 on the offical ROMs. This looks promising.

mainfram3 said:
That's a very nice find! From the source, Linux kernel versions from 2.4.4 to 2.4.37.4, and from 2.6.0 to 2.6.30.4 are vulnerable. Our Tattoos are running 2.6.29
We need a skilled kernel developer to port this to the Android, since the exploit relies on low level assembly code :S
Click to expand...
Click to collapse
I wrote to author of FlashRec. Waiting for answer)

5[Strogino] said:
I wrote to author of FlashRec. Waiting for answer)
Click to expand...
Click to collapse
Awesome. What's flashrec anyway?
I was feeling adventous and decided to try some other rooting attempts that have succeeded on other phones. The fun thing was, I could get so close to the finishing line, when the Tattoo would kill the process (asroot2, try3, etc).
Damn. However, we can't give up - the goal is just in sight, we'll get there - we need to reroute the plan.

Coburn64 said:
Awesome. What's flashrec anyway?
I was feeling adventous and decided to try some other rooting attempts that have succeeded on other phones. The fun thing was, I could get so close to the finishing line, when the Tattoo would kill the process (asroot2, try3, etc).
Damn. However, we can't give up - the goal is just in sight, we'll get there - we need to reroute the plan.
Click to expand...
Click to collapse
FlashRec it's application for HTC Magic with exploit inside, to install custom recovery on systems with old Cupcake ROMs.
http://zenthought.org/content/project/flashrec
When HTC closed down a hole, that flashrec has been used, it become out-of-use
But mainfram3 found a new hope. Not only Tattoo users, Magic users (who stucked at new Hboot 1.76.00XX) have this hope too)

5[Strogino] said:
But mainfram3 found a new hope.
Click to expand...
Click to collapse
You meant Coburn64
And also let's not forget Droid Eris users, they're stuck in the same place we are, and they seem to be a much larger group.

this is personal now!!
i know that they just have added support for the sprint hero in flashrec i think it's on version 1.4 now!
all we need is just to find a small hole in the system making us able to write directly to the device and passing all the security sh*t
i have been in contact with htc tech center but have not been able to come through yet
i will request a eng S-off and matching radio!
i will also take take a look at the exploit code for the 2.6.29 kernel
I really hope we will get this working as i already have made custom ROM and recovery.img for it! hehe...

/data/local is writable, so is /sqlite_stmt_journals. The latter is restricted to 4MB, while the first has a lot of space (the rest of the /data partition).
Oh, and I can write to the data/local directory, I have to use adb push to get files on there.
Oddly enough, it allowed me to install a Hero super user APK on my Tattoo. Now, this is getting fun. Could someone disguise asroot2 or something inside an app, package it up as a APK and get android to install it?
I tried the asroot2, try3 and such but I got:
[1] Killed /data/local/asroot2
Click to expand...
Click to collapse
...like there's some watchdog feature inside the kernel or something. :-/

UPDATE: I'm working on a busybox hack for the tattoo. The aim of this is to get busybox installed on the device, so I can dump the NAND chip partitions and get that SPL.
Fingers crossed, and we also have found the debugging ROM for the Tattoo! So yeah, hehe...

Coburn64 said:
UPDATE: I'm working on a busybox hack for the tattoo. The aim of this is to get busybox installed on the device, so I can dump the NAND chip partitions and get that SPL.
Fingers crossed, and we also have found the debugging ROM for the Tattoo! So yeah, hehe...
Click to expand...
Click to collapse
Respect!! Hope for success, thanks for your effort

Thank you for your hard work!
I thought the rooting of tattoo died when benham ceased to exist in another tattoo-related forum and now i stumble upon this!
Crossing fingers!^^

Musenkishi said:
Thank you for your hard work!
I thought the rooting of tattoo died when benham ceased to exist in another tattoo-related forum and now i stumble upon this!
Crossing fingers!^^
Click to expand...
Click to collapse
Heh.
BUMP: My Busybox Hack is now live! Get it and install the sucker on your phone!

[Q] What about swap in the Milestone?

Hi guys,
I'm a milestone owner, and very happy with this device, I've upgraded it with 1,1ghz ULV module, memhack, busybox and JIT and it's a lighting, but here is a question that I have:
I'm a linux user so I started to "play" with the busybox addon of the terminal (straight on the device), I am also a maemo user where the swap file was usual to create on the sd to make the device more usable;
Now, how about the milestone? Using the swapper app in the market, it seems to not work (using "busybox free"in the terminal doesn't show me any swap) so how to enable a swap file or partition on the milestone? I think it will help a lot for the memory hungry systems, themes, and on developing roms linke the Dexter's froyo and sense mods (which lacks on the ram front)
Have anyone managed to have swap to work on the milestone? or Is out there any guide to do it?

This sounds like an excellent idea. As I am also a linux (Ubuntu 10.04) user too, having a swap "partition" on your Milestone will give "memory hungry" applications exactly what the need.
Will be watching this Thread!

Yeah, my question is about the fact that other phones (i heard about spica,dream,g1) have this feature, but the common command on linux/maemo does not work :/
Hope there is a solution :-(

So guys, the problem is in the kernel I frear...
using busybox, I've managed to create a small 128mb partition, and also a. Swap file (to test), but the function
"Swapon" says it's" not implemented" so where is the origin of the pWow thats strange that nobody tried ;-( ok I will try to find a solution and I will report back what I find. Hope to have skme help lol xD
Edit:
so" not implemented" is in the swapper2 application; doind it in the terminal these are the results:
export PATH=/data/local/bin:$PATH
$ su
# busybox swapon
BusyBox v6905964.73458437589.3945345.RELEASE_FROM_FUTURE (2010-04-10 21:43:08 MSD) multi-call binary.
Usage: swapon [-a] [-p PRI] [DEVICE]
Start swapping on DEVICE
Options:
-a Start swapping on all swap devices
-p PRI Set swap device priority
# busybox swapon -a
swapon: /etc/fstab: No such file or directory
# busybox swapon -a /sdcard
swapon: /etc/fstab: No such file or directory
# sudo gedit /etc/fstab
sudo: not found
# gedit /etc/fstab
gedit: not found
# vi /etc/fsteb
vi: not found
So thats it....what is this fstab file?? I know its about partition table or something like that, but why we lack it? We have to figure how to implement it...maybe in that way the swap can be set via busybox... help :-(
#roblem??? :-( help!

Looks like someone has figured it out!
Please someone try and report back
http://www.droidforums.net/forum/bl...built-source-fast-working-3dlauncher-220.html

kreat1ve said:
Looks like someone has figured it out!
Please someone try and report back
http://www.droidforums.net/forum/bl...built-source-fast-working-3dlauncher-220.html
Click to expand...
Click to collapse
nice find keat1ve ... perhaps i will try out in the evening. if my wife gets me some spare time ... the instructions at droidforums is not really correct for milestone. it has to be adapted a little bit!

Will try right now, I will tell you ^_^
Thx a lot!!

yes it can and has been done. swap adds working memory true, but all those writing/reading to/from a partition/file in your sdcard WILL slow down your phone and shorten your sd card's life. its your choice eventually: either you want more memory, or you want speed. you cant have both.
yantz

@kreat1ve
this guide about the partitioning with adb does not work with milestone, I will try to create a swap partition with partition magic and then use droid swapper to enable it... let's hope xD

I dont wonna sound negative or anything but this is for the droid which is completly open which probably has a customized kernel with swap enabled, while our milestone is locked and does not have swap enabled in its kernel . Anyway i dont think trying this will hurt so i hope it works out

Following the guide, does not gave me results, but I asked to he one that posted it for more info;
meanwhile I've managed to create a .swap file and mkswap it using busybox, these are the results:
export PATH=/data/local/bin:$PATH
$ $ su
# dd if=/dev/zero of=/sdcard/.swap bs=1024 count=262144
262144+0 records in
262144+0 records out
268435456 bytes transferred in 57.985 secs (4629394 bytes/sec)
# mkswap/sdcard/.swap
mkswap/sdcard/.swap: not found
# mkswap /sdcard/.swap
mkswap: not found
# swapon /sdcard/.swap
swapon: not found
# busybox mkswap /sdcard/.swap
Setting up swapspace version 1, size = 268431360 bytes
UUID=16e9c236-61d9-49ec-a023-c529adb3109c
# busybox swapon /sdcard/.swap
swapon: /sdcard/.swap: Function not implemented
# busybox swapon -a
swapon: can't stat '/dev/block/mmcblk0p3': No such file or directory
# busybox free
total used free shared buffers
Mem: 230500 227516 2984 0 32
Swap: 0 0 0
Total: 230500 227516 2984
#
so the problem is that swapon does not recognize the file (but manually puting fstab in /etc and a file 06userinit within /etc/init.d/ containing
Code:
#!/system/bin/sh
swapon -a) but probably a partition of the sdcard may be recognized....now the problem form me...
I use windows 7 64bit...how the hell can I partition my sdcard with a swap partition?? LOL! XD
This is what blocks me...lol

try here
or
here

kassy_ok said:
try here
or
here
Click to expand...
Click to collapse
sadly the problem is in the kernel...."not supported" is the result of every swapon command...have to wait an official support or a custom kernel in 2nd boot...let's hope and wait...

Question: can't it be solved by creating a module supporting swap-filesystem?

TheSSJ said:
Question: can't it be solved by creating a module supporting swap-filesystem?
Click to expand...
Click to collapse
I'm wondering if someone has created such module?

I don`t know~~

alncool said:
I'm wondering if someone has created such module?
Click to expand...
Click to collapse
It seems that creating such a module is very hard. See the page cyanogenmod for milestone here :
http://code.google.com/p/cyanogenmo...ID Type Status Priority Version Owner Summary
I suggest everyone to star the feature. Maybe it will be developped by someone ... who knows !

So my friends... anyone could avance on this thread?
Sounds promising... but i also get stuck when enabling the swapon...
Anyone?
Cya

Hi!
Now, when we have official Froyo for MM with 2.6.32.9 kernel, can anyone create SWAP module for this kernel?

kilabdg said:
Hi!
Now, when we have official Froyo for MM with 2.6.32.9 kernel, can anyone create SWAP module for this kernel?
Click to expand...
Click to collapse
unfortunately no. Swap is not a module in Linux kernel, it changes the kernel's internal behaviour, so you cannot compile as swap=m, it is definitely y or n.

[DEV][BUILD0 - PREALPHA]HW TEST: OMAPZoom AOSP 4.1.2 JZO54K

Hi Folks, Not to be left out of all the 4.1.2 Fun, Here's a little teaser of what's to come!
{
"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"
}
ROM STATUS: BUILD0 PREALPHA - OFFLINE - AWAITING UPDATE
Click to expand...
Click to collapse
NOTE: SEE THIS POST FOR THE LATEST DETAILED ROM INFORMATION
Click to expand...
Click to collapse
NOTE: SEE THIS POST FOR THE LATEST DEVELOPMENT INFORMATION
Click to expand...
Click to collapse
Now Go! We Make Rom Now!
NOTES: ETA? DON'T EVEN ASK! :laugh:

Great Work !

[BUILD0]Touchscreen, OpenGLES and CWM Test!
Hi Folks.
Feeling Adventurous? Then You Might want to have a quick go this OmapZoom AOSP 4.1.2 JZO54K That I've prepared It's in it very early stages but It would be help if some folks could give it blast and let me know if the TouchScreen functionality is working as my touchscreen hasn't worked for a long time and as such it is some I can't test. If the lastest version of Android wasn't enough of a draw, This rom also includes the work I've done with CWM Recovery.
BUILD INFORMATION AND DETAILS
What's BUILD0?
Good Question, Build0 ( Build Zero ) is pre-alpha release aimed at testing specific hardware functionality and software features.
Hardware - Working
Touchscreen (?!?) - The Drivers are installed so it "should" just work
Archos 3G / Huawei + Others 3G Dongles - The Hardware will be recognized but there is nothing implemented in Android user land as yet.
Hardware - Not Working
Everything else! - To be implemented in future builds[/QUOTE]
Software Information
The main software/driver focus of this build was getting the PowerVR Drivers to function to enable HW Acceleration. This has been achieved not only using the stock kernel modules ( as one would expect ) but also on test custom kernel builds. This is an area along with the Camera that has proved problematic when attempting previous ports and is something I wanted to solve early on.
Hacking On It!
Source Code Info : See Separate Post on building and source code info [ COMING SOON ]
Kernel Version : Archos Stock 3.0.21 - This will change in the next build to use a kernel with JellyBean Specific features plus some extra treats , For anyone interested in hacking on this current build I have included all the stock kernel modules, they can be found /system/lib/modules. Of course the kernel modules for most hardware is only half the story as many devices also require a binary firmware blob which is not included but can be grabbed from the Archos 3.0.25 Firmware.
StabilityThe build seems pretty stable overall but although the incorrect battery percentage do make a it wobble a little
Clockwork Mod Recovery - I will update the CWM thread with details regarding bugs and testing etc but just to say, It's seems fully functional with very few minor issues.
Installation - Please See The Installation Instructions For Details

Installation Guide
Installation Guide
STOP! HAVE YOU TAKEN A BACKUP OF YOUR IMPORTANT DATA
Although your existing data is not touched, It is advised you backup your data directory before proceeding.
Click to expand...
Click to collapse
ALL THE USUAL DISCLAIMERS APPLY, FILES ARE PROVIDED AS-IS AND WITHOUT WARRANTY ,
ITS YOUR DEVICE, YOUR RESPONSIBILITY, I'M NOT YOUR DAD!
Click to expand...
Click to collapse
Build0 - Requirements
Archos G9 SD Version
android sdk / android debug bridge ( adb )
SDE Enabled Firmware ( unofficial or official )
common sense.
NOTE: I've only tested this using Linux , The procedure should be the same on Windows but we don't know until we try.
Assumptions
1.You know how to flash a SDE initramfs and zImage either through the Developer Menu or using kd_flasher from the adb command line,
2.You know how to boot your device into the Special Developer Edition Firmware ( SDE )
3.You have setup adb correctly a your device is listed in the adb devices list.
Build0 - Installation Steps
1. Download and unpack the cwm boot image [ Hotfile :/archosg9-jzo54k-cwmboot.7z ]
2. Download and unpack the system image [ CURRENTLY OFFLINE - AWAITING UPDATE ]
3. Flash the unpacked zImage and initramfs.cpio.lzo using the [Recovery]/[Developer Edition Menu]/[Flash Kernel and initramfs] option in Archos recovery mode.
4. Reboot Into Developer Edition ; You should now see the Familiar CWM User Interface, You should see a couple of error messages regarding mounting /cache/recovery/command and /cache/recovery/log. This is expected.
5. use adb to push the unpacked system.img to the /._ directory on the device with the following command
Code:
[B]adb push system.img /._/system.img [/B]
NOTE: The system.img is 500MB in size and it may take some time for the transfer to be completed
6. When the file transfer is complete, reboot the device either using the CWM UI or adb reboot, The device should reboot back into CWM, The previous error messages will still present, Again this is the expected behaviour.
At this point, if everything is ok you should be able the use adb shell commands. Lets check the mount points using
Code:
[B]adb shell mount[/B]
The output should be as follows
Code:
rootfs on / type rootfs (rw)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
none on /acct type cgroup (rw,relatime,cpuacct)
tmpfs on /mnt/asec type tmpfs (rw,relatime,mode=755,gid=1000)
tmpfs on /mnt/obb type tmpfs (rw,relatime,mode=755,gid=1000)
none on /dev/cpuctl type cgroup (rw,relatime,cpu)
/dev/block/mmcblk0p1 on /mnt/rawfs type rawfs (rw,relatime)
/dev/block/mmcblk0p4 on /._ type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
/dev/block/loop0 on /system type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
/sys/kernel/debug on /sys/kernel/debug type debugfs (rw,relatime)
If you see the message
Code:
- exec '/system/bin/sh' failed: No such file or directory (2) -
Then either you have not followed the instructions correctly or I've not typed them up correctly! Either way something's not right. See the troubleshooting section below for tips on how to check what's what.
7. Next we need to create a ext4 image for the cache and data partitions. This involves create an empty file with dd, loop mount the file as a block device using losetup then making the filesystem using mk2fs.ext2. Sounds like a lot of work. I thought so too, so all you need to do is run the following adb shell command
Code:
adb shell createfs
This will create a 500MB cache image and a 2GB data image. Again because of the file sizes involved this does take a couple of minutes to complete. Please be patient, when the command is completed the full output should look as follows
Code:
File System Image Creation Script - For Test Purpose Only
/dev/block/mmcblk0p4 /._
FileSystem Container /dev/block/mmcblk0p4 Mounted at /._.....
Checking Available Space.
Available Space : 5129
Creating cache image at /._/CAC With Block 500000
500000+0 records in
500000+0 records out
512000000 bytes (488.3MB) copied, 39.070434 seconds, 12.5MB/s
DD Returned 0 : Loop Mounting the raw image /._/CAC to /dev/block/loop1
Creating Ext FileSystem on /dev/block/loop1
warning: 287 blocks unused
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
125416 inodes, 499713 blocks
25000 blocks (5%) reserved for the super user
First data block=1
Maximum filesystem blocks=524288
61 block groups
8192 blocks per group, 8192 fragments per group
2056 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409
Creating data image at /._/DATA With Block 2000000
2000000+0 records in
2000000+0 records out
2048000000 bytes (1.9GB) copied, 175.243408 seconds, 11.1MB/s
DD Returned 0 : Loop Mounting the raw image /._/DATA to /dev/block/loop2
Creating Ext FileSystem on /dev/block/loop2
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
125184 inodes, 500000 blocks
25000 blocks (5%) reserved for the super user
First data block=0
Maximum filesystem blocks=4194304
16 block groups
32768 blocks per group, 32768 fragments per group
7824 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912
8. Reboot the device. The device will once a gain reboot into CWM Recovery. This time there should be no error messages. check everyhting is mounted and created correctly using
Code:
adb shell mount
The output should look as follows
Code:
rootfs on / type rootfs (rw)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
none on /acct type cgroup (rw,relatime,cpuacct)
tmpfs on /mnt/asec type tmpfs (rw,relatime,mode=755,gid=1000)
tmpfs on /mnt/obb type tmpfs (rw,relatime,mode=755,gid=1000)
none on /dev/cpuctl type cgroup (rw,relatime,cpu)
/dev/block/mmcblk0p1 on /mnt/rawfs type rawfs (rw,relatime)
/dev/block/mmcblk0p4 on /._ type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
/dev/block/loop0 on /data type ext4 (rw,nosuid,nodev,relatime,user_xattr,barrier=1)
/dev/block/loop1 on /cache type ext4 (rw,nosuid,nodev,relatime,user_xattr,barrier=1)
/dev/block/loop2 on /system type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
/sys/kernel/debug on /sys/kernel/debug type debugfs (rw,relatime)
9. Congratulations You now have Jellyean and CWM Recovery running on you device
One Last time choose "reboot system now" from the cwm menu to taste those JellyBeans!
TROUBLESHOOTING
Ok you've got problems, nothing that cannot be worked around.
Investigating
Code:
- exec '/system/bin/sh' failed: No such file or directory (2) -
If you run into this error then I means that your system.img is not present on the device or has not been mounted correctly for some reason. because of the way the device recovery is setup at the minute adb still looks for it's shell binary in /system/bin this only exists if the system is mounted. Fortunately we still have a couple of adb commands at our disposal, namely pull and push, the work around this issue you do the following [ Example uses Bash Terminal on Linux ]
Code:
adb pull /sbin/busybox
chmod +x busybox # Linux Only - Make sure busybox is still executable
adb push /system/bin/sh
You should now be able to drop into an interactive shellk using
Code:
adb shell
A further trick to make sure you have access to all the commands is to symlink the contents of /sbin to /system/bin. like so
Code:
a s "ln -s /sbin/* /system/bin"
More Troubleshooting Soon! If folks get stuck.

Development Information
It turns out, perhaps unsurprisingly that the omapzoom.org aosp repo is the one for us!
I did some light changes to the blaze_tablet device tree, which mainly involved changing the word blaze to archos .
Once again I've got the powervr drivers loading successful, because archos are using the latest version we don't have to rip them off the device as the userland binaries in the device/ti/proprietary-open.git work fine.
As this is the very first build I've scaled everything back, so what you've basically got is a booting rom to hack on. Apart from the powervr drivers everything else is untested and presumed not working. Also the kernel needs rebuilding to include tracing.
If anyone fancies hacking on this, get the source from http://omapzoom.org and the archos device tree can be found on my github. place the device files in a device/ti/archos_tablet directory.
Use the jb-mr0-release branch, I had some trouble building the development branch (jb-mr0-dev), clearly someone has committed some breaking changes.....

One more for luck

Don't you just hate it when the op does this

zImage and initramfs.cpio.lzo
I flashed the zImage and initramfs.cpio.lzo, rebooted. No CWM menu, still SDE. What should I do next, try pushing system.img anyway?
stevemp

stevemp said:
I flashed the zImage and initramfs.cpio.lzo, rebooted. No CWM menu, still SDE. What should I do next, try pushing system.img anyway?
stevemp
Click to expand...
Click to collapse
Hi There,
That's very strange. This should have replaced the existing SDE Booting Procedure, I wouldn't push the system.img quite yet
I have a couple of questions?
What Model Tablet Do You Have?
Are you running An SDE Rom Already, If so which one?
Is your SDE Official or Unofficial?
Have You Removed The Android Kernel Using the Recovery Menu Option?
Did you flash using the Recovery/Developer Edition menu option?
Are you using Windows or Linux?
Can you elaborate on "Still SDE", Do You Mean It Booted into your existing Rom?
That should be good for starters,
Thanks

trevd said:
Hi There,
That's very strange. This should have replaced the existing SDE Booting Procedure, I wouldn't push the system.img quite yet
I have a couple of questions?
What Model Tablet Do You Have?
Are you running An SDE Rom Already, If so which one?
Is your SDE Official or Unofficial?
Have You Removed The Android Kernel Using the Recovery Menu Option?
Did you flash using the Recovery/Developer Edition menu option?
Are you using Windows or Linux?
Can you elaborate on "Still SDE", Do You Mean It Booted into your existing Rom?
That should be good for starters,
Thanks
Click to expand...
Click to collapse
Archos 80 G9 OMAP 4460 1.2 Ghz 512 Mb ram [email protected]_V04
Never mind, let tablet reboot CWM menu showed up. I thought supposed to reboot into SDE.
Jelly Bean boots but touch screen not working
stevemp

stevemp said:
Archos 80 G9 OMAP 4460 1.2 Ghz 512 Mb ram [email protected]_V04
I think SDE is official, not sure how to find out.
Windows 7 64 bit.
SDE -> Developer Edition Menu -> Flash Kernel & Initramfs -> copied zImage and initramfs.cpio.lzo rebooted -> held power button and volume down -> went back to SDE -> Developer Edition Menu -> still looks the same.
stevemp
Click to expand...
Click to collapse
Ok Thanks Again for the Feedback.
I think the official SDE is watermarked! I also think we might have our wires crossed and you've misunderstood ( more likely I've not explained clearly ) Just what this is. This does NOT replace the existing Archos Recovery Menus. On technical level it is an SDE Rom which can be booted between android and recovery effectively adding an extra boot mode to SDE, This sits apart from the Archos BootMenu Stuff.
I suppose a good way to think about it is in the following structure.
Code:
Archos Boot Menu
Android
Recovery
Developer Edition -----> Android
Recovery
So You actually load the developer edition to use this recovery. Flashing and Booting these Files won't affect any other Rom/Data on the Tablet as the Partitions are self contained in there own image files. So you can easily return to [email protected] by flashing a "Classic" initramfs and kernel.
If You still can't boot into CWM You might want to have a go with the alternative flashing method using adb. It's a lot easier than all that Vol+Down Stuff.
When Booted in android, run the following commands
Code:
adb push zImage /data/local/zImage
adb push initramfs.cpio.lzo /data/local/initramfs.cpio.lzo
adb shell "kd_flasher -i /data/local/initramfs.cpio.lzo -k/data/local/zImage"
adb shell "reboot_into sde"
Thanks Again

stevemp said:
Archos 80 G9 OMAP 4460 1.2 Ghz 512 Mb ram [email protected]_V04
Never mind, let tablet reboot CWM menu showed up. I thought supposed to reboot into SDE.
stevemp
Click to expand...
Click to collapse
Beat Me Too It, See my above post.... :victory:
Oh well stands as a good explanation

Jelly Bean
Boots into Jelly Bean, touch screen not working.
Awaiting further instructions.
stevemp

stevemp said:
Boots into Jelly Bean, touch screen not working.
Awaiting further instructions.
stevemp
Click to expand...
Click to collapse
OK Thanks for the test.... To use the classic phrase, It's not you It's me , I think I'm missing some layout files, Nice to hear you got it Booted.
One piece of probably useful information I've omitted! You can boot back into CWM using adb, while booted into JellyBean use
Code:
adb reboot recovery
Recovery should be fully working, You can flash zip i.e gapps CWM-SU etc, The sdcard mount point tries to mount the external sdcard as fat32 ( for now ).
once the external sdcard is mounted you should be able to run a backup
No more instructions at the minute I'm afraid but I'll get right on it.
Once again Thanks for the Testing and Feedback, It's been very useful.

Just for Archos Gen9 SD ?
why and what kind of gen9 ?
i have 3 gen 9
8" 1ghz 16 go
10" 1.5ghz 16go
10" 1.5ghz 250go

cajl said:
Just for Archos Gen9 SD ?
why and what kind of gen9 ?
i have 3 gen 9
8" 1ghz 16 go
10" 1.5ghz 16go
10" 1.5ghz 250go
Click to expand...
Click to collapse
Should be good for all Gen9 SD's and in time HD versions as well, Can't test with HD Versions because I don't have one! :laugh:

If you want i will be testing this afternoon on the HD
and if the dl is ok

stevemp said:
Boots into Jelly Bean, touch screen not working.
Awaiting further instructions.
stevemp
Click to expand...
Click to collapse
Hi!
Touch screen driver will be ok!
I think should be ok with the curent driver from 4.0.25 !
....just let time to trevd for add this stuff! :good:

surdu_petru said:
Hi!
Touch screen driver will be ok!
I think should be ok with the curent driver from 4.0.25 !
....just let time to trevd for add this stuff! :good:
Click to expand...
Click to collapse
All ready on it. missing /system/usr/idc ( input device configurations ) , they can be pull from an existing archos rom
For those who are interested.
http://source.android.com/tech/input/input-device-configuration-files.html
http://source.android.com/tech/input/touch-devices.html
I seem to recall the wireless xbox 360 pad being added using ( i think ) this method. I'll have a quick look, I might throw that in if its not too difficult

trevd said:
All ready on it. missing /system/usr/idc ( input device configurations ) , they can be pull from an existing archos rom
For those who are interested.
http://source.android.com/tech/input/input-device-configuration-files.html
http://source.android.com/tech/input/touch-devices.html
I seem to recall the wireless xbox 360 pad being added using ( i think ) this method. I'll have a quick look, I might throw that in if its not too difficult
Click to expand...
Click to collapse
Hi!
Thanks TREVD!
A very very very good job!!! :good:
My device is it now on Service Centre for reparation ( touchscreen issue! ) for 3 , 4 week!
I can't wait to test all your stuff!
Thank's again and good luck! :good:

[MOD][P905] selinux permissive on stock kernel LTE QUALCOMM ONLY!

At first, I am not liable for any harm or damage that may happen to your device!
If you have su and didn't trigger knox, I CANNOT guarantee that running this script won't cause 0x1!
Requirements:
1) P905/viennalte/Qualcomm based model ONLY (won't work on Exynos devices. MIGHT work on other Qualcomm LTE deices from Note Pro and Tab Pro series or even S5 / Note 3 etc - feel free to repost but give credits AS THIS METHOD SEEMS TO BE COMPLETELY NEW! ) running 4.4.2 stock;
2) root access with SuperSU (using cf-root - credits to chainfire);
3) busybox installed (I do recommend this paid installer: https://play.google.com/store/apps/details?id=stericson.busybox.donate , MOST PROBABLY free version will be more than enough, too, but I haven't tested it as I have license...)
4) Android Terminal Emulator installed ( free at: https://play.google.com/store/apps/details?id=jackpal.androidterm )
Installation:
1) download file permissive_via_kmem.sh using below link and put it in the root of internal memory (so it will be placed in: /sdcard/permissive_via_kmem.sh)
2) run Android Terminal Emulator
3) at command line, type:
Code:
su -c /sdcard/permissive_via_kmem.sh
(give it an access if requested)
4) voila.
Alternative: if u have init.d support just put the file in /system/etc/init.d to make permissive on every boot
Additional info for advanced users:
1) samsung decided to compile kernels for newer 4.4.2 roms with a flag (a kernel variable) forcing selinux enforcing mode
2) as kernel itself cannot be modified after compiled, it was impossible to set permissive mode using shell or even by repacking kernel's ramdisk, at least on Qualcomm LTE devices
3) custom kernel can do the job, but samsung's sources are broken, at least for P905, and it refuses to boot at all...
4) however, there is a workaround...
5) we cannot change kernel binary to run with different flag out of the box BUT we can obtain it's placement (address) directly in kernel memory space on running kernel and write different value DIRECTLY into the memory, hacking the kernel to make it think that the flag was different
6) for this purpose i believe we have to disable restrictions to access kernel pointers (done via sysctl)...
7) ...then read the output of /proc/kallsyms which will provide a list of all kernel variables along with their addresses in kernel memory space...
8) ...filter out a boolean variable selinux_enforcing which is responsible for all the troubles...
9) ...and write raw 00 byte into the address where the variable value is stored, via /dev/kmem.
Download:
http://www12.zippyshare.com/v/89625246/file.html

Noob question
Could you explain to a newb what this does?
I've read this article on it and still can't fathom what benefits I'd have from changing it to permissive: http://www.androidpolice.com/2013/10/31/kitkat-feature-spotlight-selinux-defaults-to-enforcing-rather-than-permissive-other-new-security-features/
And thank you.

cavkic said:
Could you explain to a newb what this does?
I've read this article on it and still can't fathom what benefits I'd have from changing it to permissive: http://www.androidpolice.com/2013/10/31/kitkat-feature-spotlight-selinux-defaults-to-enforcing-rather-than-permissive-other-new-security-features/
And thank you.
Click to expand...
Click to collapse
Check this

Well, if i'd try to express it in a simple way, from the user's point of view permissive mode is equal to selinux turned off at all, except it is logging (and only logging...) all the warnings caused by security violations, which would result in an error in enforcing mode. Permissive mode let you avoid strict security policies defined by manufacturer (and NSA - yeah, the real spies - which is maintaining general selinux rules), but also gives the possibility of establishing possible issues which may appear after switching to "really secure" enforcing mode.
And if you are asking about the exact, disturbing (ofc if security is not your main priority...) effects of enforcing mode that may affect end-users, we may start from: troubles with write-access to some (mostly external, but i have personally fought with with an issue of non-writeable internal sdcard, too) medias (well, to be honest, I do hope that my discover will help in building 100% working custom recovery...), troubles with non-working system mods resulting from bad selinux file labels, troubles with wiping partitions (ie. wiping cache or even swapping modded system lib sometimes has to be followed by triggering restorecon command on that filesystem (restore selinux context), which is leading to ie. losing root access, which may be fixed by flashing supersu again, etc etc, non working apps (especially related to modifying sensitive system parameters or resources), unchangeable system properties, unreachable functionalities, blah blah blah.... This topic had been widely discussed on xda and over the internet.
On the contrary, if you like to use your device as-is and you're not interested in modding/tweaking it, you will probably not need this mod, as you will gain nothing - but lose a little bit of security... For heavy modders, although, it's a must-have.
Btw can anyone confirm if it's working? I assume that I was looking for solution for some time, made some other changes to the environment meanwhile, so I cannot be 100% sure that above script alone is absolutely enough (but in theory it should...), however, even if it is not, it's just a matter of 1-2 days to figure out what additional, previously-well-known steps, such as running "setenforce 0", may be required in addition.
And as a brief summary: YES, my selinux is now really Permissive, both when running getenforce command and in system settings!
Wysłane z mojego SM-P905 przy użyciu Tapatalka

After following all steps getenforce still returns enforcing and in system it also shows enforcing.
If I try running setenforce I get permission denied.

Ok, can you enter:
Code:
su
printf '\x00' | su -c dd of=/dev/kmem seek=$( printf '%d\n' '0x'`cat /proc/kallsyms | grep ".*\ selinux\_enforcing" | cut -f 1 -d " "` ) bs=1 count=1 conv=notrunc
into terminal and tell me what's the output and/or the enforcing state??
Wysłane z mojego SM-P905 przy użyciu Tapatalka

As requested
Output:
/dev/kmem cannot open for write: permission denied
getenforce still returns Enforcing
[email protected]:/ $ cd /dev
[email protected]:/dev $ ls *mem*
ashmem
kmem: Permission denied
mem: Permission denied
ramdump_audio-ocmem
ramdump_smem
smem_log
1|[email protected]:/dev $
Same result in # mode

RaSand said:
As requested
Output:
/dev/kmem cannot open for write: permission denied
getenforce still returns Enforcing
[email protected]:/ $ cd /dev
[email protected]:/dev $ ls *mem*
ashmem
kmem: Permission denied
mem: Permission denied
ramdump_audio-ocmem
ramdump_smem
smem_log
1|[email protected]:/dev $
Same result in # mode
Click to expand...
Click to collapse
I assume that you have ran the command as root (ie didnt forget about 'su' before the main command)...? Your logs show non-root mode, but ur saying about '#' mode at the end, guess you mean su... Assume that all we do here requires root shell first to be opened, and the output even if similiar, may vary in details between non-root and root mode, so don't forget to get privileges before running anything below...
If so, I guess default policy prevents writing to /dev/kmem in enforcing mode by setting its selinux context to a special one, dedicated only for /dev/kmem and /dev/mem.The working solution is to repack kernel (not same, but, indeed, a lot easier, than recompile - changes won't affect the kernel binary code, but it's ramdisk part, only) with modified policy defaults, which will treat /dev/kmem as a genuine device, not a "sensitive" one. I can provide the one repacked for my own purposes, however, befoure such an intrusion we may want to try other solutions I can think of (again, cannot test it as I ve added many different mods in many different places, I would need to go back to stock to test it, but I need my device 100% steady and configured for my job this week. Hope you'll help me in solving this out, it shouldnt take long...).
Notice: Again, ALL BELOW COMMANDS SHOULD BE RUN IN ROOT MODE. That means you shall enter "su" command alone before trying any of those steps, and the Terminal will switch to a root shell, which is confirmed by switching the last sign in the prompt from '$' to '#'.
Notice 2: if it is written - after some steps - to try switching to permissive mode again, it should be done by running the command from MY PREVIOUS POST only, as it is equal to longer version from the script, just closed within shorter one-liner command... the command should change the mode to permissive itself and no further steps are needed.
1) run following:
Code:
ls -lZ /dev/kmem >/sdcard/info.txt
and paste the exact output (which has been saved at /sdcard/info.txt) here so I can gather further info about issue. Dont make a test of the main script here as nothing has been changed. After that...
2) we can try to set different context (a default one for dev files) manually. Again, it might be impossible as of selinux policy, but worth trying. Enter as root:
Code:
busybox mount -o rw,remount /
chcon u:object_r:device:s0 /dev/kmem
if error, paste it here. If no error, test if permissive mode script is working.
3) we can try to modify selinux policy in temporary ramdisk file to prevent giving /dev/kmem a special context and then restore context of whole /dev to it's "defaults", however, those "defaults" would be our modified ones. Possible issues: not sure if the restoring default context will make use of modified policy or would it use only the policy loaded on-boot (and as the ramdisk is temporary, policy modifications will disappear too within reboot). After getting root, enter:
Code:
busybox mount -o rw,remount /
sed -i "s:^.*\/dev\/[k]*mem.*$::g" /file_contexts
setprop selinux.reload_policy 1
restorecon -R /dev >/dev/null 2>&1
after that - if no errors - check if the switching works.
4) if none of the above is working, guess we'll need to repack stock kernel with a ramdisk content modified in the same way as in step 3. When embedded in kernel, the changes to the policy rules will be seen every boot and they will affect /dev/kmem in a persistent manner. This will let you write to it for sure. I will provide a ready repacked boot.img, so we can avoid repacking at all. This however is not a very satisfying solution, as my goal was not only to achieve permissive mode, but to achieve it without any changes (even if they are much less disturbing than recompiling kernel from source) to boot partition. But hey, first check out on-the-fly solutions above, as they are much less intrusive to a device, coz won't require reflashing kernel/boot partition.
EDIT: remount command added to step 2, repeat if you had error with changing the context.
Thanks for your effort.

[email protected]:/ $ su
[email protected]:/ # ls -lZ /dev/kmem >/sdcard/info.txt
/dev/kmem: Permission denied
1|[email protected]:/ #
info.txt is empty
chcon: Could not label /dev/kmem with ubject_r:device:s0: Permission denied
2|[email protected]:/ #
waiting for code for 3)
same result in step 2 with added remount
---------- Post added at 04:55 PM ---------- Previous post was at 04:30 PM ----------
It swallowed all commands in 3) BUT re running the script didn't change anything. After please wait.... done it still says selinux is set to Enforcing. Sorry.
getenforce returns enforcing
setenforce to 0 or Permissive doesn't change a bit.
seems it has to be done the hard way
better luck next time

RaSand said:
[email protected]:/ $ su
[email protected]:/ # ls -lZ /dev/kmem >/sdcard/info.txt
/dev/kmem: Permission denied
1|[email protected]:/ #
info.txt is empty
chcon: Could not label /dev/kmem with ubject_r:device:s0: Permission denied
2|[email protected]:/ #
waiting for code for 3)
same result in step 2 with added remount
---------- Post added at 04:55 PM ---------- Previous post was at 04:30 PM ----------
It swallowed all commands in 3) BUT re running the script didn't change anything. After please wait.... done it still says selinux is set to Enforcing. Sorry.
getenforce returns enforcing
setenforce to 0 or Permissive doesn't change a bit.
seems it has to be done the hard way
better luck next time
Click to expand...
Click to collapse
Your errors are quite strange, as it seems that you don't even have permissions to check the simple content of a directory...
Try to run commands from step 1 - 3 again, but with slight modifications (below), so theyll run in separate, undoubtly-rooted shell... Test also with modded command (you can try it alone before in the very beginning...)
Also: please run 2 and 3 in reversed order, ie. first step 3 and if not working, without rebooting, run step 2...
Btw are you using SuperSu 1.99? If no - after trying all below options, upgrade SuperSu from the Play Store, run it to update the binaries, reboot. check commands again. If still the same, install update to /system using option from its menu (it will do some cleanup and ask to reboot, after that you have to run option again, this time it will perform installation, after which you have to reboot again - after boot run SuperSu and check if the option is greyed out, if yes, everything went fine) and check all steps once again...
Here we go.
Main command:
Code:
su -c printf '\x00' | dd of=/dev/kmem seek=$( printf '%d\n' '0x'`cat /proc/kallsyms | grep ".*\ selinux\_enforcing" | cut -f 1 -d " "` ) bs=1 count=1 conv=notrunc
Step 1 v2:
Code:
su -c ls -lZ /dev | grep kmem >/sdcard/info.txt
Step 2 v2 (formerly step 3 ):
Code:
su -c busybox mount -o rw,remount /
su -c sed -i "s:^.*\/dev\/[k]*mem.*$::g" /file_contexts
su -c setprop selinux.reload_policy 1
sleep 3
su -c restorecon -R /dev
Notice: I am not sure if setprop selinux.reload_policy 1 is enough to force sammy's android (which is a really giant b***ch to hack when compared to any other android...) to reload the policy, this may really work, but only if the policy is reloaded on-line using new defaults. Later I will look for that information...
Step 3 v2 (formerly step 2 - please run directly after step 2v2, without rebooting...):
Code:
su -c busybox mount -o rw,remount /
su -c chcon u:object_r:device:s0 /dev/kmem
Notice: step 3 - when ran fine - might now print some errors that it cant access some stuff in /dev - this is absolutely ok. But formerly I disabled the output at all (not to confuse you with some strange errors), but it resulted in lack of possibility to find out if the command ran AT ALL or if it escaped because of no permissions on the very beginning.

Before we go on here let's get a few things out of the way.
1) please advise where i should get supersu 1.99 from. I'm on 1.94 and in my country (GE) there is no newer version available in the play store.
2) first thing I usually do when I start the terminal is type "su"
3) I'm an old man. So please be patient
that said let's give it another try
---------- Post added at 06:42 PM ---------- Previous post was at 06:11 PM ----------
This is starting to test my temper. I guess I will put the steps into files and run them with gscript. Hang on. Might take some time
---------- Post added at 07:30 PM ---------- Previous post was at 06:42 PM ----------
Guess I had it for today. No changes whatsoever.
Here is what I did
installed supersu to /system. Option is greyed out now
made a new script for every box of code. Main and step 1 to 3
Made copies and added some echo lines so I could see if scripts work and/or finish correctly
executed scripts with gscript in the given order
No echo in step 1 to 3
ran original code
same result.
don't know what else to try.
sorry

RaSand said:
Before we go on here let's get a few things out of the way.
1) please advise where i should get supersu 1.99 from. I'm on 1.94 and in my country (GE) there is no newer version available in the play store.
2) first thing I usually do when I start the terminal is type "su"
3) I'm an old man. So please be patient
that said let's give it another try
---------- Post added at 06:42 PM ---------- Previous post was at 06:11 PM ----------
This is starting to test my temper. I guess I will put the steps into files and run them with gscript. Hang on. Might take some time
---------- Post added at 07:30 PM ---------- Previous post was at 06:42 PM ----------
Guess I had it for today. No changes whatsoever.
Here is what I did
installed supersu to /system. Option is greyed out now
made a new script for every box of code. Main and step 1 to 3
Made copies and added some echo lines so I could see if scripts work and/or finish correctly
executed scripts with gscript in the given order
No echo in step 1 to 3
ran original code
same result.
don't know what else to try.
sorry
Click to expand...
Click to collapse
Stay cool. I am a (quite) young man, but I have patience, too ;]
No output when running *something* as su = faulty su installation (maybe)...
Please download SuperSu 1.99 (flashable cwm version) from here: http://forum.xda-developers.com/showthread.php?t=1538053 and put it somewhere on internal sdcard
Download my "almost-working" TWRP recovery image: http://www53.zippyshare.com/v/30690424/file.html
Put it in internal mem so its path will be /sdcard/twrp2.img
Run terminal emulator (CAREFULLY WITH THE PARTITION NUMBERS!)
Code:
su
dd if=/dev/block/mmcblk0p15 of=/sdcard/recovery.backup.img
sleep 1
dd if=/sdcard/twrp2.img of=/dev/block/mmcblk0p15
sleep 1
sync
reboot recovery
In recovery, flash downloaded supersu zip. Reboot.***
Try commands again.
Maybe your busybox is bad? Can you tell me the output of command busybox written alone without further params?
***(btw the recovery may be useful, but it is not-fully-working, however, it is working AT ALL... be aware of issues:
- it cannot write backups to exfat external cards, vfat/fat32 only
- it may mess the selinux context, especially for cache partition after wipe. solution: from twrp run advanced -> console (or terminal? dont remember) and run
restorecon -R /cache
- if u ever have a bootloop after flashing a (even reliable...) zip, you should get back to twrp, click mount menu, mount everything, switch to advanced -> console and run:
restorecon -R /system
restorecon -R /data
restorecon -R /cache
selinux contex will be fixed BUT it will mess context for su binary, so in the end flash supersu again and reboot, everything will be ok.
If you want to revert, just do:
dd if=/sdcard/recovery.backup.img of=/dev/block/mmcblk0p15
).
And last but not least, kernel which I have promised (BUT if you use it, I will lose my only tester heheee):
http://www46.zippyshare.com/v/63874309/file.html
Please be aware that there are some other tweaks included (like unsecure adb, faster filesystem mount options but with higher risk of data loss, etc).
Put b4.img to /sdcard/b4.img
Run:
Code:
su
dd if=/dev/block/mmcblk0p14 of=/sdcard/boot.backup.img
sleep 1
dd if=/sdcard/b4.img of=/dev/block/mmcblk0p14
sleep 1
sync
reboot
You can revert to stock by dd if=/sdcard/boot.backup.img of=/dev/block/mmcblk0p14 (or by flashing full stock by odin). Would be glad if you can confirm that mode is permissive using this repacked kernel (HOPE IT WILL!!!!) and after some time you'll flash the backup back, to help me solving the case, as i suppose that there IS possibility of permissive without the kernel flash and I need a tester ;} It would be reeeeeeaaaaaaaally nice...
BE AWARE THAT:
- it's for note pro 12.2 LTE ONLY!!!! also called viennalte or SM-P905... It WON'T work on other devices and it may damage them (for example, coz of different mmcblk numbers...)
- messing the mmcblk0pxx number may cause an unrecoverable harm to your device (especially if you overwrite bootloader partitions or your efs partitions where unique imei is stored), it's 14 for kernel (boot) and 15 for recovery
- your knox WILL be tripped (if it hasnt been tripped yet... but it's not very probable )
- on the very first boot screen, a warning messages may appear in the left-top corner, about some warranty stuff. Ignore them, they'll disappear after reverting boot/recovery to stock.
Regards.

Just done flashing twrp and supersu(now 1.99)
i will not give up that easy, don't worry.
Just to be on the safe side i downloaded b4. Maybe you should remove it for the moment.
Looks like fun being the most important part of the team.lol.
btw. Knox was tripped about 2 hours after i got the device
busybox is v1.22.1 (2014-01-25 17:27:18)
---------- Post added at 10:05 PM ---------- Previous post was at 09:15 PM ----------
This it what happened after the last command in step 2 was executed
Could not label /dev/cpuctl with ubject_r:cpuctl_device:s0: Operation not supported on transport endpoint
Could not access /dev/kmem: Operation not supported on transport endpoint
Could not access /dev/mem: Operation not supported on transport endpoint
Could not label /dev/pts with ubject_r:device:s0: Permission [email protected]:/ #

After this I will reboot
127|[email protected]:/ # dd if=/sdcard/b4.img of=/dev/block/mmcblk0p14
18468+0 records in
18468+0 records out
9455616 bytes transferred in 2.044 secs (4626035 bytes/sec)
[email protected]:/ # sync
[email protected]:/ #
---------- Post added at 02:08 PM ---------- Previous post was at 02:00 PM ----------
One would expect to have a new kernel after the above, but guess what
[email protected]:/ $ su
[email protected]:/ # getenforce
Enforcing
[email protected]:/ # setenforce Permissive
127|[email protected]:/ # getenforce
Enforcing
[email protected]:/ #
and the kernel set the warranty bit for kernel change, but it didn't make it to block 14 as I still have the stock kernel

RaSand said:
After this I will reboot
127|[email protected]:/ # dd if=/sdcard/b4.img of=/dev/block/mmcblk0p14
18468+0 records in
18468+0 records out
9455616 bytes transferred in 2.044 secs (4626035 bytes/sec)
[email protected]:/ # sync
[email protected]:/ #
---------- Post added at 02:08 PM ---------- Previous post was at 02:00 PM ----------
One would expect to have a new kernel after the above, but guess what
[email protected]:/ $ su
[email protected]:/ # getenforce
Enforcing
[email protected]:/ # setenforce Permissive
127|[email protected]:/ # getenforce
Enforcing
[email protected]:/ #
and the kernel set the warranty bit for kernel change, but it didn't make it to block 14 as I still have the stock kernel
Click to expand...
Click to collapse
Your two posts above confirm that SU version was not the issue, as it is still preventing from modyfing anything related to kmem, sorry for effort, attough hope you'll at least enjoy included, almost-working twrp, as it seems to be only one capable of flashing zips and doing backups and restoring them on p905 floating around (if you use exfat card for everyday use, my recommendation is to use another one, ie. 8 gig, which are cheap as hell, format it to fat32 (in android it's recognized as vfat) and use it for exclusively for backup purposes, at least until someone establishes a better solution. It's not that bad after all plus it gives you real possibility of experimenting with the device without need to worry about configuring it again from the beginning if something fail. Btw please be aware if in any case, after restoring backup/flashing zip/clearing cache you'll receive a bootloop AND/OR after booting you/apps won't be able to write to any part of internal memory (like /sdcard or /cache), just get back to twrp, use console and run restorecon commands for all partitions AND -as restorecon will break su - reflash su. ALSO - if anytime TWRP on exit will prompt you with a proposition of rooting the device itself - don't do that, the only proper way of fixing su is reflashing it from the genuine zip (or with odin, but avoid that as cf-root includes older version). Uh, isn't it a offtopic? Sorry..
The kerne IS stock (as to the binary part) but with modified ramdisk (repacked) including changed policy of accessing /dev/kmem. If you have kernel warranty bit warning on boot, you have flashed it succesfully ( the message will disappear when you flash back FULLY-stock kernel back - also, i dunno why but it says "kernel is not enforcing" but it's not YET true! It will say the same even if I repack kernel without any changes, so it's quite misleading...), although kernel version/compilation number nor any extra features will not change in the system coz the kernel base is absolutely the same (and it has to stay the same until Samsung release sources that work, coz current one won't).
To really, really confirm that you have flashed my kernel and that the policy of writing to memory has been removed, please open /file_contexts file (it lies in the very root of the filesystem) in any text editor within Android, and look for lines with /dev/kmem or /dev/mem. They should be commented out by "#" in the beginning - or deleted at all (dont remember which one method I did use...). If so, you can be sure that you have flashed repacked kernel succesfully (and also that I have uploaded the proper one, with changed policy...).
If you have checked above, you may be sure that after every boot to Android, now, the new policy (without restrictions to /dev/kmem, which were commented out/deleted) will be loaded. I don't think that restorecon -R /dev will be no longer necessary after that, as the /dev directory is virtual and created on every boot, so its previous, restricted security labels are not preserved between reboots and they are assigned according to current policy, only - but you can run it to check if you see any errors for /dev/kmem (and you should NOT see them... there might be other, like for /dev/cpuctl etc, but it doesnt matter...).
After that, there should be no further doubts that you have unlocked /dev/kmem for writing!
On this step you still need to run the command from my post on top of the topic, this one:
Code:
su
printf '\x00' | su -c dd of=/dev/kmem seek=$( printf '%d\n' '0x'`cat /proc/kallsyms | grep ".*\ selinux\_enforcing" | cut -f 1 -d " "` ) bs=1 count=1 conv=notrunc
setenforcing alone WILL NOT WORK EVEN NOW, only the script above helps. I guess you avoided that after flashing kernel, coz of misleading boot warning...
Then check enforcing status. Now it really should work.
If we achieve a success, I'd rather release a fully-featured-repacked-kernel, with built-in kmem script, so it will be permissive from the very beginning (PLUS it will be in a good mood to close possibility of further writing to /kmem after that one single write, as it is really serious security hole, to be honest, to let anyone write to any part of memory directly..., and also include init.d support out-of-the-box as well).

Sorry for letting you wait that long. I was out in woods all day and did not even take the Tablett with me. Besides that there was no service whatsoever.
After running your script, wich for whatever reason I didn't do yesterday, I do have permissive selinux. As you suggested I play with it a couple of hours till bedtime and re flash stock after that to do more testing if you come up with new ideas and need a tester.
bee back in the morning, or maybe before I lay my tired head to rest.
congrats for the job you did till now.
edit:
Just checked file_contexts and the lines for kmem and mem are commented out. So for the moment I'm definitely on your kernel. Thanks again

RaSand said:
Sorry for letting you wait that long. I was out in woods all day and did not even take the Tablett with me. Besides that there was no service whatsoever.
After running your script, wich for whatever reason I didn't do yesterday, I do have permissive selinux. As you suggested I play with it a couple of hours till bedtime and re flash stock after that to do more testing if you come up with new ideas and need a tester.
bee back in the morning, or maybe before I lay my tired head to rest.
congrats for the job you did till now.
edit:
Just checked file_contexts and the lines for kmem and mem are commented out. So for the moment I'm definitely on your kernel. Thanks again
Click to expand...
Click to collapse
good, thank you for testing and hope enforcing linux won't bother you again ;] you're probably a second man on the planet who is running your machine in permissive
and don't worry about anything, it's not a race or something. i am most thankful that you found a time to run all the suggested stuff, and for patience.
please however note that leaving open /dev/kmem shall be considered as a serious security hole! it allows root app to write ANYTHING to ANY part of memory. Well, that's was an obligatory warning, however, I was never scared too much with security issues and until now nothing bad happened so..
Let's summarize:
- now I am sure that my script is working BUT only after giving it possibility of writing to memory via /dev/kmem
- writing to /dev/kmem is possible only after changing the security policy, which lies in kernel's ramdisk
- the final appropach shall also CLOSE the access to /dev/kmem just after changing the selinux mode for security reason
- the aim is to make a complete modification which will make use of only one area of the device ie. system OR kernel, not both, as it is too intrusive:
- find a way to reload policy when device is on-line, so writing to /dev/kmem will be possible (it's a preferred method, no need to flash anything and no need to watch ugly warranty message - but I doubt if it's possible - it would be an equally dangerous security issue, there is no practical difference between letting write to memory and between letting to open the possibility of write to memory and then letting write to memory ... or
- implement the memory write technique straight in the kernel's ramdisk.
I will be back with new stuff, soon.

Before you surprise us with new stuff, could please change the command to revert to stock kernel in post #12. Somebody might get into trouble by just running the command and put the kernel in the wrong block. And while you are at it. It should be if=/ not if-/ in the code field.

RaSand said:
Before you surprise us with new stuff, could please change the command to revert to stock kernel in post #12. Somebody might get into trouble by just running the command and put the kernel in the wrong block. And while you are at it. It should be if=/ not if-/ in the code field.
Click to expand...
Click to collapse
Thank you, changes made, no one should flash the wrong block device (although flashing boot to recovery - which is possible, as the boot partition size is 2meg smaller than recovery - shall result in nothing but... booting the device when entering recovery mode ;] - that's just fyi, of course, mistakes corrected...)

esgie said:
Thank you, changes made, no one should flash the wrong block device (although flashing boot to recovery - which is possible, as the boot partition size is 2meg smaller than recovery - shall result in nothing but... booting the device when entering recovery mode ;] - that's just fyi, of course, mistakes corrected...)
Click to expand...
Click to collapse
Esgie, is there any further developments with this script? I've given it a shot and even after running the script, SELinux remains in Enforcing mode.
I see that you have the modified kernel for SELinux in permissive mode, but I really like the approach of having this script rather than using a modified kernel, so I'm wondering if in your process of getting the kernel to work, there might be something you've discovered that would make this script work as well.
Thanks.

Custom *.rc (init.rc) scripts with Magisk. (Or running a script at network change.)

Hello, everyone.
In order to avoid an XY problem, I would like to introduce the actual problem first.
I need to run a script each time network changes. Android automatically changes quite a few settings when network changes, and because I need to have some of them set to specific values, I need to tweak them each time something happens.
How would I like to proceed:
There is a sysprop setting that changes each time network changes: sys.radio.cellular.netId.
Naturally, I would like to hook my script to that property change.
Android init system seems to provide such an option: init.rc syntax allows to subscribe to a property change using the
Code:
on property:propname=*
syntax.
Seems easy:
Add a custom_network.rc
Bash:
on property:sys.radio.cellular.netId=*
start custom_network
service custom_network /bin/custom_network.sh
user root
seclabel u:r:magisk:s0
oneshot
Add a file /bin/custom_network.sh:
Bash:
#/system/bin/sh
echo "TODO"
The above is essentially following this guide: https://android.stackexchange.com/q...run-an-executable-on-boot-and-keep-it-running
So, I created a magisk module, added the files above to the $MODDIR/system/etc/init, and $MODDIR/system/bin directories.
Then I added the following lines to the customize.sh:
Bash:
set_perm $MODPATH/system/bin/custom_network.sh 0 0 0755
set_perm $MODPATH/bin/custom_network.sh 0 0 0755
chown 0.0 $MODPATH/system/etc/init/custom_network.rc
chmod 0644 $MODPATH/system/etc/init/custom_network.rc
chcon u:object_r:system_file:s0 $MODPATH/system/etc/init/custom_network.rc
However, this does not work. The service custom_network does not appear in the getprop | grep svc list, and cannot be started with setprop ctl.start "custom_network".
Is it true that in order for _any_ custom rc files, the system boot image must be patched?
If yes, is there a manual how to do so?
If no, then what am I doing wrong here?
Furthermore, if patching the boot image cannot be avoided, is there a manual on how to do this with minimal pain?
On the other hand, is there a way to avoid adding a custom init service entirely, and add a network listener by some other means?

Did you figure it out?

I don't believe init services get a stdout.
You need to write to either /dev/kmsg or logcat.
You can test your service with start custom_network.
You could also listen for uevents:
Code:
s=socket(PF_NETLINK, SOCK_DGRAM, NETLINK_KOBJECT_UEVENT);
Although I'm not sure what you're looking for is there.

I was mostly looking for feedback by someone also wanting to patch the init.rc: I'm still trying to understand the cascade of events causing adbd to be started twice in boot, to find and modify the rc script responsible for the first time it's started and use instead a patched adbd

csdvrx said:
I was mostly looking for feedback by someone also wanting to patch the init.rc: I'm still trying to understand the cascade of events causing adbd to be started twice in boot, to find and modify the rc script responsible for the first time it's started and use instead a patched adbd
Click to expand...
Click to collapse
have you figured it out ? i have the same issue , i am trying to create a file at /system/etc/init folder