yashsingh1/xdaforums huggingface dataset:
[Off-topic] prototype7:
I think there's another button that needs to be brought to your attention. It's called the shift key. Use it less.
[Off-topic] LordManhattan:
I do also thank devs and people that deserves it; and funny people. I will however not thank people that asks for it.

On another note, OP, your post is "hard" to read when you're throwing those upper cases all over the place. It ruins the the "reading flow". There's no reason to do it at all.
[Off-topic] VaderSKN:
LordManhattan EDIT: This is the useless post.
[Off-topic] LordManhattan:
He was talking to the OP.
[Off-topic] TeeJay3800:
Although the OP has a valid point, I'm going to close this before it gets out of control.

Although it's been fun reading the posts so far so maybe I'll leave it open....

Nah, closed. :silly:
[Android Software/Hacking General [Developers Only]] loadedmind:
Hey all. First time posting here. To get the technical data out of the way, I'm currently running an AT&T-flavored Samsung Galaxy S2 SGH-i777 (not sky) with the Cyanogenmod root @ ICS ver 4.0.4. The Cy mod is 9.1.0-i777.

Before I dive into the deep-end of developing a solution, I wanted to ensure a project doesn't already exist to address what I (IMHO) consider to be an issue - privacy and general Google distrust. Please don't take offense if you're a Google fanboy and please don't tell me Google is my only option.

While I realize I can choose to merge [or not] contacts and other data with Google, has someone GA'ed an open source (or otherwise) method to use one's own server or personally-controlled cloud-based option for synchronizing personal information? Perhaps somehow tying in an existing IMAP account (like a Horde API for lack of a better similarity explanation) with an rsync engine at the server for push/pull abilities?

I researched SyncML, but it seems that I would only be able to incorporate its code into a more top-level coded solution for alternative syncing methods.

Thanks for any/all feedback.

Regards.
[Android Software/Hacking General [Developers Only]] loadedmind:
No one?

So I'm guessing either no one else has thought about a third-party handling your information and doing something about it or just plain apathy?
[AT&T Samsung Galaxy S II SGH-I777] Virus1x:
I didn't seem to find anything on this but does it have a built in call blocker? I'm fairly sure it's a tw feature and if so anyone know a half decent call blocker that isn't **** and works

Transmission Terminated.
[AT&T Samsung Galaxy S II SGH-I777] clay101eve:
I hate you... that is all.

Obviously I don't really hate you, but I don't have an answer and wanted to bump this for you.

Clay

Team Pirate

Sent from my Buttery Smooth PINK SGH-i777
[AT&T Samsung Galaxy S II SGH-I777] 122ninjas:
I just made a contact called Blocked. Put any numbers you don't want in there then hit settings and make it so it automatically goes to voicemail

Sent from my SGH-I777
[AT&T Samsung Galaxy S II SGH-I777] Eternalty:
Hah never thought of that. Pretty cool

Team Pirate

Sent from Pirateghost's house
[AT&T Samsung Galaxy S II SGH-I777] clay101eve:
Team Pirate wins again eh Ninja?

Clay

Team Pirate

Sent from my Buttery Smooth PINK SGH-i777
[AT&T Samsung Galaxy S II SGH-I777] 122ninjas:
:D

Sent from my SGH-I777
[AT&T Samsung Galaxy S II SGH-I777] clay101eve:
...

Ninja Pirate anyone?

Clay

Team Pirate

Sent from my Buttery Smooth PINK SGH-i777
[AT&T Samsung Galaxy S II SGH-I777] 122ninjas:
I'm part of the society??

Sent from my SGH-I777
[AT&T Samsung Galaxy S II SGH-I777] Eternalty:
Team Pirate

Sent from Pirateghost's house
[AT&T Samsung Galaxy S II SGH-I777] clay101eve:
Not with a Sig like that...

Clay

Team Pirate

Sent from my Buttery Smooth PINK SGH-i777
[AT&T Samsung Galaxy S II SGH-I777] 122ninjas:
Ahem... gentlemen

Sent from Team Pirate's Transmitter Thingy
[AT&T Samsung Galaxy S II SGH-I777] Phalanx7621:
What did u call us?!?!
[AT&T Samsung Galaxy S II SGH-I777] 122ninjas:
Tf2 reference. Ahem.. Piratemen

Sent from Team Pirate's Transmitter Thingy
[AT&T Samsung Galaxy S II SGH-I777] Eternalty:
Hah we got us the world's first ninja pirate. In your face :D

Team Pirate

Sent from Pirateghost's house
[AT&T Samsung Galaxy S II SGH-I777] clay101eve:
... who is "us"?

I don't see anything about you being Team Pirate, Phailanx...

Clay

Team Pirate

Sent from my Buttery Smooth PINK SGH-i777
[AT&T Samsung Galaxy S II SGH-I777] Virus1x:
How does one become a pirate

Transmission Terminated.
[AT&T Samsung Galaxy S II SGH-I777] 122ninjas:
You download stuff off the internet that you normally pay for

Sent from Team Pirate's Transmitter Thingy
[AT&T Samsung Galaxy S II SGH-I777] Pirateghost:
But you have to be a ghost so you don't get caught

;)

Raise yer mizzenmast and swab 'er poop deck!
[AT&T Samsung Galaxy S II SGH-I777] Virus1x:
Lol Google my username on Google haha I'm about as pirate as it gets

Transmission Terminated.
[AT&T Samsung Galaxy S II SGH-I777] clay101eve:
All I see is back reports and scam logs...

Clay

Team Pirate

Sent from my Buttery Smooth PINK SGH-i777
[AT&T Samsung Galaxy S II SGH-I777] 122ninjas:
LOL

Sent from Team Pirate's Transmitter Thingy
[AT&T Samsung Galaxy S II SGH-I777] Virus1x:
Hack forums number one coder and pirate

Transmission Terminated.
[Android General] mod23:
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:

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:

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.
[Android General] matthias24:
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"
[Android General] matthias24:
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.
[Android General] -Android Freak-:
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!
[Android General] jemandanders:
Thank you very much mod23! My phone is finally usable again :)

Works as described on Galaxy R with leaked ICS.

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
[Android General] lolo250612:
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 034521

4

7, 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 :D

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.:rolleyes: 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://xdaforums.com/showpost.php?p=26730989&postcount=2.

And, something that people may forget, always double check that

USB debugging is disabled

.
[Android General] matthias24:
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.
[Android General] lolo250612:
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
[Android General] Fmstrat:
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.

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
[Android General] gadsden:
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:

('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.
[Android General] Fmstrat:
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
[Android General] gadsden:
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.
[Android General] gadsden:
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.
[Android General] gadsden:
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.

I looked and could not find this, so I proceeded as described.

(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.
[Android General] gadsden:
Bumped for help!
[Android General] Fmstrat:
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
[Android General] gadsden:
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.
[Android General] gadsden:
Been working on this for a whole week now, just wondering if I'm even on the right track here?
[Android General] zedawg:
thx
[Android General] gadsden:
Anyone able to help me on this?
[Android General] mod23:
Sorry mate, but I use Unix. That's why this recipe is a guideline for Unix people. If you work on Windows, Cygwin or Ubuntu in a virtual machine might be a solution. I mean, you spent a week on this and didn't look up what "mv" does. If you did, you would have found out that it belongs into the Unix world while you use Windows. If you want to get to know Android, you won't get around learning to use Linux, btw.

Oh, and your nagging really didn't improve the politeness of my reply. I'm sorry, but I disabled notifications for this thead because of this.