Archive for September, 2012
It’s been widely reported today that the Samsung Galaxy S3 and other Samsung Galaxy phones have a glaring vulnerability: a webpage can trigger the Samsung dialer to dial a code which wipes the phone.
I wanted to see if this was really true, so I thought I’d knock up a proof of concept using a much safer short-code, *#*#4636#*#*, which, if entered in the dialler, will take you to a testing / control menu where you can change various device settings (it’s useful to know about that hidden trick – but don’t change things unless you know what you’re doing).
So, I created a testmenu.html containing a frame which attempts to load tel:*#*#4636#*#*; it does indeed call up the dialler, but does not appear to actually trigger the test menu. (This debug code doesn’t require you to push send to confirm it – when you type the last “#”, the menu pops up – this is one reason I chose it as a test, as I assume that the problem with the wipe code (which I’m not testing out on my phone!) is that it works the same way (that, or people push to dial it, not knowing what will happen.)
Next, I decided to try a code that does need you to push send – *#100#. which typically returns your phone number. I created ownnumber.html. Loading that page in my Galaxy Note’s stock browser does indeed launch the dialler again – this time, though, the code *#100# is displayed, ready to be “dialled” if the user desires. This is the behaviour I’d expect from anything that links to tel:$number – the user to be asked for confirmation before placing a “call”.
Is it just that the Galaxy Note doesn’t have the same problem, or is there something special about the “wipe device” code?
Is, perhaps, the test menu code “executing”, but invisibly?
I am somewhat disturbed that Samsung modified the stock browser to support tel: URLs; I could see them being mildly useful for actual links to click to bring up the dialler, but using them as the source for a frame / image would never make sense.
(For what it’s worth, this is a Samsung Galaxy Note (GT-N7000) running Android 4.0.4, on UK Vodafone.)
A few times I’ve wanted to extract part of a large monolithic Subversion repository out into a seperate Git repo, but maintain the commit history.
Here’s how I do it.
First, I set up a mapping of Subversion user => Username
davidp = David Precious
Now, I clone the entire Subversion repo via git svn into a new git repository:
# Clone the Subversion repo into a new Git repo:
# (~/subversion_authors.txt is file mentioned above)
git svn clone file:///shared/svn/scripts --no-metadata -A ~/subversion_authors.txt tmp/scripts-repo-tmp
Some tags get added during this process, I believe; I don’t need/want to preserve them, so I remove any and all tags:
# remove tags - we don't need them
git tag -l | xargs git tag -d
Now, the clever part; using git filter-branch to select the path within the repo I want to preserve, and remove everything else, promoting the desired path to the “root” of the repository:
# remove all except a given path:
git filter-branch --tag-name-filter cat --prune-empty --subdirectory-filter path/to/desired/dir HEAD
In the above, path/to/desired/dir is the path within the repo that I want to move to the root of the repo; everything else will be discarded.
At this point, I can add a GitHub repository via git remove add origin $url, and push the new repository.
I *think*, because I pushed to GitHub, then deleted my temporary repo and cloned back down, that unrelated previous commits were automatically removed. In case that’s not true, though, the following ought to purge unrelated commits from the new Git repo:
git reset --hard
git for-each-ref --format="%(refname)" refs/original/ | xargs -n 1 git update-ref -d
git reflog expire --expire=now --all
git gc --aggressive --prune=now