Database Info

[HOWTO] chroot Ubuntu 11.10 under CM7

INTRODUCTION
This document describes a procedure for installing Ubuntu 11.10 Oneiric Ocelot onto your Android device to run alongside an existing Android rom. My instructions assume you are running CyanogenMod 7. I will try to provide workarounds for other roms.
Ubuntu on a mobile device, running alongside Android, is somewhat difficult to use and is useless for most users. You should not attempt this procedure unless you have a need to run arbitrary Linux software from a mobile device. Many mobile computing needs can be met by installing remote access software on a traditional desktop computer. Conversely if you find the idea of having a general purpose Linux system in your pocket to be freaking awesome, whether you need it or not, please read on.
CAUTION
The following procedure assumes familiarity with Linux fundamentals, and basic familiarity with Android's Linux underpinnings. Data loss is possible, especially for the data on your SD card, so please make backups. Some commercial Android software is recommended, specifically Tasker and Better Terminal Emulator Pro. A large, fast SD card is also recommended. (I <3 my PNY 32 GB class 10 card)
Some optional steps are proposed that may interfere with how your Android device manages its SD card. You may be required to manually run a script before certain Android features, like mounting your device's SD card on a desktop PC via USB cable, will function properly.
Each step will have, whenever possible, a recommended procedure and one or more alternative procedures. If the recommended procedure doesn't work for you, the alternative procedure might require some research, manual-page reading, or other outside assistance to accomplish.
Shell commands should be executed on a root shell on your Android device. Use the built-in Terminal Emulator, ConnectBot in local mode, Better Terminal Emulator Pro, "adb shell" from a connected PC, or your favorite terminal emulator.
OVERVIEW
Too long; didn't read? Here's a quick summary of the steps involved:
Partition your SD card, creating a 2 GB or 4 GB Linux partition
Confirm the new partition is mounted at /sd-ext
Unpack http://cdimage.ubuntu.com/ubuntu-core/daily/current/oneiric-core-armel.tar.gz to /sd-ext
Create an empty file /sd-ext/.nomedia
Edit /system/etc/init.d/05mountsd to bind proc, dev, and sys to /sd-ext
Optionally edit /system/etc/init.d/05mountsd to bind /data, /system, and /cache to /sd-ext/mnt
Prepare a script to open a chroot shell with correct environment variables
Update /etc/apt/sources.list and /etc/resolv.conf according to your preference
Overwrite /sbin/start with /sbin/true
Copy or link important files into /etc and /lib
Initialize the package manager and begin downloading packages
(optional) Integrate Ubuntu services with Tasker profiles
STEP 1: Partition your SD Card
While a basic Ubuntu system can be installed in as little as 200 MB of disk space, many software packages require more space. Also many Linux tasks require unusual file attributes, permissions, or types, which cannot be placed on your SD card's regular FAT32 / VFAT file system.
Recommended: Use an existing Ubuntu system, or even an Ubuntu live CD, and a USB card reader to repartition your SD card without losing any data. Be sure the first primary partition remains FAT32 / VFAT, and create a second primary partition of type ext3 or ext4.
Alternative 1: Use any desktop system to back up all of the data on your SD card, either with a card reader or using your Android device. Use your phone's recovery partition to destructively repartition your SD card with a 2 or 4 GB ext3 or ext4 partition, and NO swap partition. Then copy your SD card contents back to your SD card.
Alternative 2: If you don't want to partition your SD card, you can create large empty files on your SD card and mount those. Some of the later steps will work differently and you may have to improvise.
Create large empty files on your SD card to contain your Ubuntu filesystem: dd if=/dev/zero of=/mnt/sdcard/UBUNTU.IMG bs=32768 count=65536
Identify a free loopback device number that isn't currently in use and won't likely be occupied by Android Apps2SD in the future: ls /dev/block
Create a new loop device for your file. Note the first number is the loop filename number you observed wasn't in use (at least a few dozen higher than the highest number you see), then a b and a 7, and then a number one less than the filename number. For example: mknod /dev/block/loop200 b 7 199
Associate the loop device with your new empty file: losetup /mnt/block/loop200 /mnt/sdcard/UBUNTU.IMG
Find which versions of mkfs are on your system: ls /system/xbin/mkfs*
Using whatever version you have (ext4 or ext3 preferred, but ext2 is acceptable) run: mkfs.ext# /dev/block/loop200
Save these commands in a script for later use. The dd and mkfs commands were only used this once, but the mknod and losetup commands will have to be run manually from a script each time you boot your phone.
STEP 2: Mount your Linux Partition
To avoid causing problems for your Android system, we shouldn't tamper with any of Android's critical files or directories. We will mount our Linux partition in a new directory that Android isn't using. With any luck, our rom already contains scripts that will automatically mount this for us.
Recommended: If you have partitioned your SD card and you are running CyanogenMod 7, use a root shell or file manager to confirm /sd-ext contains at least a directory called lost+found. If lost+found is present in /sd-ext then this step is done and you should continue to step 3.
Alternative 1: Use a root shell to navigate to /etc/init.d and look for a file called 05mountsd. If that file doesn't exist, you may need to create it or use another alternative method. If it does exist, run it with ./05mountsd and observe any error messages. If fsck or mount are failing because the filesystem type doesn't match what was expected, you can edit the file and change the filesystem type in the script.
Hint: you can do a quick search-and-replace using sed and a regular expression:
Code:
mv 05mountsd 05mountsd-old
cat 05mountsd-old | sed -e s/ext3/ext4/ > 05mountsd
diff 05mountsd-old 05mountsd
#changes look good to you? then proceed:
rm 05mountsd-old
ls -al
chown root.shell 05mountsd
chmod 750 05mountsd
#adapt owner (root), group (shell) and permissions (-rwxr-x---) to match the other files in that directory
Alternative 2: If your rom doesn't create, or attempt to mount, anything called /sd-ext you might have to create your own mount point.
Code:
mount -o remount,rw /system
mkdir /system/sd-ext
mount -o remount,ro /system
Then, in the following steps, replace any reference to /sd-ext with /system/sd-ext.
STEP 3: Install the Base System
Recommended: Download this file: http://cdimage.ubuntu.com/ubuntu-core/daily/current/oneiric-core-armel.tar.gz (Should be under 32 MB, and is the only potentially-insecure download required because the file is unsigned.)
Store it on your SD card somewhere, like in /mnt/sdcard/download/. (If you use your Android device's browser, it will probably land there automatically.)
If you're nervous about making a mistake, double-check your system partition is read-only:
Code:
mount | grep -v block/dm- | grep \(rw
#If anything there looks like it shouldn't be read-write, make it read-only:
mount -o remount,ro /system
Open a root shell and navigate to /sd-ext. Use pwd (present working directory) to confirm you really are in /sd-ext. Then go ahead and unpack:
Code:
tar zxvf /mnt/sdcard/download/oneiric-core-armel.tar.gz
STEP 4: Create a .nomedia file
Android may try to scan your Linux partition for images, videos, and pictures. The Linux partition contains many files and directories and this scan can take a long time. To avoid these lengthy scans, we will add a file to the Linux partition that blocks well-behaved Android services from scanning.
Recommended: Use a root shell to navigate to /sd-ext. Create the file and set its permissions:
Code:
echo > .nomedia
chown root.root .nomedia
chmod 644 .nomedia
STEP 5: Bind /proc, /dev, and /sys to the Linux partition
Recent versions of Linux provide a way to clone a partition, so when changes are made to one copy of the partition the changes take effect immediately in the other copy. We will use this to make the /proc, /dev, and /sys partitions used by Android available in our Linux partition as well.
This is necessary because when we run Ubuntu we will be using chroot (change root) to make /sd-ext the only filesystem Ubuntu can see. Ubuntu will need to be able to see /proc, /dev, and /sys, as well as some of the files in /etc, /vendor/lib, and /system/lib. We will meet some of these needs with mount --bind
Additionally we will need these bindings to be recreated every time the /sd-ext partition is mounted. So we will add some commands to the run-parts script that mounts /sd-ext, located at /etc/init.d/05mountsd.
Recommended: Open a root shell and navigate to /etc/init.d, and use a text editor to open 05mountsd.
Near the end of the file you should see some commands that operate on /sd-ext:
Code:
$BB chown 1000:1000 $SD_EXT_DIRECTORY;
$BB chmod 770 $SD_EXT_DIRECTORY;
Edit the chmod command and change the permission mask number from 770 to 775, which grants non-root users the ability to read the contents of that directory. Then add the following commands immediately after the chown and chmod commands already present:
Code:
$BB mount --rbind /dev /sd-ext/dev
$BB mount --rbind /proc /sd-ext/proc
$BB mount --rbind /sys /sd-ext/sys
STEP 6: (OPTIONAL) Bind /system, /data, and /cache to /sd-ext
This step is optional, and provides a way to operate on Android system files from within Ubuntu. If you're concerned about a stray command destroying your Ubuntu system and you want to make sure it doesn't take any Android system files with it, you should skip this step.
Recommended: Open a root shell and navigate to /sd-ext/mnt, and create some directories which will serve as mount points:
Code:
pwd
# you should be in /sd-ext/mnt
mkdir -m 700 system data cache
chown root.root system data cache
ls -al
# Each of system, data, and cache should show drwx------ and root for both owner and group
Then navigate to /etc/init.d and edit 05mountsd. Add the following under the existing mount --rbind commands you added earlier:
Code:
$BB mount --rbind /system /sd-ext/mnt/system
$BB mount --rbind /data /sd-ext/mnt/data
$BB mount --rbind /cache /sd-ext/mnt/cache
STEP 7: Prepare a script to open a chroot shell with proper environment variables
Now you will need an easy way to create a first process, a shell, in the new environment you've created. This shell will start life in a different world than regular Android shell processes live in: it will use a different root filesystem and will be able to see different files and directories, and it will have access to a vast number of full-featured programs and services.
We will be using the Bourne Again Shell, bash. We will launch bash with a program called env, which sets some environment variables and then launches a program with that new environment. Finally, we will be launching env with a program called chroot, which changes the root filesystem seen by a program before it launches it.
Option 1: Better Terminal Emulator Pro: I don't want to say "recommended" because it involves buying software that's not really necessary. I'm partial to Better Terminal Emulator Pro because it seems to have more available options (compared to the built-in Terminal Emulator) and it doesn't kill your shell unexpectedly when network connectivity changes (unlike ConnectBot). I'm not affiliated with the author of that software. Also, after I bought that I stopped looking for alternative shells, so there may exist other alternative shells that work better for this.
Use Better Terminal Emulator Pro and add the commands necessary for starting your chroot shell to BTEP's options. Once you do this, BTEP will essentially be a dedicated Ubuntu console for you, and may be difficult to use for other tasks.
My settings are:
Shell: Android Shell
Command Line: /system/bin/sh
Initial Command:
Code:
/system/xbin/chroot /sd-ext /usr/bin/env PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin TERM=linux /bin/bash -l; exit
clear
Start as root: yes
Option 2: Terminal Emulator, and a shell script: Open a root shell and create a file:
Code:
#!/system/bin/sh
/system/xbin/chroot /sd-ext /usr/bin/env PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin TERM=linux /bin/bash -l
exit
Save the file with whatever name you like, perhaps "ubuntu", and put it somewhere in your path. You could add it to /system/bin: mount -o remount,rw /system; mv ubuntu /system/bin/ubuntu; mount -o remount,ro /system
Option 3: ConnectBot: I don't recommend ConnectBot for this because, while it does offer "local" connection types, if your connectivity changes (even wifi to cell) it will close your "connection" immediately.
That said: create a new connection with type local, and give it the following initial command:
Code:
su -
/system/xbin/chroot /sd-ext /usr/bin/env PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin TERM=linux /bin/bash -l; exit
clear
STEP 8: Update /etc/apt/sources.list and /etc/resolv.conf
Ubuntu uses a package manager which automatically finds, downloads, verifies, and installs software for you. The package manager requires a list of trusted repositories which contain binaries built for ARM CPUs, like the one in your Android device.
FIXME: Later I'll discuss the pros and cons of each of these selections. For now I'll just provide my sources.list file.
Open your Ubuntu shell, using the method from step 7, and issue the following commands:
Code:
echo nameserver 8.8.8.8 > /etc/resolv.conf
# you can use a nameserver of your choice if you like.
echo nameserver 8.8.4.4 >> /etc/resolv.conf
# notice the >> instead of > which means we're appending, not overwriting.
apt-get install nano
# follow the prompts - say yes if it asks if you want to proceed.
nano -w /etc/apt/sources.list
And here are the contents of my sources.list file, containing binary sources for ARM CPUs:
Code:
deb http://ports.ubuntu.com/ubuntu-ports/ oneiric main restricted universe multiverse
deb http://ports.ubuntu.com/ubuntu-ports/ oneiric-security main restricted universe multiverse
deb http://ports.ubuntu.com/ubuntu-ports/ oneiric-updates main restricted universe multiverse
deb http://ports.ubuntu.com/ubuntu-ports/ oneiric-backports main restricted universe multiverse
deb http://archive.canonical.com/ oneiric partner
deb http://archive.canonical.com/ oneiric-security partner
deb http://archive.canonical.com/ oneiric-updates partner
deb http://archive.canonical.com/ oneiric-backports partner
STEP 9: Overwrite /sbin/start with /sbin/true
Nothing too complicated here. Some Ubuntu packages install services, which the system will usually want to automatically start and end when the system boots and shuts down.
However, on an Android device Android is responsible for booting and shutting down the system, and it doesn't know much about Ubuntu services.
Later (FIXME: when?) we'll discuss how to use an Android program like Tasker to more intelligently manage Ubuntu services. But for now, we need to trick Ubuntu's package installation scripts into believing it has successfully started a service. We will use a useless program called true, which does nothing and reports that it was successful, in place of a program called start, which will be unable to start a service because it has no access to Android's init system.
Open your Ubuntu shell and do this: cp /sbin/true /sbin/start
STEP 10: Copy or link important files into /etc and /lib
FIXME: I haven't finished this section yet. Some of my software remains broken until I fix this.
STEP 11: Initialize the package manager and begin downloading packages
Now we can begin using our Ubuntu system's package manager to install any other packages we might need.
Open your Ubuntu shell and do the following:
Code:
apt-get update
# This will take a short while, and will download updated software catalogs from each of the update servers
apt-get upgrade
# This looks for updates to any currently-installed packages. There aren't many packages installed so this should be quick.
apt-get install PACKAGE NAMES GO HERE
Then keep using apt-get install to install whatever you need.
Here are some common packages and package sets:
ubuntu-dev-tools: development tools including a compiler and linker
tightvncserver: simple X server you can connect to with androidVNC
FIXME: I need to put a lot more here.

Sorry for bumping old threat, but I am kind of stuck. Everything goes fine, but when I try to create the script in BTEP (and android terminal) I am getting segmentation fault in both of them.
Checked for syntax errors 100 of times. I am using CM6 froyo 2.2 on Motorola milestone. SD card has 2 gb of ext3 partition mounted in /sd-ext.
*EDIT*
Reflashed CM 7 latest and same thing happens. Segmentation Fault.

[HOWTO] Use pattern lock and device encryption

Normally, a pattern/gesture lock is not available when device encryption is activated.
But the lockscreen can be reactivated by changing the corresponding settings in /data/data/com.android.providers.settings/databases/settings.db to the values used for the pattern lock before enabling device encryption, namely resetting lockscreen.password_type to PASSWORD_QUALITY_SOMETHING.
If you don't run Android 4.0.4, you may verify that android.app.admin.DevicePolicyManager.PASSWORD_QUALITY_SOMETHING still corresponds to 0x10000.
Enter a root shell and execute:
Code:
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "UPDATE secure SET value='65536' WHERE name = 'lockscreen.password_type'"
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "UPDATE secure SET value='1' WHERE name = 'lockscreen.patterneverchosen'"
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "UPDATE secure SET value='1' WHERE name = 'lock_pattern_autolock'"
Generate a new gesture.key with the attached perl script (call it without arguments for help) and transfer it to the device:
Code:
mv gen-gesture.key.pl.txt gen-gesture.key.pl && chmod +x gen-gesture.key.pl
./gen-gesture.key.pl 01258 > gesture.key
adb push gesture.key /mnt/sdcard/Download/
adb shell
su -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
^C
Reboot the device.
This was tested on my Samsung Galaxy S3 with Android 4.0.4.
Thanks to robberknight who initiated a thread about PIN locks and encryption.

Thanks for the post!
I tried this today with my Samsung Galaxy Note 2 but it didn't work (Android 4.1)
The only thing I couldn't do (regarding to your how-to) was using the sqlite3 command from the shell, because there is no sqlite3 on my device (installing it with "SQLite Installer for root" didn't work either, I'm getting a "CANNOT LINK EXECUTABLE" error). So I just pulled the settings.db to my computer, editied it with an sqlite-manager and pushed it back. But I guess this shouldn't make any difference ...
I simply can't get rid of the password unlock screen, no matter what I enter in the sqlite database.
And I would be happy if I could even use a PIN instead of an alphanumeric password (which is the only option for encryption now)
By the way, what did you mean with "If you don't run Android 4.0.4, you may verify that android.app.admin.DevicePolicyManager.PASSWORD_QUA LITY_SOMETHING still corresponds to 0x10000."?
On my phone this constant is 65536
Right now this would be my lock-settings from the settings.db:
"103","lock_after_timeout_rollback","60000"
"35","lock_motion_tilt_to_unlock","0"
"107","lock_pattern_autolock","1"
"108","lock_pattern_visible_pattern","0"
"104","lock_screen_lock_after_timeout","60000"
"94","lock_screen_owner_info","..."
"95","lock_screen_owner_info_enabled","1"
"59","lock_screen_quick_note","1"
"36","lock_signature_visible_pattern","1"
"29","lockscreen.disabled","0"
"109","lockscreen.lockexchange.enable","0"
"34","lockscreen.options","enable_facelock"
"105","lockscreen.password_type","65536"
"106","lockscreen.patterneverchosen","1"

Found the solution on my own: Just delete the /data/system/locksettings.db (this one was empty on my device anyway)
After a restart the lock-keys of settings.db now finally work. I guess there is some caching in place and removing the locksettings.db forces Android to update the settings of the lock-screen.

Hello!
This sounds very interesting.
How to define the unlock pattern:
Does the perl-script create a pattern/gesture that corresponds to the digits you entered. In your example:
gen-gesture.key.pl 01258 > gesture.key - This makes your pattern 01258? (Since there is no dot inte 3x3 pattern matrix to represent a "0" then this cannot be correct.)
How do I define the pattern I want to use then? Is this done separately by going in to the settings later when the phone is booted? I don't dare to do this in fear of "locking" the device with a pattern/gesture that I don't know.
I hope to get your help here...
Thank you!

Thank you very much mod23! My phone is finally usable again
Works as described on Galaxy R with leaked ICS.
-Android Freak- said:
This makes your pattern 01258? (Since there is no dot inte 3x3 pattern matrix to represent a "0" then this cannot be correct.)
Click to expand...
Click to collapse
Was confused at first as well, but running the perl script without arguments tells us:
0 1 2
3 4 5
6 7 8
Afterwards, you won't be able to change it in the settings. I think you have to newly generate the gesture.key

Warning
I do not want to give lessons to anybody, but just to highlight how the unlock pattern protection is low, thwarting almost certainly the extra layer of protection that is supposed to be brought by Android full-phone encryption. Just consider the following remarks:
1) Contrary to a PIN code, pattern lock equivalent digits will be linked to each other (except if you are really really cunning). For example, if you start at digit 0, the following digits are to be 1,4 or 3. Thus decreasing dramatically the entropy of the underlying number.
2) You can't use the same digit two times. As an example, try the greek PHI symbol. The equivalent PIN code can't be 03452147, because 4 can't be used two times. The equivalent code must be simpler: 034521 7. You will agree that this greatly reduces the number of possible equivalent PIN codes you can achieve with pattern lock.
3) The protection mechanism offered by Android is way too weak in my opinion for such lock mechanism. After 3 failed attempts, your phone just ask you to wait for 30 sec. It does not shutdown.
4) But the killing argument is: you have grease under your fingers. Except if you systematically think to wipe the screen of your phone after unlocking your phone, the gesture will let a fingerprint corresponding to the gesture you will repeat several times per day. Try by yourself, and see how easy it is to see the lock pattern used with an oblique light source.
So, if I was to steal your phone to have access to your personal data you think secured by encryption, I would
1) Steal your phone when it is on
2) Realize that it is "protected" by lock pattern
2) Use an oblique light with the almost certainty that I will see the fingerprint of the pattern lock (except if you wipe systematically your screen, or you wash your hands always before unlocking your phone).
3) Try to draw the pattern in one direction.
4) Try it in the other direction if it fails. Almost sure to unlock the phone at this point (except if the pattern is really really intricate).
5) Once your phone is unlocked, I could do whatever I would want to with it. So no need to be the king of crackers.
I hope, after reading this, you will reconsider using pattern lock in parallel to encryption. In my opinion, it is a total nonsense. But it is my only personal opinion. Just judge by yourself.
Edit:
------
For me, the only way, both secure and practical, to secure your phone is by using a PIN code of at least 4 numbers (6 is better). PIN codes let fingerprints much harder to "interpret" than unlock pattern. Then use a handy tool like EncPassChanger to have a true complex password for decryption at boot time. And, if you are clearly paranoid, follow this great tip: http://forum.xda-developers.com/showpost.php?p=26730989&postcount=2.
And, something that people may forget, always double check that USB debugging is disabled.

lolo250612 said:
For me, the only way, both secure and practical, to secure your phone is by using a PIN code of at least 4 numbers (6 is better). PIN codes let fingerprints much harder to "interpret" that unlock pattern. Then use a handy tool like EncPassChanger to have a true complex password for decryption only at boot time. And, if you are clearly paranoid, follow this great tip: http://forum.xda-developers.com/showpost.php?p=26730989&postcount=2.
Click to expand...
Click to collapse
There is one big problem with your solution: The SD card. The SD card is encrypted with your PIN Code as well, which is stored in the same file as your screen-unlock-PIN code. I have no idea why the Google developers choose to use the same file for everything, but they did. So your solution is a good idea as long as you don't care about the security of your SD card.

On my phone (Lenvo A789, with ICS 4.0.4), the sdcards (both internal and external) are not encrypted at all. Only /data and other "system" partitions. You can view them with Terminal Emulator, by typing the mount command. The encrypted partitions correspond to /dev/block/dm-x (x is a number). Just to be clear, I mean "sdcards", the partition /mnt/sdcard or /mnt/sdcard2 as reported by Android and mounted as such.
Anyway. I am certainly not an expert in security. I am just trying to document myself to have an overview of the security mechanisms I use. But, if I am right, your encrypted partitions are not encrypted directly with your password or your PIN code. They are encrypted by a random key generated by Android when you start the encryption process. This master key is then encrypted itself at first by your PIN code (if you choose this option) before being saved in a file. That's what allows the user to change his password without having to re-encrypt everything. And I agree with you, this is a major security flaw, as a password with only digits can be cracked in a few µsec by a casual PC, if somebody has access physically to the content of your phone memory and this key file.
This is where EncPassChanger acts. It reencrypts your master key (not the data itself) with a password that can be complex as you don't type it everytime you unlock your phone.
So you have your PIN code to unlock your phone when it is on ( and only when it is on); it does not decrypt anything, decryption only occurs at boot time; it just gives you access to the UI and allows you to interact with your phone. And you have a strong password for the encryption of the data that lay physically on the memory (even when the phone is off), that allows Android to decrypt your master encryption key at boot, and therefore your data. And the PIN code cannot be used to decrypt your encryption master key any longer.
"Online" protection (phone lock) and "offline" protection (encryption of data lying "physically" on the memory) are really two different things. They become completely disconnected from each other once you use EncPassChanger to make the encryption/decryption password different from the initial PIN code. The only thing you have to be careful about, is that if you change your PIN code for whatever reasons, Android reencrypts the master encryption key with this new PIN code, droping the job done previously by EncPassChanger. So you have to use it again.
And the fact that, for a reason I don't see clearly, your sdcard would be encrypted as well as /data, does not change anything to that.
But I may be wrong, don't I ?
For more extensive details, see: http://nelenkov.blogspot.fr/2012/08/changing-androids-disk-encryption.html and http://source.android.com/tech/encryption/android_crypto_implementation.html
And even more details (Android encryption is in fact more or less Linux LUKS): http://www.markus-gattol.name/ws/dm-crypt_luks.html

Confirmed working on Nexus 10 and Nexus 4 with 4.2.2
Check for records in settings.db first!
If they don't exist, use this method.
On newer devices, the fields above do not exist in the settings.db file once encryption has been activated. The proper way to do this for a device is to confirm the settings are there, and if not, go through the below process (note the INSERTs instead of UPDATEs).
Create gesture.key using the Perl script and copy to SDCARD
Ensure device is unlocked and keep screen active while running the below code. If the device locks, you can get stuck on a black screen after removing /data/system/locksettings.db.
Run the below code.
Code:
su -
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "INSERT INTO secure (name, value) values ('lockscreen.password_type', '65536')"
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "INSERT INTO secure (name, value) values ('lockscreen.patterneverchosen', '1')"
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "INSERT INTO secure (name, value) values ('lock_pattern_autolock', '1')"
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "INSERT INTO secure (name, value) values ('lock_pattern_visible_pattern', '1')"
cat /mnt/sdcard/gesture.key > /data/system/gesture.key
rm /data/system/locksettings.*
Reboot
Lastly, combine with EncPassChanger to use a 20+ character encryption password at boot to ease your mind about brute force attempts.
Thanks,
Ben

Fmstrat said:
Confirmed working on Nexus 10 and Nexus 4 with 4.2.2
Check for records in settings.db first!
If they don't exist, use this method.
On newer devices, the fields above do not exist in the settings.db file once encryption has been activated. The proper way to do this for a device is to confirm the settings are there, and if not, go through the below process (note the INSERTs instead of UPDATEs).
Create gesture.key using the Perl script and copy to SDCARD
Ensure device is unlocked and keep screen active while running the below code. If the device locks, you can get stuck on a black screen after removing /data/system/locksettings.db.
Run the below code.
Code:
su -
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "INSERT INTO secure (name, value) values ('lockscreen.password_type', '65536')"
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "INSERT INTO secure (name, value) values ('lockscreen.patterneverchosen', '1')"
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "INSERT INTO secure (name, value) values ('lock_pattern_autolock', '1')"
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "INSERT INTO secure (name, value) values ('lock_pattern_visible_pattern', '1')"
cat /mnt/sdcard/gesture.key > /data/system/gesture.key
rm /data/system/locksettings.*
Reboot
Lastly, combine with EncPassChanger to use a 20+ character encryption password at boot to ease your mind about brute force attempts.
Thanks,
Ben
Click to expand...
Click to collapse
Thanks for the update. I want to give this a try on my Razr Maxx HD running 4.1.1, any idea if this will work? Also, in your info here, your code says:
Code:
('lockscreen.password_type', '65536')"
But isn't it impossible to use the same number twice? Not sure I understand this correctly if that is a true pattern lock sequence.

gadsden said:
Thanks for the update. I want to give this a try on my Razr Maxx HD running 4.1.1, any idea if this will work? Also, in your info here, your code says:
Code:
('lockscreen.password_type', '65536')"
But isn't it impossible to use the same number twice? Not sure I understand this correctly if that is a true pattern lock sequence.
Click to expand...
Click to collapse
I don't see any reason why it wouldn't work, but of course, no guarantees. As for the password_type, 65536 is a code saying "use the pattern lock", it is not the same as the string of numbers used with the python file to create your gesture.key file.
Thanks,
Ben

Fmstrat said:
Confirmed working on Nexus 10 and Nexus 4 with 4.2.2
Check for records in settings.db first!
If they don't exist, use this method.
On newer devices, the fields above do not exist in the settings.db file once encryption has been activated. The proper way to do this for a device is to confirm the settings are there, and if not, go through the below process (note the INSERTs instead of UPDATEs).
Create gesture.key using the Perl script and copy to SDCARD
Ensure device is unlocked and keep screen active while running the below code. If the device locks, you can get stuck on a black screen after removing /data/system/locksettings.db.
Run the below code.
Code:
su -
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "INSERT INTO secure (name, value) values ('lockscreen.password_type', '65536')"
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "INSERT INTO secure (name, value) values ('lockscreen.patterneverchosen', '1')"
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "INSERT INTO secure (name, value) values ('lock_pattern_autolock', '1')"
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "INSERT INTO secure (name, value) values ('lock_pattern_visible_pattern', '1')"
cat /mnt/sdcard/gesture.key > /data/system/gesture.key
rm /data/system/locksettings.*
Reboot
Lastly, combine with EncPassChanger to use a 20+ character encryption password at boot to ease your mind about brute force attempts.
Thanks,
Ben
Click to expand...
Click to collapse
Ok, I'm ready to do this, but I am afraid I have no idea what I'm doing! I couldn't find the settings.db like you said might happen. I tried running the perl script, but got permission denied when it tried to create /data/system/gesture.key. It did create the key and push it to the device, but then it stopped there.
After I verified it did push the gesture.key, I tried running the sqlite3 code in root shell. Some of the commands said adb does not recognize this command as an internal or external command. I have never ran commands like the ones shown here for sqlite3. My adb experience is pretty limited to following directions to root. I have done manual roots in adb, so I understand some basic commands, but this is out of my league! Can you help me a little bit to do this with some steps that are more beginner-ish? If you can help me out (PM is fine), I'll be glad to type out the instructions in an organized way for others to follow in the future. I really want to be able to set this up, any help would be greatly appreciated.

Ok, I think I need to stop messing with this now, been working on it all day! I ran all the sqlite3 commands you said, and got stuck at the cat command. It says no such file or directory. I think I did the perl script wrong and never got the gesture key done right. It pushed a file called gesture.key, but I don't know if it's right. I am not sure how to run the perl script, really. I have to get back to my job that I haven't done anything at today, yikes! Any help is appreciated.

Ok, I didn't quite understand the concept of how this worked yesterday, so I spent some more time on it today. I thought the perl script was to be ran from the PC. I didn't understand that I was supposed to be loosely following the steps in the other thread referenced here. Having no experience whatsoever with python, I didn't know what to do. Now, I understand the process, I am just having a little trouble. So far I have followed these instructions.
Fmstrat said:
Check for records in settings.db first!
If they don't exist, use this method.
Click to expand...
Click to collapse
I looked and could not find this, so I proceeded as described.
azoom1 said:
1) Load SLA4
2) Menu-View-Interpreters
3) Menu-Add
4) Select Python 2.6.2 - the SLA4 app will go get Python and intall it with the correct linking
5) Exit SLA4, then start Python and select Install, and when finished, exit Python
6) Put the pin_change.py file in the SLA4 "scripts" directory
7) Start SLA4
After that, when SLA4 is run you should see the script in the pick list. Upon selection SLA4 will pop-up an icon select-list. Pick the gear, which will run the script.
Click to expand...
Click to collapse
(I pasted this from the other thread, I did not use the script name here, I did use gen-gesture.key.py)
I installed SLA4 as described here and went to run the script with the gear icon. When I run it, all I get is a notification that gen-gesture.key.py was exited. Reading that I am supposed to generate the key, then copy it to the SD card, I thought maybe it did generate the gesture.key and I just have to find it, but I looked everywhere through files and couldn't find the file anywhere. I did locate a log file, gen-gesture.key.py.log, but it was blank, nothing to see.
Thinking there might have been a problem with the script, I tried to use the QR code here, but python said "Invalid QR code content". I double checked my script and I don't appear to have missed anything when I copied it, so I am lead to believe there is something else I am missing about how to use python. Only other thing I can think of that's wrong is the script extension, I used .py to run it in python, but wonder if it's supposed to be .pl since it's perl, or if I need .py to run it in python and the script runs as a perl script like that.
So, I am trying really hard to do this, I'm trying to learn on my own, but a little help would be really nice if anyone is able.

Bumped for help!

gadsden said:
Bumped for help!
Click to expand...
Click to collapse
You should not need to follow any directions in another thread. The Perl script is intended to be run on a PC, not on the phone, so there is no need for Perl to be installed. Running the script with out any arguments prints out the pattern of the android lock screen but instead of dots it has numbers. Run the script with the numbers after it as provided in the example in post number 1 to create the gesture.key file on your PC. Then copy that file over to the phone as described.
I'm also a little confused by your comment about not finding settings.db. I can think of no reason why the file would not exist, unless you mean that the records were not in the database file.
Thanks,
Ben

Fmstrat said:
You should not need to follow any directions in another thread. The Perl script is intended to be run on a PC, not on the phone, so there is no need for Perl to be installed. Running the script with out any arguments prints out the pattern of the android lock screen but instead of dots it has numbers. Run the script with the numbers after it as provided in the example in post number 1 to create the gesture.key file on your PC. Then copy that file over to the phone as described.
I'm also a little confused by your comment about not finding settings.db. I can think of no reason why the file would not exist, unless you mean that the records were not in the database file.
Thanks,
Ben
Click to expand...
Click to collapse
You said to check for records in settings.db first. When I search through my files, I can locate the directory data/data/com.android.providers.settings, but there is nothing inside of it. So, I did run the sqlite codes. I ran each line separately, and it said Error:too many options. So, I ran them all together and no errors came back. However, I still can't find anything in the directory.
Then to run the script, there is an attached file here called gen-gesture.key.pl.txt. Am I supposed to put that file into my platform tools folder and use the mv gen-gesture.key code to call the script? Or do I paste the text in the txt file into adb? I have tried running everything explained here in root shell in adb, I thought that was how I am supposed to do it, but I seem to be missing something. Sorry for the basic questions, but I'm still learning here.

Fmstrat said:
You should not need to follow any directions in another thread. The Perl script is intended to be run on a PC, not on the phone, so there is no need for Perl to be installed. Running the script with out any arguments prints out the pattern of the android lock screen but instead of dots it has numbers. Run the script with the numbers after it as provided in the example in post number 1 to create the gesture.key file on your PC. Then copy that file over to the phone as described.
I'm also a little confused by your comment about not finding settings.db. I can think of no reason why the file would not exist, unless you mean that the records were not in the database file.
Thanks,
Ben
Click to expand...
Click to collapse
Here's what I did so far.
1) Installed perl because it wasn't on my computer
2) changed permissions on /data/data/com.android.providers.settings/databases/settings.db to 777 so I could view the files in DDMS. Checked the settings.db and when I outputted it as a text file, all I got was a blank document
3) installed sqlite3 on my phone with sqlite installer
4) Entered root shell and entered
Code:
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "UPDATE secure SET value='65536' WHERE name = 'lockscreen.password_type'"
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "UPDATE secure SET value='1' WHERE name = 'lockscreen.patterneverchosen'"
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "UPDATE secure SET value='1' WHERE name = 'lock_pattern_autolock'"
I didn't know if I was supposed to run each line individually, or all at once, so I did it both ways. neither one had an error
5) Saved the gen-gesture.key.pl.txt file to my platform tools folder. Ran
Code:
perl gen.gesture.key.pl.txt
It came back with this
Code:
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>perl C:\Android\ad
t-bundle-windows-x86-20130219\sdk\platform-tools\gen-gesture.key.pl.txt
Usage: gen-gesture.key.pl <sequence>
With sequence as number sequence drawn on this keypad:
0 1 2
3 4 5
6 7 8
The generated binary output has to be put into: /data/system/gesture.key
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>
6) then entered this all at once
Code:
mv gen-gesture.key.pl.txt gen-gesture.key.pl && chmod +x gen-gesture.key.pl
./gen-gesture.key.pl 01258 > gesture.key
adb push gesture.key /mnt/sdcard/Download/
adb shell
su -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
^C
it came back with a bunch of errors and left me at root shell. I figured maybe I was supposed to run it from root shell anyway, so I entered it again. The very first command came back as "mv" is not a recognized internal or external command. I tried it a couple more times, but I'm not following what's supposed to happen here. I did do a reboot of the phone and when I did so, the lock settings were disabled. So, something is happening, but not everything that needs to. I I've probably spent over 12 hours on this over the past week and I am sure I'm doing it wrong. The OP doesn't describe in detail how a beginner needs to do this. I've learned as much as I can, but seeing as how I even got stuck on not knowing I needed to install perl, I'm positive that I'm missing more. The post just isn't beginner friendly. I'm trying hard to understand this but I'm becoming really discouraged here. Can someone provide a little more info here.
Here's the whole session if it helps
Code:
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>perl C:\Android\ad
t-bundle-windows-x86-20130219\sdk\platform-tools\gen-gesture.key.pl.txt
Usage: gen-gesture.key.pl <sequence>
With sequence as number sequence drawn on this keypad:
0 1 2
3 4 5
6 7 8
The generated binary output has to be put into: /data/system/gesture.key
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>mv gen-gesture.key
.pl.txt gen-gesture.key.pl && chmod +x gen-gesture.key.pl
'mv' is not recognized as an internal or external command,
operable program or batch file.
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>./gen-gesture.key.
pl 01258 > gesture.key
'.' is not recognized as an internal or external command,
operable program or batch file.
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>adb push gesture.k
ey /mnt/sdcard/Download/
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>adb shell
su -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
^Csu -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
[email protected]:/ $ su -
re.key > /data/system/gesture.key <
[email protected]:/ # mv gen-gesture.key.pl.txt gen-gesture.key.pl && chmod +x gen-g
esture.key.pl
./gen-gesture.key.pl 01258 > gesture.key
adb push gesture.key /mnt/sdcard/Download/
adb shell
su -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
n-gesture.key.pl && chmod +x gen-gesture.key.pl <
sh: ^Cmv: not found
adb push gesture.key /mnt/sdcard/Download/
adb shell
su -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
127|[email protected]:/ # ./gen-gesture.key.pl 01258 > gesture.key
sh: can't create gesture.key: Read-only file system
1|[email protected]:/ # adb push gesture.key /mnt/sdcard/Download/
* daemon not running. starting it now on port 5038 *
* daemon started successfully *
error: device not found
1|[email protected]:/ # adb shell
error: device not found
1|[email protected]:/ # su -
re.key > /data/system/gesture.key <
[email protected]:/ #
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>mv gen-gesture.key
.pl.txt gen-gesture.key.pl && chmod +x gen-gesture.key.pl
'mv' is not recognized as an internal or external command,
operable program or batch file.
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>./gen-gesture.key.
pl 01258 > gesture.key
'.' is not recognized as an internal or external command,
operable program or batch file.
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>adb push gesture.k
ey /mnt/sdcard/Download/
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>adb shell
su -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
^Csu -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
[email protected]:/ $ su -
re.key > /data/system/gesture.key <
[email protected]:/ # exit
^Cexit
sh: ^Cexit: not found
127|[email protected]:/ # exit
exit
127|[email protected]:/ $ exit
exit
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>mv gen-gesture.key
.pl.txt gen-gesture.key.pl && chmod +x gen-gesture.key.pl
'mv' is not recognized as an internal or external command,
operable program or batch file.
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>./gen-gesture.key.
pl 01258 > gesture.key
'.' is not recognized as an internal or external command,
operable program or batch file.
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>adb push gesture.k
ey /mnt/sdcard/Download/
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>adb shell
su -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
^Csu -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
[email protected]:/ $ su -
re.key > /data/system/gesture.key <
[email protected]:/ #

Been working on this for a whole week now, just wondering if I'm even on the right track here?
gadsden said:
Here's what I did so far.
1) Installed perl because it wasn't on my computer
2) changed permissions on /data/data/com.android.providers.settings/databases/settings.db to 777 so I could view the files in DDMS. Checked the settings.db and when I outputted it as a text file, all I got was a blank document
3) installed sqlite3 on my phone with sqlite installer
4) Entered root shell and entered
Code:
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "UPDATE secure SET value='65536' WHERE name = 'lockscreen.password_type'"
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "UPDATE secure SET value='1' WHERE name = 'lockscreen.patterneverchosen'"
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "UPDATE secure SET value='1' WHERE name = 'lock_pattern_autolock'"
I didn't know if I was supposed to run each line individually, or all at once, so I did it both ways. neither one had an error
5) Saved the gen-gesture.key.pl.txt file to my platform tools folder. Ran
Code:
perl gen.gesture.key.pl.txt
It came back with this
Code:
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>perl C:\Android\ad
t-bundle-windows-x86-20130219\sdk\platform-tools\gen-gesture.key.pl.txt
Usage: gen-gesture.key.pl <sequence>
With sequence as number sequence drawn on this keypad:
0 1 2
3 4 5
6 7 8
The generated binary output has to be put into: /data/system/gesture.key
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>
6) then entered this all at once
Code:
mv gen-gesture.key.pl.txt gen-gesture.key.pl && chmod +x gen-gesture.key.pl
./gen-gesture.key.pl 01258 > gesture.key
adb push gesture.key /mnt/sdcard/Download/
adb shell
su -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
^C
it came back with a bunch of errors and left me at root shell. I figured maybe I was supposed to run it from root shell anyway, so I entered it again. The very first command came back as "mv" is not a recognized internal or external command. I tried it a couple more times, but I'm not following what's supposed to happen here. I did do a reboot of the phone and when I did so, the lock settings were disabled. So, something is happening, but not everything that needs to. I I've probably spent over 12 hours on this over the past week and I am sure I'm doing it wrong. The OP doesn't describe in detail how a beginner needs to do this. I've learned as much as I can, but seeing as how I even got stuck on not knowing I needed to install perl, I'm positive that I'm missing more. The post just isn't beginner friendly. I'm trying hard to understand this but I'm becoming really discouraged here. Can someone provide a little more info here.
Here's the whole session if it helps
Code:
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>perl C:\Android\ad
t-bundle-windows-x86-20130219\sdk\platform-tools\gen-gesture.key.pl.txt
Usage: gen-gesture.key.pl <sequence>
With sequence as number sequence drawn on this keypad:
0 1 2
3 4 5
6 7 8
The generated binary output has to be put into: /data/system/gesture.key
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>mv gen-gesture.key
.pl.txt gen-gesture.key.pl && chmod +x gen-gesture.key.pl
'mv' is not recognized as an internal or external command,
operable program or batch file.
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>./gen-gesture.key.
pl 01258 > gesture.key
'.' is not recognized as an internal or external command,
operable program or batch file.
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>adb push gesture.k
ey /mnt/sdcard/Download/
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>adb shell
su -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
^Csu -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
[email protected]:/ $ su -
re.key > /data/system/gesture.key <
[email protected]:/ # mv gen-gesture.key.pl.txt gen-gesture.key.pl && chmod +x gen-g
esture.key.pl
./gen-gesture.key.pl 01258 > gesture.key
adb push gesture.key /mnt/sdcard/Download/
adb shell
su -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
n-gesture.key.pl && chmod +x gen-gesture.key.pl <
sh: ^Cmv: not found
adb push gesture.key /mnt/sdcard/Download/
adb shell
su -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
127|[email protected]:/ # ./gen-gesture.key.pl 01258 > gesture.key
sh: can't create gesture.key: Read-only file system
1|[email protected]:/ # adb push gesture.key /mnt/sdcard/Download/
* daemon not running. starting it now on port 5038 *
* daemon started successfully *
error: device not found
1|[email protected]:/ # adb shell
error: device not found
1|[email protected]:/ # su -
re.key > /data/system/gesture.key <
[email protected]:/ #
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>mv gen-gesture.key
.pl.txt gen-gesture.key.pl && chmod +x gen-gesture.key.pl
'mv' is not recognized as an internal or external command,
operable program or batch file.
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>./gen-gesture.key.
pl 01258 > gesture.key
'.' is not recognized as an internal or external command,
operable program or batch file.
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>adb push gesture.k
ey /mnt/sdcard/Download/
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>adb shell
su -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
^Csu -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
[email protected]:/ $ su -
re.key > /data/system/gesture.key <
[email protected]:/ # exit
^Cexit
sh: ^Cexit: not found
127|[email protected]:/ # exit
exit
127|[email protected]:/ $ exit
exit
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>mv gen-gesture.key
.pl.txt gen-gesture.key.pl && chmod +x gen-gesture.key.pl
'mv' is not recognized as an internal or external command,
operable program or batch file.
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>./gen-gesture.key.
pl 01258 > gesture.key
'.' is not recognized as an internal or external command,
operable program or batch file.
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>adb push gesture.k
ey /mnt/sdcard/Download/
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>adb shell
su -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
^Csu -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
[email protected]:/ $ su -
re.key > /data/system/gesture.key <
[email protected]:/ #
Click to expand...
Click to collapse

thx

[GUIDE] Native Debian on Samsung Galaxy i7500

Hello fellow phone enthusiasts,
there are some sources on the internet describing how to run Debian on the Samsung Galaxy i7500 (Samsung's first Android device). Unfortunately, none of these sources can act as a complete guide, so I thought I could try to fill this void. This guide is far from complete and will hopefully grow over time. Anyway, I hope this is helpful for some people that are trying to do the same.
Note that this post should have gone into the development section, but I'm not senior enough to post there. Also the URLs in this guide are messed up for the same reason. Each messed up URL is marked with "(FIX this url)". I will fix these things as soon as possible, if there is any interest in this guide.
Best regards,
Frank
0. WARNING
This guide is for experienced users only. You might brick your phone while following this guide. I will not take responsibilty for any harm that may happen to you, your phone or those around you when following this guide. Please read and understand the complete guide before doing the first step. You have been warned.
Make a nandroid backup (can be done in the recovery image). Really, do it. Even if you think there's no valuable data, you must do a nandroid backub, because you will need to have the boot.img to boot back into android after debian has been installed. You must also copy your nandroid backup onto your PC.
1. Credits
A few years ago, there has been quite an active development community for the Galaxy i7500. Unfortunately, these forums have now pretty much died and I was not an active member of that community, because I was using it as my primary device back then and had no interest in hacking it.
Anyway, a HUGE THANK YOU goes to the fine fellas from drakaz.com and the GAOSP. You guys are awesome!
The actual hard technical work for this guide has been done by the authors of the following guides. I'm simply trying to understand what they did and write a step-by-step guide using their expertise:
(FIX this url)https :// code . google . com/p/linux-on-android/wiki/BasicSteps
(FIX this url)https :// wiki . debian . org/ChrootOnAndroid
(FIX this url)http :// www . bananenfisch . net/?p=1056
(FIX this url)https :// sven . killig . de/android/console.html
2. Overview
The goal of this guide is to have a running Debian Squeeze (Debian 6) running natively on a Samsung Galaxy i7500. Debian will not be run in a chroot environment on top of android, but instead the phone will directly boot into debian when powering it on. Debian will be installed on a SD card, so that we could still boot into Android, should we really mess things up at some point. It will not be true dual boot though (i.e. you have to reflash the boot section from a PC to boot into Android).
2.1 Primary goals
In the end, I'd like have the following functionality:
WLAN
Bluetooth
X Window / Graphical User Interface
All this is possible with below description now.
But this means we will loose the ability to make phone calls, send text messages, use GPS, connect to the internet through 3G or anything else you would normally expect from a smartphone. It's very likely possible to also have this functionality included, but I simply don't need it for my project. If someone else is willing to investigate this, I would be interested in the results though.
2.2 Prerequisites
Things you'll need include:
good Linux knowlegde
1 rooted Samsung Galaxy i7500 (I recommend to flash GAOSP)
1 micro SD card (I'm using an 8 GiB class 4 card)
1 computer running Linux with the following software installed (I'm using Debian & Fedora, but any distribution that has debootstrap should work)
debootstrap
git
fastboot (I suggest to use the version that comes with your distro, but you can also try the one from the Android SDK)
GCC cross-compiler for ARM in order to compile the kernel (Debian and Fedora come with compiler versions, that didn't work for me, so I'm using version 7 of the Android NDK, i. e. GCC version 4.4.3)
3. Installing Debian
Note that I had already GAOSP2 beta 3 installed on the i7500. I don't know if any of these steps are possible without installing GAOSP first.
3.1 Prepare partitions on SD card
The Samsung Galaxy i7500 has an "internal SD card" which will be preserved for use with Android, the recovery image, a.s.o. The external SD card will be used for debian. ALL data on the external card will be lost after below steps.
Put the SD card into an SD card reader or boot the i7500 into recovery mode (press "vol-" and "call" buttons when switching on the phone). Note that using GAOSP directly didn't work for me, because for some reason only the first partition was shown on the PC.
Code:
cfdisk /dev/sdX
(replace X with the correct letter for your SD card, and then create the one big enough partition for your needs, I created one 4GiB primary partition leaving me 4GiB for playing around later)
Code:
sudo mke2fs /dev/sdX1
3.2 Build debian filesystem structure
Create a directory for the newly created debian partition (I assume it' s called "debian") and run the following commands
Code:
sudo mount /dev/sdX1 ./debian/
Code:
sudo debootstrap --verbose --arch armel --foreign squeeze ./debian/ (FIX this url) http :// ftp . de . debian . org/debian
Code:
sudo umount ./debian/
3.3 Finalize the debian installation
The following is based on the steps as described here (FIX this url) wiki. debian.org/ChrootOnAndroid and www . bananenfisch .net/?p=1056.
Boot phone into GAOSP
Open terminal
Code:
su
Code:
cd /data/local
Code:
mkdir debian
Code:
mount /dev/block/mmcblk1p1 /data/local/debian
Finalize bootstrap:
Code:
chroot /data/local/debian /debootstrap/debootstrap --second-stage
Mount special file systems and chroot into Debian:
Code:
for f in dev dev/pts proc sys ; do mount -o bind /$f /data/local/debian /$f ; done
Code:
chroot /data/local/debian /bin/bash
Finalise the installation:
Code:
echo "deb (FIX this url) http :// ftp . de . debian . org/debian/ squeeze main non-free contrib" > /etc/apt/sources.list
Code:
apt-get update
Code:
rm -f /etc/mtab
Code:
ln -s /proc/mounts /etc/mtab
Code:
passwd root
Code:
echo i7500 > /etc/hostname
Code:
apt-get install openssh-server
Code:
apt-get clean && apt-get autoclean
The ssh-sever can be started whenever you like through
Code:
/etc/init.d/ssh start
Afterwards you can log in from your PC using "ssh [email protected]" into the chroot environment.
3.4 Configure locale
We need to set the locale for the system (otherwise there will always be warning messages, e.g. when installing new software):
Code:
apt-get install locales console-data keyboard-configuration
You might want to tweak a few more settings (especially if your locale is not en_US). You can use:
Code:
echo export LANG=en_US.UTF-8 >> /root/.bashrc
Code:
export LC_ALL="en_US.utf8"
Code:
dpkg-reconfigure locales
Code:
dpkg-reconfigure console-data
Code:
dpkg-reconfigure keyboard-configuration
3.5 Installing additional software
You can now start installing additional software that you might need (I suggest you log into your phone through ssh as described above). You'll be needing an editor to edit configuration files (I choose vim). For setting up WiFi the package "wpasupplicant" is needed.
Code:
apt-get install vim less wpasupplicant
3.6 Chroot into debian
If you at a later time want to chroot into your debian environment, I recommend to store the following commands in a shell script (I stored it in /data/local/debian.sh) which you can then run as root.
Code:
#!/bin/sh
mount /dev/block/mmcblk1p1 /data/local/debian
for f in dev dev/pts proc sys ; do mount -o bind /$f /data/local/debian/$f ; done
chroot /data/local/debian /bin/bash
4. Create boot image
4.1 Build kernel
Perform the following steps on your PC:
Download the Galaxo kernel sources: git clone (FIX this url) https :// github . com/drakaz/GalaxoKernel.git
Apply the patch described on (FIX this url) https :// code . google . com/p/linux-on-android/wiki/BasicSteps (themddi_toshiba_smd.c patch doesn't work, do the change manually)
Apply patch as described here: (FIX this url) http :// sven . killig . de/android/console.html
copy attached config.txt file to .config
I will eventually create a branch on github containing the patches and default config. But for now, you'll have to do the patching yourself.
Code:
make ARCH=arm CROSS_COMPILE=/path/to/android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi- oldconfig
Code:
make ARCH=arm CROSS_COMPILE=/path/to/android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-
Code:
make ARCH=arm CROSS_COMPILE=/path/to/android/android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi- modules
4.2 Install modules
The modules need to be installed on the SD card partition, so you need to boot your phone into recovery and mount the SD card. Then execute the following command.
Code:
sudo make ARCH=arm CROSS_COMPILE=/path/to/android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi- INSTALL_MOD_PATH=/path/to/sdcard modules_install
In order for the WLAN kernel module to work the following files need to be copied from the GAOSP ROM to the /etc/ folder on the phone:
rtecdc.bin
nvram.txt
4.3 Minimal boot file system
A boot file system (a.k.a. initramfs) is needed to start the debian boot process. Create a folder called minimal_initramfs with the follwoing content:
Code:
minimal_initramfs/
|-- dev/
|-- init*
|-- mnt/
| `-- root/
|-- proc/
|-- sbin/
| `-- busybox*
`-- sys/
A binary of busybox can be downloaded from the busybox website (use busybox-armv4tl). The file "init" is actually a shell script with the following content:
Code:
#!/sbin/busybox sh
# initramfs pre-boot init script
# Something (what?) needs a few cycles here
/sbin/busybox sleep 1
# Populate /dev
/sbin/busybox mknod /dev/mmcblk1p1 b 179 9
# Mount the root filesystem, second partition on micro SDcard
/sbin/busybox mount -t ext2 -o noatime,nodiratime /dev/mmcblk1p1 /mnt/root
# Transfer root to SDcard
exec /sbin/busybox switch_root /mnt/root /sbin/init
The directory structure must then be compressed. To do this run the following sequence of commands when in the minimal_initramfs directory:
Code:
find . | cpio --quiet -H newc -o | gzip > ../minimal.cpio.gz
4.4 Creating the image
For creating the image you need the tool mkbootimg which you can find in android_bootimg_tools.tar.gz. Run the following command to create the boot image from the initramfs and the kernel you created above:
Code:
./mkbootimg --kernel /path/to/Galaxo-kernel/arch/arm/boot/zImage --ramdisk /path/to/minimal.cpio.gz --cmdline "fbcon=font:VGA8x8" --pagesize 2048 --base 10000000 -o debian_boot.img
5. Configuring network
5.1 Setting up the interface
Your /etc/network/interfaces file on the phone should look like this:
Code:
# Used by ifup(8) and ifdown(8). See the interfaces(5) manpage or
# /usr/share/doc/ifupdown/examples for more information.
auto lo
iface lo inet loopback
auto eth0
allow-hotplug eth0
iface eth0 inet dhcp
wpa-driver wext
wpa-conf /etc/wpa_supplicant.conf
5.2 Setting up wireless encryption
For network configuration we'll be using wpa_supplicant which we already installed in one of the above steps. On the phone create the file /etc/wpa_supplicant.conf with the following content. Please enter the correct values for ssid, psk and key_mgmt for your network:
Code:
network={
ssid="YourSSID"
psk="YourSecretPassword"
key_mgmt=WPA-PSK
priority=11
}
5.3 Loading drivers
In order for the WLAN kernel module to be loaded add the following line to /etc/modules:
Code:
bcm4325 firmware_path=/etc/rtecdc.bin nvram_path=/etc/nvram.txt
6. Flashing the boot image and booting into Debian
Now it's finally time to finally flash the previously created boot image. At this time, be sure that you only have your Galaxy connected to your PC. Otherwise you might brick any other connected phone. On the PC run
Code:
sudo fastboot flash boot debian_boot.img
Then boot the Galaxy into fastboot mode by pressing "call" when powering on the phone.
When the process is finished the phone will boot into Debian and automatically connect to your wireless network (if the set-up was correct). You can now connect to the phone through ssh and enjoy your new pocket server.
If you may ever want to boot into android again, you just need to flash the original boot.img that you created with nandroid:
Code:
sudo fastboot flash boot boot.img
7. Bluetooth
7.1 Compile brcm_patchram_plus
For getting bluetooth operational it is necessary to use Broadcom's brcm_patchram_plus software. As it is not available as a Debian Squeeze package, we need to compile it ourselves. So we need to install the following packages on the phone:
Code:
apt-get install git gcc make libbluetooth-dev
Then it's possible to download the sources:
Code:
git clone (FIX this url)https :// github . com / MarkMendelsohn / brcm_patchram.git
And compile the tool using:
Code:
make
7.2 Activating bluetooth
In order for bluetooth to work the following files need to be copied from the GAOSP ROM to the same folder on the phone that you compiled the brcm_patchram_plus in:
BCM4325D1_004.002.004.0153.0156.hcd
After that it's possible to execute the followig commands:
Code:
echo 0 > /sys/class/rfkill/rfkill0/state
echo 1 > /sys/class/rfkill/rfkill0/state
./brcm_patchram_plus -d --enable_hci --baudrate 3000000 --use_baudrate_for_download --patchram BCM4325D1_004.002.004.0153.0156.hcd /dev/ttyHS0
The last command will never terminate and you will get a lot of output due to the (-d) switch. After starting a new console, you will be able to scan for bluetooth devices using:
Code:
hcitool -i hci0 scan
7.3 Connecting a keyboard
I'm using a Rapoo E6100 keyboard and the following procedure worked fine for me. It should be similar with other keyboards.
Code:
apt-get install python-bluez python-gobject python-dbus bluez-compat
Code:
cd /usr/share/doc/bluez/examples
Press pairing button on keyboard then
Code:
./simple-agent hci0 6C:xx:xx:xx:xx:xx
(use the bluetooth address of your keyboard, according to the scan in the previous chapter)
The script will ask for a PIN. I entered 0000 on both the keyboard and phone and the keyboard was registered.
Code:
./test-device trusted 6C:xx:xx:xx:xx:xx yes
(again use the bluetooth address of your keyboard)
Code:
hidd --connect 6C:xx:xx:xx:xx:xx
Now you should be good to use your keyboard.
7.4 Automate patchram
Right now, the KB is not automatically connected on boot, because the patchram command from above needs to be executed on every boot. Hence the following commands should be added to /etc/rc.local (before the exit 0):
Code:
#Activate bluetooth
echo 0 > /sys/class/rfkill/rfkill0/state
echo 1 > /sys/class/rfkill/rfkill0/state
/path/to/brcm_patchram_plus --enable_hci --baudrate 3000000 --use_baudrate_for_download --patchram /path/to/BCM4325D1_004.002.004.0153.0156.hcd /dev/ttyHS0 &
8. Setting the clock
I was having trouble with my clock forgetting the day and time after each reboot. It was a flaw in my kernel config. In the current version of attached config file this is fixed. Anyway, I'm also running NTP to have the clock more accurate.
Code:
apt-get install ntpdate
NTP already come nicely pre-configured (thanks, Debian maintainers!). After that the timezone can be selected using
Code:
dpkg-reconfigure tzdata
9. GUI (X.org)
X.org works almost out-of-the-box since we already pathed the kernel as described in chapter 4 above. Based on the description from (FIX this url)https :// code . google . com/p/linux-on-android/wiki/BasicSteps only two minor changes have been made:
The framebuffer device is at /dev/fb0 instead of /dev/graphcics/fb0
I use evdev instead of tslib, because it provided better results for me (thanks to pabs from #debian-mobile for pointing me there)
9.1 Install X.org
All we need to do is download the software
Code:
apt-get install xorg xserver-xorg-video-fbdev xserver-xorg-input-evdev
9.2 Configuring X.org
Now create /etc/X11/xorg.conf:
Code:
Section "InputDevice"
Identifier "Touchscreen"
Driver "evdev"
Option "Device" "/dev/input/event2"
EndSection
Section "Device"
Identifier "Configured Video Device"
Driver "fbdev"
Option "fbdev" "/dev/fb0"
EndSection
Section "Monitor"
Identifier "Configured Monitor"
Option "DPMS" "false"
EndSection
Section "Screen"
Identifier "Default Screen"
Monitor "Configured Monitor"
Device "Configured Video Device"
EndSection
Section "ServerLayout"
Identifier "Default"
Screen "Default Screen"
InputDevice "Touchscreen" "CorePointer"
EndSection
Section "ServerFlags"
Option "DefaultServerLayout" "Default"
EndSection
9.3 Testing X.org
For testing X.org I've installed icewm and created the following /root/.xsession
Code:
#!/bin/sh
xterm&
exec icewm
Then just type in startx from the console and you have X. Of course you will have to change this to whatever you need or maybe even make X start on boot.
9.4 Boot into Browser
For my target system I want the phone to directly boot into a browser. This can easily be achieved by using the nodm package:
Code:
apt-get install nodm
and midori as browser:
Code:
apt-get install midori
We'll also need a user account. I called my user "default". But naturally you can of course choose whatever you like.
Code:
adduser default
Then nodm has to be configured in /etc/default/nodm:
Code:
# nodm configuration
# Set NODM_ENABLED to something different than 'false' to enable nodm
NODM_ENABLED=true
# User to autologin for
NODM_USER=default
# xinit program
NODM_XINIT=/usr/bin/xinit
# First vt to try when looking for free VTs
NODM_FIRST_VT=7
# X session
NODM_XSESSION=/etc/X11/Xsession
# Options for the X server
NODM_X_OPTIONS='vt7 -nolisten tcp'
# If an X session will run for less than this time in seconds, nodm will wait an
# increasing bit of time before restarting the session.
NODM_MIN_SESSION_TIME=60
And we have to create ~/.xsession for our user:
Code:
#!/bin/bash
midori -e Fullscreen &
exec icewm
A few tweaks in the icewm config (~/.icewm/preferences) will make the window manager look more nicely:
Code:
WorkspaceNames=" 1 "
TaskBarShowCPUStatus=0
TaskBarDoubleHeight=0
TaskBarShowWorkspaces=0
TaskBarShowMailboxStatus=0
TaskBarShowNetStatus=0
TimeFormat="%H:%M"
TaskBarShowWindowListMenu=1
TaskBarShowShowDesktopButton=0
10. Power management
The kernel is already configured with many different frequency govenors. Also the default govenor is set to "ondemand" but for some reason the when looking at /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor it's using the "performance" govenor. This can be solved by simply installing cpufreq-utils:
Code:
apt-get install cpufrequtils
The default settings are already using "ondemand", which seems to be a good choice. Anyway, further optimisations can be done in /etc/default/cpufrequtils if needed.
The phone still gets a little too warm for my taste (I think warmer than in android). Maybe there's something that could fix this, but I'm not an expert.
11. Known shortcomings
The whole set-up is in a really, REALLY early alpha stage
If any of the hardware buttons is touched in text mode the phone crashes (does not happen when in X.org)
The screen will time-out after some time, I have no idea how to wake it up again
Did I mention this is in an alpha stage?
12. Future improvements
Switching to a newer kernel version: The latest version of GAOSP runs on kernel version 2.6.35, while this guide is using 2.6.27. I have experimented with 2.6.29, but I had trouble getting a working frame buffer.
Switching to the latest version of debian (wheezy).

History
History:
2013-12-27:
Initial version
2013-12-30:
Minimized the the init script by removing mounts for /dev, /proc, and /sys. These are not necessary and mounting /dev prevents Debian's udev from working correctly.
2014-01-19:
Added description for bluetooth.
2014-01-25:
Added description for graphical user interface (X.org).
2014-01-25:
Boot into X/Browser and power management
2014-01-26:
Updated clock settings

Video proof
Hi all,
to get a better understanding what this is all about please watch the attached video. Please excuse the poor quality and the fingerprints on the screen.
As you can see the framebuffer output has a few quirks, but hopefully this will work out as soon as X is working.
BR,
Frank

All goals achieved
Okay, I think I now have achieved all goals. I can connect to WiFi and bluetooth. And there is a graphical user interface. Now the tweaking can start (first thing that comes to mind is powersaving). I really created this guide for myself, but I'd be happy to know if anyone else has interest in this topic.

Nice, I am interested. One question!
frank47 said:
Okay, I think I now have achieved all goals. I can connect to WiFi and bluetooth. And there is a graphical user interface. Now the tweaking can start (first thing that comes to mind is powersaving). I really created this guide for myself, but I'd be happy to know if anyone else has interest in this topic.
Click to expand...
Click to collapse
Nice, I am interested. One question!
I would like to use this device to get some data from the sensors. I have tested some apps in Android GAOSP to read the sensors in the i7500, but instead of using android apps, it could be very interesting to have a debian.
Have you tried to do it? Do you think it is possible? Is it too tricky to get a stable debian running an app to send sensors' data to another debian? I could help if you see it is interesting.
What is your opinion? Thank you...

Hi PabloGN,
there are a lot of entries in /proc and /sys. I think it's likely to be possible te access the sensors. For now, I have only looked at the battery status. Don't know if you'd consider that a sensor. Anyway, you would probably have to re-write your software to use those devices instead of using already existing Java libs for android. Hard to tell,*if it's worth the effort.
BR,
Frank

PabloGN said:
I would like to use this device to get some data from the sensors.
Click to expand...
Click to collapse
This is the list of input devices on my the i7500:
Code:
[email protected]:~# cat /proc/bus/input/devices
I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="I7500_headset"
P: Phys=
S: Sysfs=/devices/virtual/input/input0
U: Uniq=
H: Handlers=kbd event0
B: EV=3
B: KEY=4 0 0 0 0 0 0 0
I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="I7500_keypad"
P: Phys=
S: Sysfs=/devices/virtual/input/input1
U: Uniq=
H: Handlers=kbd event1
B: EV=3
B: KEY=800180 100000 0 41000800 1c1ec0 0 0 0
I: Bus=0000 Vendor=0000 Product=0000 Version=0033
N: Name="melfas-tsi-touchscreen"
P: Phys=
S: Sysfs=/devices/virtual/input/input2
U: Uniq=
H: Handlers=event2
B: EV=b
B: KEY=400 0 0 0 0 0 0 0 0 0 0
B: ABS=11000003
I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="compass"
P: Phys=
S: Sysfs=/devices/virtual/input/input3
U: Uniq=
H: Handlers=event3
B: EV=9
B: ABS=20305ff
I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="proximity_i2c"
P: Phys=
S: Sysfs=/devices/virtual/input/input4
U: Uniq=
H: Handlers=event4
B: EV=1
So, it should at least be possible to read the compass and proximity sensor data form /dev/input/event3 and /dev/input/event4. Maybe there's more and I just haven't compiled it into the kernel or it's accessed in some other way. Sorry, the sensors are not part of my use case so far.
I'm only using /dev/input/event2 (touchscreen) in my xorg.conf as an input device. Works like a charm.
Good luck with your endeavour. If you want me to test something or send you the output of some command, just ask here or by PM.

Restore your Baseband in MT65XX Devices

HOW TO RESTORE YOUR BASEBAND IF YOU LOST IT DURING A FORMAT - MT65XX DEVICES
Thanks go to abdullahi_ for this solution. His original post from another forum can be found below:
https://forum.hovatek.com/thread-116-post-376.html#pid376
Prequisites
Phone Rooted
Smart Phone Flash Tool Backup - Specifically protect_f file (for a Dual SIM phone, maybe different for a single SIM phone)
Linux OS - I used Ubuntu in a virtual machine
Android SDK platform tools for ADB access
From a terminal (CTRL + ALT + T)
Code:
mkdir -p ~/protect_f/f
cd ~/protect_f
At this point copy the file "protect_f" in the ~/protect_f
then continue:
Code:
sudo mount -t ext4 -o loop protect_f f/
Enter your password
then continue:
Code:
cd f
sudo chown -R $USER:$USER *
Copy the files in the f/md folder to a folder on your phone and using a file manager with root access copy the two files into the /protect_f folder or any toher means
NOTE: You will probably get back your cell access immediately. However, please continue to make the permissions and ownership are the same as the original.
Also if you have a dual SIM, one of the files from the protect_f folder will automatically be created in the protect_s folder
To clean up the files on the Linux OS:
Code:
cd ~/protect_f
sudo umount f/
cd ~
rm -rf protect_f
To change permissions and ownership on the files
From an adb shell for your phone:
Code:
su
cd /protect_f
ls -l
Take note of the ownership of the md folder, on the phone I used they were ccci & nvram, in Linux the ownership was 9996 & 9997.
At this point I put the phone in airplane mode, just as a precaution to make sure the rest went smoothly
Code:
cd md
chown ccci:nvram *
chmod 660 *
If you have a DUAL SIM phone, for the second folder....
Code:
cd /protect_s/md
chown ccci:nvram *
chmod 660 *
You can now take the phone off of airplane mode and reboot your phone to be sure it is working,
ALL DONE!

REMOVED

[guide]_[mtk]_[boot_modifications]

Thought id post today on how to set your SELinux to permissive on boot within your boot.img along with some other mods aswell
DISCLAIMER
Make sure you have at least basic knowledge decompiling boot.img & basic understanding of the files contained within, I will not be held responsible if you mess this up, following my instructions to the tee you will have no problems though,
PRE REQUISTES
* MTK extractor or similar program to decompile the boot.img
* Notepad ++
* A copy of your devices boot.img or BOOTIMG.file
* SP flash tool to flash boot.img to device
"alternatively you can add to a flashable zip if you have a custom recovery available for your device using android script generator here on xda-developers"
GUIDE
1. If your boot file is named BOOTIMG.file rename it to boot.img
2. Copy the boot.img to the program folder youll be using to decompile for this guide ill be using MTK extractor as it has a simple gui interface for all the newbs
3. MTK EXTRACTOR ONLY
Open mtk extractor application select the BOOT option from the left, in the bottom left you will see an off switch toggle it to ON
Click start at the top under unpack boot, in the mtk extractor folder will be your boot.img files
4. SETTING THE KERNEL TO PERMISSIVE
( PART 1 )
NOTE
Not all mtk devices are the same some can be set to permissive without the need for all the files using only some and some require all the files it depends on the kernel the device uses the extra files wont make a difference if anything will enforce the state even more
In this tutorial you will be using all the files to set the SELinux contexts to permissive to ensure it is enforced.
PART 1 - STEP 1.
open the INITRD folder then open your default.prop using notepad++
Set the following :
ro.secure=1 >
ro.secure=0
(This renders the boot.img insecure)
ro.selinux=0 >
ro.selinux=1
(NOTE) UBIFS MTK does not have this option
ro.security.perf_harden=1 > ro.security.perf_harden=0
(If you also want insecure adb)
ro.adb.secure=1 >
ro.adb.secure=0
(only newer mtk devices use this ro. Code )
ro.storage_manager.enabled=1 >
ro.storage_manager.enabled=0
Additionally if your device also has a low ram size you should add this to the default prop also to reduce the amount of ram usage while enabling high-end gfx also
# begin ram properties
# for low ram device to return true
ro.config.low_ram=true
# force high-end graphics in low ram mode
persist.sys.force_highendgfx=true
# ram inhaler
ro.HOME_APP_ADJ=1
# end ram properties
Now save and exit the default.prop
PART 1 - STEP 2.
Open your init.rc & init.charging.rc file with notepad++ scroll to the very bottom of the init.rc ( if you have init.target.rc add to this also)
Place this code exactly as shown
# SELinux
on property:/system/bin/setenforce $permissive u:r:kernel:s0
on property:selinux.echo $permissive > /sys/fs/selinux/enforce u:r:kernel:s0
on property:selinux.reload_policy=0
restart ueventd
restart installd
on property:selinux.setsebool debugfs 0
setenforce 0
setprop selinux.reload_policy 0
seclabel u:r:kernel:s0
Now save & exit the init.rc
PART 1 - STEP 3.
Open your fstab/s
To remove DM-Verity if present in your fstab look for the /system line & change to the following
/system ro wait,verify >
/system ro wait
Now look for /data then remove the force encryption of meta-data on data it will look something like this for exapmle
/dev/block/mmcblk0p2 /data ext4 nosuid,nodev,wait,forceencrypt=/dev/block/mmcblk0p3 ext4 /metadata >
/dev/block/mmcblk0p2 /data ext4 nosuid,nodev,wait
To remove encrypted footers from devices which use this instead of DM-Verity, change as follows using the example below,
/[email protected] /data ext4 noatime,nosuid wait,check,encryptable=footer >
/[email protected] /data ext4 noatime,nosuid, wait (check is optional & can be removed also if wanted)
PART 2 - STEP 1
( if you have init.target.rc already no need for this step)
open a new blank page in notepad++
On the first line add
On init
Space out 1 line so your now on line 3
Copy the #SELinux code we placed from init.rc to the new blank page, now save as init.target.rc
Do the above again but this time name it as init.kernel.rc
Now copy theese files to your INITRD folder
PART 2 - STEP 2.
open your init.rc & init.charging.rc once again
Add the following to the import section at the very top of the page,
import /init.kernel.rc
Import/init.target.rc
Save & exit now, your probably wondering why youve added so many files with the same code, on some devices it is necessary as i have found especially on NAND + UBIFS or JFFS2 devices.
PART 2 - STEP 3.
exit the INITRD Folder now open up the bootinfo.txt file
Change from the following
cmdline: >
cmdline: bootopt= androidboot.selinux=permissive
NOTE
FOR MT67**** 32 BIT DEVICES CHANGE FROM
cmdline: bootopt=64S3,32N2,32N2 >
TO
cmdline: bootopt=64S3,32N2,32N2 androidboot.selinux=permissive
FOR MT67**** 64 BIT DEVICES CHANGE FROM
cmdline: bootopt=64S3,32N2,64S3 >
TO
cmdline: bootopt=64S3,32N2,64S3 androidboot.selinux=permissive
Now save & exit the bootinfo.txt
PART 2 - STEP 4
open the cpiolist
Add the following at the bottom or add wherever dosent matter as long as its there
file init.kernel.rc initrd/init.kernel.rc 0750
file init.target.rc initrd/init.target.rc 0750
(Add this option only if you origninally didnt have the init.target.rc file)
Save & exit the cpiolist.
PART 2 - STEP 5
Recompile & flash if you did everything right youve now got an insecure boot.img without dm-verity encryption or data footer enceyption, with insecure adb & SElinux set as permissive,
To make sure its permissive go into settings and about device then scroll to bottom you should now see it,
If you found this useful you know where the thanks button is.

Matty1993 said:
Open your fstab/s
To remove DM-Verity if present in your fstab look for the /system line & change to the following
/system ro wait,verify >
/system ro wait
Now look for /data then remove the force encryption of meta-data on data it will look something like this for exapmle
/dev/block/mmcblk0p2 /data ext4 nosuid,nodev,wait,forceencrypt=/dev/block/mmcblk0p3 ext4 /metadata >
/dev/block/mmcblk0p2 /data ext4 nosuid,nodev,wait
To remove encrypted footers from devices which use this instead of DM-Verity, change as follows using the example below,
/[email protected] /data ext4 noatime,nosuid wait,check,encryptable=footer >
/[email protected] /data ext4 noatime,nosuid, wait (check is optional & can be removed also if wanted)
Click to expand...
Click to collapse
Hi Matty1993,
These are also in dtb of the kernel which I think may cause some issues if not removed. Magisk normally removes it from /system but on newer Android versions 8.0 > 8.1 /vendor is also wait,verify by default.
To edit these yourself you need a good hex editor and replace the ",verify" with zero bytes do not just delete it or type zero's or it will not boot.
I have not seen any forceencrypt in the dtb of the boot.img's I have seen as yet.

bigrammy said:
Hi Matty1993,
These are also in dtb of the kernel which I think may cause some issues if not removed. Magisk normally removes it from /system but on newer Android versions 8.0 > 8.1 /vendor is also wait,verify by default.
To edit these yourself you need a good hex editor and replace the ",verify" with zero bytes do not just delete it or type zero's or it will not boot.
I have not seen any forceencrypt in the dtb of the boot.img's I have seen as yet.
Click to expand...
Click to collapse
Wow i didnt even see this till now i need an assistant or something to organise and mark all my threads because im useless at it haha anyhow maybe could be a vendor related thing then as mine has all the info in dtb of kernel aswell as i was able to remove just "verify" from system and metadata completely and got it to boot.
I also found an easier way to get kernel permissive also as my first older method dosent seem to work with newer mtk models but my newer method works across most mtk platform from mt6572 up to mt6737m
What i did is decompiled my twrp i built for the same phone and copied the busybox applet from /sbin in the initrd then decompiled my boot.img added it to sbin gave it necessary permission of 04555 in the cpiolist whilst i had cpio list open i added below "file init initrd/init 0750"
"file init2 initrd/init2 0750" then went back to the initrd and changed the name of the "init" file to "init2" opened notepad++ to a new page and added the following
#!/sbin/busybox sh
cd/
/sbin/busybox mkdir /tmp
/sbin/busybox mount -t tmpfs tmpfs /tmp
/sbin/busybox mount -t proc proc /proc
/sbin/busybox sed -e 's/printk\.disable_uart\=1/printk\disable_uart\=1 androidboot\.selinux\=permissive/' /proc/cmdline > /tmp/cmdline
/sbin/busybox mount --bind -o -ro /tmp/cmdline /proc/cmdline
/sbin/busybox settings put global captive_portal_detection_enabled 0
/sbin/busybox chmod 755 /init2
/sbin/busybox mv /init2 /init
/bin/su settings put global captive_portal_detection_enabled 0
exec /init
All i did then was save it under the name .init to the bootimg directory then remove the "." from the file name so that it became init.file instead of .INIT format file
After that opened up the bootinfo.txt and added under cmd=bootopt=androidboot.selinux=permissive
Recompiled bootimg and had no dramas so thought id chuck it up here in case anyone else couldnt get there kernel to setenforce 0 through /bin/setenforce or any other way youve tried on these newer mtk models, do remember though results may vary this may or may not work for everyones device, no this will no permanently brick your device doing this if it dosent work you will simply still have an enforcing kernel. Have fun all

Help
tell me how to do selinux = permisive on my firmware and all permissions? Google search does not help. Doogee bl9000 Android 8.1 kernel 4.4.95+ Please help.

waryag said:
tell me how to do selinux = permisive on my firmware and all permissions? Google search does not help. Doogee bl9000 Android 8.1 kernel 4.4.95+ Please help.
Click to expand...
Click to collapse
Hey bud sorry for late reply,
What board make type is it running 6580, 6735/6737 or 6763/6737 depending on which it should be pretty straight forward to get you unlocked and what not as your BL will be by default locked down either way on 6580 or 67xx
I dont recommend you pushing permissive selinux on 8.1 however as this will compromise your security integrity what were you looking to do anyhow regarding permissive selinux,
Rooting or custom recovery ??