[Announce] SIMLock - A SIM card based locking daemon - Page 3 - maemo.org

SPARTAN563 | # 21 | 2011-06-20, 13:44 | Report

Okay, SIMLock is now in the autobuilder que, will let you all know if/when it is in extras-devel.

As for the idea of locking your phone when an app is started, it isn't the actual UI part that would chew battery power (since that would only be visible for as long as it took you to enter your code in the first place) but rather the background daemon which would have to do something like this (since there doesn't appear to be a DBus signal for "app launched"):

Code:

QList<QString> runningUnlocked;

while(!exit) {
  //Get a list of all the running apps on the phone
  QList<QString> runningApps = GetRunningApps();

  //Loop through them and find out if they are locked, and if they have been unlocked by the person unlocking the phone
  for(int i = 0; i < runningApps.length(); i++) {
    if(IsLockedApp(runningApps[i]) && !runningUnlocked.contains(runningApps[i])) {
        LockPhone();
        WaitForUnlock(); //We don't want to keep calling the lock function while the phone is locked, so wait for it to unlock
        runningUnlocked << runningApps[i]; //Add the app to the list of unlocked ones (temporary)
        continue;
    }

    //Remove any of the apps that were running unlocked but have been closed
    for(int i = 0; i < runningUnlocked.length(); i++) {
       if(!runningApps.contains(runningUnlocked[i]))
          runningUnlocked.removeAt(i);
    }
  }
  sleep(5);
}

Which means that every 5 seconds (less if you wanted to reduce the chance of someone performing that race hack I spoke about) it is gonna have to grab all your running apps, check them against a database of your locked apps, and then if it finds a locked app that is busy running it locks the phone. But each time it has to do that it will be chowing CPU cycles. So in order to lower that you would make it only check while the phone is in an "active" state (i.e. unlocked, the kind that is done with the lock switch). But that still will chew power while the phone is in an active state.

If you'd like though, I'll code it up in Qt, should make it a little less power hungry than if it were in Python.

As for keeping it running after a killall command, you could just use an event.d script that would restart it continually until the phone was turned off.

EDIT: Okay, package has been built by the Autobuilder and should appear in extras-devel relatively soon. I will update this and the first post when it has been uploaded there correctly.

EDIT2: Package is now available in extras-devel

Last edited by SPARTAN563; 2011-06-20 at 14:50.

The Following 2 Users Say Thank You to SPARTAN563 For This Useful Post:
shawwawa, warhawk007

SPARTAN563 | # 22 | 2011-06-20, 16:40 | Report

Version 0.5.0 released on Extras-Devel, adds the following console commands as well as fixing an upgrade issue from <=0.3.0
--add [IMSI] : Adds an IMSI to the database
--remove [IMSI]: Removes an IMSI from the database

Neither of these commands is documented yet however, not sure if they should be included so I'll let you guys decide and remove them if you think they aren't worth it.

The Following User Says Thank You to SPARTAN563 For This Useful Post:
F2thaK

warhawk007 | # 23 | 2011-06-20, 17:23 | Report

Originally Posted by SPARTAN563 View Post

Okay, SIMLock is now in the autobuilder que, will let you all know if/when it is in extras-devel.

As for the idea of locking your phone when an app is started, it isn't the actual UI part that would chew battery power (since that would only be visible for as long as it took you to enter your code in the first place) but rather the background daemon which would have to do something like this (since there doesn't appear to be a DBus signal for "app launched"):

Code:

QList<QString> runningUnlocked;

while(!exit) {
  //Get a list of all the running apps on the phone
  QList<QString> runningApps = GetRunningApps();

  //Loop through them and find out if they are locked, and if they have been unlocked by the person unlocking the phone
  for(int i = 0; i < runningApps.length(); i++) {
    if(IsLockedApp(runningApps[i]) && !runningUnlocked.contains(runningApps[i])) {
        LockPhone();
        WaitForUnlock(); //We don't want to keep calling the lock function while the phone is locked, so wait for it to unlock
        runningUnlocked << runningApps[i]; //Add the app to the list of unlocked ones (temporary)
        continue;
    }

    //Remove any of the apps that were running unlocked but have been closed
    for(int i = 0; i < runningUnlocked.length(); i++) {
       if(!runningApps.contains(runningUnlocked[i]))
          runningUnlocked.removeAt(i);
    }
  }
  sleep(5);
}

Which means that every 5 seconds (less if you wanted to reduce the chance of someone performing that race hack I spoke about) it is gonna have to grab all your running apps, check them against a database of your locked apps, and then if it finds a locked app that is busy running it locks the phone. But each time it has to do that it will be chowing CPU cycles. So in order to lower that you would make it only check while the phone is in an "active" state (i.e. unlocked, the kind that is done with the lock switch). But that still will chew power while the phone is in an active state.

If you'd like though, I'll code it up in Qt, should make it a little less power hungry than if it were in Python.

As for keeping it running after a killall command, you could just use an event.d script that would restart it continually until the phone was turned off.

EDIT: Okay, package has been built by the Autobuilder and should appear in extras-devel relatively soon. I will update this and the first post when it has been uploaded there correctly.

EDIT2: Package is now available in extras-devel

Wow..thanks for your quick response. So if Qt is more CPU or battery efficient. Could you code it in qt and release it for testing?
I'm sorry if I seem too desperate, but this is an application I really wanted on Maemo. All other platforms have apps like this and I've been requesting for such an app since I bought my N900 last year. I never got a satisfactory response till now. But when you said you could do it, my hopes are up high again. I'm patiently waiting for a release.
Thanks again. Cheers!

SPARTAN563 | # 24 | 2011-06-20, 17:42 | Report

Hi, it should be since it will compile to native code (doesn't have to run through an interpreter). That being said it will still chow battery until I can get it to stop intelligently.
Am in the process of coding up an early version now, hopefully it will be ready for early testing in a few days time. Also, since I am coming from a Windows/.NET background it will take a bit of fiddling to figure out how to get a list of running processes (looks like I'll have to make use of /proc) but once that is done it shouldn't be too hard.
May also consider making it have some DBus calls so you can pause it or start it using a shortcut or something on your desktop (you could call the lock thing anyway when you do so just to prevent them from doing it themselves) which would prevent it from sharpening its claws on your precious battery

Will let you know when I have something to show for it.
Regards,
SPARTAN563

F2thaK | # 25 | 2011-06-21, 01:42 | Report

this has changed name too...... thanks for update!

SPARTAN563 | # 26 | 2011-06-21, 06:23 | Report

Correct, went from simlockd to simlock. Figured that since it was now a commandline app the d suffix was no longer appropriate.
Everything else however should function the same as it did before.

F2thaK | # 27 | 2011-06-21, 08:11 | Report

seems that way

SPARTAN563 | # 28 | 2011-06-21, 17:59 | Report

Version 0.6.0 released on Extras-Devel

Changes are as follows:
* Fixed the folder ~/.simlockd being created when it wasn't needed
* Rewrote help text to make it easier to read
* Added shortcuts for --add, --remove, --show and --clear commands
* Rewrote event.d script, removed chmod calls, better startup time
* Rewrote README file to add information about how to use SIMLock
* Removed unnecessary debug code from the --show command
* Lots of memory leaks have been fixed (wouldn't have been noticed)

EDIT: Recommend you do not upgrade to 0.6.0 as it introduces a crash which stops the application's daemon from functioning correctly. v0.6.1 which rectifies this issue will be released within the next 45 minutes

Last edited by SPARTAN563; 2011-06-22 at 06:08.

The Following User Says Thank You to SPARTAN563 For This Useful Post:
F2thaK

SPARTAN563 | # 29 | 2011-06-22, 08:00 | Report

Version 0.6.1 released in Extras-Devel

Fixes a crash introduced in version 0.6.0
Fixed a spelling error in the debug output printed by the daemon

The Following User Says Thank You to SPARTAN563 For This Useful Post:
F2thaK

F2thaK | # 30 | 2011-06-22, 08:29 | Report

v .6.1 update not showing for me...........?