Hacker News new | comments | show | ask | jobs | submit login
USSD code to factory data reset a Galaxy S3 can be trigged from a HTML page (exquisitetweets.com)
295 points by EwanToo on Sept 25, 2012 | hide | past | web | favorite | 174 comments

Hello. I'm the guy who put this collection together. I've since tried to update it, and to hit 'delete' on it to avoid spreading misinformation, but Exquisite Tweets is still caching the original version. Mea culpa: I didn't do the research before passing it on.

There's been a lot of back-and-forth over whether it's true or not (check @pof's timeline for such), and a hell of a lot of people sending it on without double-checking. Myself included.

There is clearly a big security bug here (see the video linked), but it's extremely questionable as to whether it can be activated from a web page or whether it requires a bit of social engineering too!

[Edited to add: and just as I write this, @jwheare has cleared the cache and fixed the bug in Exquisite Tweets. Hopefully that should nip this in the bud.]

I tried reproducing it using a "USSD" that works on my venerable Nexus One (radio debug - * # * # 4636 # * # *), but on entering dialler app the input box is empty. This might simply mean the debug activity was started and got focus before the dialler app had its focus set, so if another such code triggered factory reset, might definitely still work.

I wrote a trivial webpage (using the show IMEI USSD * #06#), served from my desktop with Lighttpd. It certainly can be executed via a simple web page using a frameset on both Chrome & Browser, and there's no prompt. Works on a Huawei running 2.3, a Galaxy S2 running ICS, and an HTC.

I created an Android app to intercept these requests and prevent them. https://dl.dropbox.com/s/28lk6rn09x84qqg/AutoResetBlocker.ap...

Please test it and make sure it works for you.

  1. Open the above link on your phone
  2. Install the application (it requires no special permissions)
  3. Try this IMEI test: http://jsfiddle.net/kKFn8/
  4. Check the box to make "Auto-Reset Blocker" the default action
  5. Auto-Reset Blocker will show you the malicious number
  6. Open this safe telephone number test: http://jsfiddle.net/tLHpw/
  7. Auto-Reset Blocker will show the safe number and you will be asked which dialer to use
  8. Select your normal dialer
  9. Your normal dialer will open with the safe number
Again, please give it a try. If people like it, I will see about setting up an Android Market account to distribute it.

I tested it with my S2 and it works, but I had to put the files in a local web server because for some reason, the malicious code didn't work from jsfiddle.net

So I did the following:

  1- I tested the link provided by kristofferR (http://kristofferr.com/samsung.html).
  2- Made 2 local copies
  3- Edited one of the copies, replaceing the IMEI code with a normal phone number.
  4- Placed both files in a local web server.
  5- Accesed the files from my phone, and got the expected results with your App.

Works great. However, the immediate select app popup if it's "safe" means that the "This phone number appears safe" text is shadowed on my phone. Perhaps add a "dial" button?

Still, please set up a Market account, this would be great!

I submitted a new version incorporating your suggestion. It should be on the market in a couple hours. :-)

Thank you everyone for your feedback! I published my application on Google Play. https://play.google.com/store/apps/details?id=net.gicode.and...

It is still rough on the eyes, but it serves the intended purpose.

This seems to work, but I couldn't get the JSFiddles to make it trigger.

May I suggest pointing people to a simple webpage (like http://kristofferr.com/samsung.html) maybe more user-friendly?

Yeah, I am not sure why the JSFiddle would work on one phone and not another, but it is definitely an issue.

I might try putting tel: links (for people to tap on) directly into the marketplace description.

Your site works on my S2. Please don't change the test number ;)

Please add this to Google Play store so its more trustworthy and easier to access.

Thanks, works as intended on my S3. Any chance of releasing the source code though?

Thanks for asking. That is the plan. I just need a bit more time to make it presentable.

Page text was:

    the USSD code to factory data reset a Galaxy S3 is *2767*3855# can be
    triggered from browser like this: <frame src="tel:*2767*3855%23" />

Looks like OP decided to pull this down to minimize damage. Makes me wonder was this a 0-day or he informed Samsung first.

does that mean premium rate numbers can also be triggered?

I don't have a Galaxy S3 to test this, but my experience with the Galaxy S and Galaxy S2 is that for normal phone numbers, you need to specifically confirm that you want to dial the number. For the code to factory reset the phone, though, simply typing in the code is sufficient, you don't need to press dial. It might be the same here, so that only that specific USSD code can be triggered without a confirmation from the user.

Yes, this is how it works. I tested a Galaxy S2 and HTC with Chrome and the stock Browser - both spawn the dialler and pass the code which triggers automatically on the terminating '#'.

The special feature of these "pseudo USSD" codes on Android is that you don't have to press the call button. Simply typing the digits is enough. Note I have no idea if this particular attack actually works.

This predates Android by years. Special "phone number" codes have been used to control firmware since the very first compute went into a phone. The reason is fairly clear: in the early devices, dialing a number was the only UI metaphor available. USSD itself is actually a standard, such as it is: http://en.wikipedia.org/wiki/Unstructured_Supplementary_Serv...

Now, of course, it's just a bit of legacy nonsense that gets left enabled simply because it's part of an existing workflow and serves mostly as a hidden gotcha for people doing security analysis.

In this case, the USSD is not the bug. The fact that it can be triggered from HTML and cause a factory reset without user interaction is the bug. At least with older phones, after entry, it was necessary to hit dial before any effect was taken.

That's true, but sort of missing my point. Security bugs are very rarely "security bugs" in isolation. They're far more often unexpected interactions between subsystems. Here, the expectation of the browser is that it can fire a "phone number" Intent securely, because the dialer app will handle it. But the phone number intent also happens to hook to the USSD layer. It's not USSD's "fault", as the check needs to be in the browser according to the architecture. But USSD remains a booby trap because it's an unexpected legacy feature with surprising security behavior.

I don't think it's "android feautre", I've seen this on a few non-smart phones in the past. I don't know which one though as I owned few of them over the years.

It's not the end of the world though. You're browsing on your android phone and suddenly it dials an unexpected number and you can see that it starts 900XXXXXXX or 976XXXXXXX. Most people are going to hang up pretty quickly. Sure, you might be out of pocket for up to $10 (I don't actually know how much mobile carrier charge for the connection charge), but it's not the same as losing all your data.

A more common attack vector to make money on compromised accounts would be setting up a call forward to an international number and then dialing the subscribers phone number. Illegal low cost calling cards often steal service by doing this. If there was a way to also retrieve the user's phone number, I can imagine a system where you dial the calling card company, input your code and the number you want to dial.... It tells you that it's trying to connect you and that it may take a couple of minutes... It snares the next person caught out on the website, sets their call forward to the number you want to dial, then dials that subscriber for you and connects. So then it's charging the wireless subscriber for your international call, and even if they then disable the call forward on their account, until you hang up, it's still charging them for the call forward.

If I was really bored and feeling malicious, printing QR codes to point to this "exploit" and then pasting them over QR codes on random advertisements in the streets seems like a terrible idea.

It wouldn't affect anyone because no one has ever scanned a QR code in an ad

I chuckle every time I see this.

But good sir, it's empty!

This will never stop being funny

My 6 year old daughter is absolutely fascinated by QR codes. I've been nagged into scanning ones on posters, in magazines, and even one that showed up in the middle of a TV show...

I have a six year old son with this same fascination. Sometimes I'll walk into my home office and find some mailer with a QR code sitting there waiting for me. His inquisitive mind just has to know what the phone will do with the code.

You can pick up barcode battlers on ebay for cheap. Although they're probably antiques now.

I've got some somewhere, but I don't think they did QR codes and they certainly didn't launch a link - that's what she enjoys. No idea why, but I'm not going to discourage her from anything that gets her interested in technology. We're going to get a t-shirt printed for her with a QR code saying "If found, please ring [phone number]".

First thought: this might be a neat Android game Second thought: this has already been implemented



(by the way, this displays in an awful Spanish for me, because of my default language)

I do mountain bike (and thus indirectly hiking) trail development, construction, and maintenance as volunteer work. This has shown me a surprisingly useful place for QR codes: on trailhead map boards. The code just links to a (well optimized) PDF of the map itself, along with some text that says "Scan this with your phone to download a copy of the map.".

It amazes me how many people I see scanning the QR code to get a copy of the map before they head out on the trails.

Every Android phone in Japan would be wiped out in a matter of hours. I see people scanning them in Tokyo constantly.


I actually found them quite useful as a bookmarking tool when comparison shopping appliances at retail stores. They usually had code to the retailer's page for the appliance, and another for the manufacturer's page.

I've yet to scan one of these codes, or see anyone scanning one. It seems like something from the 90s just came back for one last dying breath.

I was in a British train station the other day and saw a poster containing 20 QR codes, one for each of a set a possible journeys from the station. Since I'm techy and had time to kill I scanned it, waiting to see the timetable information. Sadly the company who installed the posters was having some downtime, so it just errored. The annoying thing was that they were really just a URL shortening company, forwarding you on to the correct mobile friendly page of the trainline website. I really don't know why the trainline couldn't have just made some nice short, typing friendly short URLs of their own, and posted these on the poster. Or just posted the actual time tables like they used to. In the olden days.

Whilst scanning it and trying to figure out what was wrong, the station master approached me to see what I was doing - since the poster had been installed he'd yet to see anyone use it, and had been waiting to ask someone what on earth it was for.

Still - if there is someone out there that wanted to hack me, they just have to place a qr code in a place where I am likely to have nothing to do for a while... At least with this poster it was actually easy to scan the codes, unlike those on billboards or posted on the tube here in the UK.

My local bus company has failed to grasp QR codes in a mind-bogglingly thorough way.

Every stop has a poster with a QR code on it, advertising that you can now look up when the next bus will be here by scanning the QR code. The first thing you might notice is that the poster is actually a photo of a QR code on a poster, and is taken at an angle sufficient to render scanning the QR code impossible.

The second thing you might notice is that all the posters are identical - they are, in fact, an advert for the QR code you are meant to scan and not the QR code itself.

So where are these QR codes? Somewhere else on the bus stop? On the post for the sign? No. Reading the smaller print on the poster reveals all: You simply visit their website on your PC and go to a specific URL, which delivers you a page full of QR codes. You then scan the QR code corresponding to the bus stop whose schedule you wish to view.

Couldn't be easier!

Maybe they got the idea from Google Code, which helpfully shows me a QR code for the tarball I'm about to download, for all those times I'm using the browser on my desktop and the IDE on my phone.

It's a QR code of the tarball's hash, so you can do an easy (albeit less secure) visual verification instead of comparing two text strings.

uh what? So I download the file, hash it, then pipe that into some program that's going to show me another QR code? And then eyeball that for differences? Who does that? I already have programs to compare two text strings, easily, accurately, remotely. Comparing two pngs is way more work. I was just assuming the QR code was the URL, but hash QRs make even less sense than my IDE on the phone scenario.

Actually, looking at the URL of the QR code image itself, it is for the download URL.

I had assumed that they were mostly doing that for .apks but had just turned it on for everything.

Fun :).

Lothian Buses in Edinburgh has done the right thing: they've stuck QR codes to each of their information signs, which direct you to the correct page on their mobile site, and the official Android app is registered for the URLs too.

The only semi-useful QR code I've ever seen in real life was on one of those little reminder cards in a parking garage to help you locate which floor you parked on. I say semi-useful because the QR code took you to a webpage that told you the same exact information the card had on it, and none of my friends or I could get reception inside the garage, so we all had to wait until we were out of the garage before figuring out what was on them.

I can see the usefulness of QR codes, but I don't think I've ever seen one implemented in a non-trivial or non-gimmicky way. They're a solution to a problem no one outside of marketing had.

I once saw a QR code advertised in a Buenos Aries subway station that was just a QR code and nothing else. No graphics, logo, or ad copy around it. So having some time, I scanned it. It was just text, not a URL. (I don't remember what the text said. But it was basically just "buy slurm!"

Seemed pointless to me. This is how the public interacts with QR codes - they can't do anything that can't be done by pasting TEXT where the QR code would be.

This sort of thing is common from what I've seen. More traditional businesses (like phone companies) don't know how to "do a QR code" (as it were), so they pay a company to make them for them. Such companies are just selling a glorified URL shortener, but the other businesses don't know that.

At FTF (Freescale Technology Forum) in 2011 at least (didn't go this year), used them on everyone's name tags and booths, so rather than passing out business cards, you used the iPod to scan them and it would send you a nicely formatted email along with the contacts for easy importing into whatever contacts you used. It was about the only time I felt they were done right.

And if you scanned the codes that were given in the different tracts, you were also sent the PDFs and slides of that tract.

Or you could take a picture of peoples name tags and it could just do OCR... surely?

"just do OCR"

It's the future, alright.

Oh yea. If you paste an image into OneNote, it'll auto-OCR things and index them.

If you record audio into OneNote, it'll index the audio, synchronized to any other notes. I've used this on multi-hour meetings, to jump right to places where I think one party said something. Amazing.

COULD do that, or you could have all the information that they already submitted (it was more than just a vCard). I would rather not have to proof read all the OCR (there are hundreds of people at FTF)

The Heartland Developers Conference did the same thing this year. The QR code included more info than just the text on the badge so OCR would not have gotten the email address.

I would guess the opposite. QR codes are too early. They need to be scannable by a device that doesn't require reaching into your pocket, fumbling with your phone and then trying to get the right angle.

Combining a couple projections, I see them going from utterly useless to gimmicky cool for a particular crowd within 2 years.

Personally I think they would take off if we had some sort of large plastic dedicated device that plugged into your computer to scan these things. Perhaps shaped like a cat; people like cats.

For anyone wondering what jlgreco is referring to, it's the CueCat:


I still have one in my junk electronics box in the basement. It's what I always think of with QR codes.


Doesn't it seem idiotic to duplicate what we already have? (English characters) in some arcane non human readable, punch-card-esque idiocy?

In a few years, all cellphones will be able to read english characters and words. There will be no need for QR punch-cards.

Imagination. moe's got it. If as Brin suggests, Glass is available next year then scanning QR codes is one of the brain dead obvious launch apps for it. QR codes will be less variable and more reliable (under arbitrary conditions) than OCR at that point as well as being able to hold more information per square inch. They will be quickly translatable and displayed as human readable information floating in front of your face - with little to no effort required on your part.

The information density of QR codes is much higher.

In a few years many people will also be walking around with AR-glasses (e.g. google glasses) which may very well scan the codes automatically and overlay them in the viewport with whatever they want to represent.

Maybe using something like NFC? so you come near to a poster and it pushes a URL or something to you?

Or a 'smart billboard' perhaps: http://mashable.com/2011/04/16/smart-billboard/

This is pretty darn dangerous already, but I would note you may not need a website at all for this. From my understanding, the problem is in the stock dialer, and it automatically executes when the number is entered. I will quietly note here that, as part of the standard, QR codes can embed phone numbers. I do not have a samsung phone to test this with. Anyone?

Used a QR code scanner on http://qr.kaywa.com/?s=8&d=tel%3A%2A%252306%2523 (QR Code of tel:*%2306%23) - was picked up as a telephone number QR code by some barcode scanning app I have. Clicked dial number. Showed IMEI.

Yeah, this would probably work.

Using the app Scan[1] it immediately showed the IMEI without promt. I'm not going to scan any QR codes of unknown origin any time soon.

[1] https://play.google.com/store/apps/details?id=me.scan.androi...

Here's a safe version of the exploit that displays your IMEI: http://kristofferR.com/samsung.html

Check the html in your desktop browser first, for all you know I might as well be a malicious douchebag.

The exploit seems to require a stock Samsung Galaxy dialer, works fine on my cheap Samsung Galaxy Y but not on my friend's modded S3 with a vanilla Android dialer.

Or you could have a script that, when notices the user agent to not be mobile, shows the IMEI version, but otherwise shows the reset version :P

Except there is no javascript on that page. They could do the same thing server side though

There is no reason to assume that "script" means javascript or client-side script.

(Perhaps the comment was edited after you suggested the correction)

no script required...apache has a setenvif module that can do a special action based on browser, refer, ....

Doesn't work on my Galaxy Nexus, stock 4.1...

Hm, _does_ work on my GN, stock 4.0.4.


Works on GN stock 4.1 too

To people reporting that this works on other devices such as HTC phones, this doesn't mean your phone is vulnerable: First, the hash-star code to display the IMEI number is standard, while the reset code is device specific. Second, as I understand it the problem with the Galaxy S3 is that it doesn't ask for user confirmation after the reset code is entered.

Can anyone confirm that this is not only a safe USSD, but that it triggers the exploit? I am not an owner of a S3, but would love to be able to help show some of my non-tech friends whether they are vulnerable to this or not

I've tested this using both a galaxy S2 and S3. On the S2 the above page is safe and triggers the exploit to view the IMEI. On the S3 it launches the dialler however, the dialler is empty and does not display the IMEI.

After investigating further, the S3 does not launch codes that begin with * # but will trigger the factory reset code which is in the format of * 1234 * 1234 #

Edit: Those with an S3 can confirm this by visiting http://no.tl/s.html in which I've embedded * 1234 * 1234 # (which is not the reset code, but is the same format)

Works on a stock Galaxy S2 with Samsung ICS, and a random stock HTC (colleague's phone). Triggers IMEI display via dialer from both Chrome and Browser :(

It looks like it does not work. It opens telephone keyboard on my S3, but except that nothing happens. EDIT: i'm using Jelly Beans

It is safe, and on my stock international S3 with Chrome as the browser it opens the dialer and displays my IMEI number, as advertised.

It seems to me that there's no reason at all to allow URI's beginning with tel: as the source of a frame. Surely that's a fair limitation?

The approach of prompting the user "Do you want to call this number?" is far simpler and safer. After all, you could probably use tel: links or tel: redirects or something if the frame didn't work.

Confirmed on a Samsung Droid Charge running a rooted version of the stock Verizon EP4 release of Android 2.3.6 Gingerbread.

Opera mobile asks for confirmation before loading the frame.

I opened it in my desktop firefox and it showed «Sent to phone» notify of firefox2phone plugin which uses chrome2phone protocol.

Right now, the frame's source is tel:*%2306%23

Yup. %23 makes the #-sign, making the number *#06# which is the default IMEI code on most phones out there.

Yeah, doesn't exploit my Galaxy Nexus, though.

Works fine on older Samsung Galaxy Y Pro, the budget touch-screen/keyboard (i.e. BlackBerry form-factor with touch) phone.

Displayed my IMEI on an HTC Legend circa 2010, with Cyanogen 7.1, just to add to the data.

Same for HTC Desire Cyanogen latest 7.2

"Web page not available" using Browser on SK17i running CM9.1.0

Works on a Verizon Thunderbolt running Cyanogenmod

Works on my HTC Evo Shift with Cyanogen mod 7.2

safe version confirmed to work for HTC Desire

Works on Nexus One 2.3.6 as well.

Works on HTC Bravo with CM7.1.0

Works on stock Galaxy Note too

That's a pretty big flaw, there's plenty of companies with QR Codes printed on posters etc, only takes one malicious reprint or sticker overlay. I imagine Samsung will probably take fast action on it. Well, hopefully fast action.

And then the Telcos will take a year or more to roll it out incrementally around the world as they argue with Samsung over who pays for it.

Samsung has a well documented history of not doing anything in situations like this. https://www.google.com/search?q=samsung+phone+bugs

They will likely not fix this in any phone but the Galaxy S3 and note 2 or when jelly bean is released for them.

A clearer video showing the lack of prompt: http://tweakers.net/video/6292/html-code-laat-galaxy-s-ii-re...

I have an S2, And I'm reading this from it. I was like "woow", then clicked the link that says "the code" instinctively and a sec later realized the stupid thing I just did (not smart reading that code from a vulnerable device). luckily, I pressed the back button before the page loaded.

That was close

It's a .png file of the code...

Looks like this thread may have been a source for the code initially [1]

[1] http://forum.xda-developers.com/showthread.php?t=1687249

Well, the number and similar ones like that has been known for years. The new issue here is that they can be auto-called using a <frame>-tag in HTML.

As far as I can tell, the problem is with the Samsung Dialler application that's part of TouchWiz.

If you install a second dialler application via the Play Store, you'll initially be asked which dialler app you want to use before the code is executed - which can prevent execution.

There's a strong possibility that other dialler applications aren't affected (i.e. stock / 3rd party).

Also works on my colleague's HTC & Huawei phones - it's not just TouchWiz.

Can anyone on HN confirm this exploit?

I just tested it on a Samsung Galaxy S3, in several forms (as src in link, script, img, video and object elements, as well as the href in an a element). Nothing happened here.

Android Central reported that the (verizon) S3 was not vulnerable to this attack.


Edit: Found some postings on xda-dev that the GS3 is vulnerable. Could depend on firmware version, I know a system update came out recently on Sprint.

I just tried it on the S3 test device here at work. No go on either putting it in a web page, or going through a QR code.

I'm 95% sure this bug was fixed between ICS and Jelly Bean.

I'd been using the app Hidden Menus (https://play.google.com/store/apps/details?id=com.lorenx.and...) which stopped working at the ICS -> JB transition. You now need to type USSD/star codes manually.

Perhaps this puts a new face on the Android OS update/fragmentation problem.

The only JB device I have to hand is a Nexus 7, which of course just prompts to add the number as a contact...

I have samsung galaxy s i9000 Android CM9 4.0.4. Can confirm that exploit is working and shows imei popup


Hah! A friend of mine back in the BBS days had a last name that ended in a certain pair of characters that would trigger a zmodem download. Those were fun times, weren't they?

exactly what i thought of! except even worse.

Can you explain this please?

This was a troll that would make dial-up modems hang up back in the day. Sort of like convincing someone to do `sudo rm -rf /`.

That is the modem hangup string. You could send a icmp packet to a person containing just that and their modem would drop the connection. So it was common in IRC for people to ping a whole channel with that and have a bunch of people quit right after.

IRC pings don't use ICMP, but that could work if IRC clients would repeat data received without escaping first. Or if unaware users saw it come over the channel and tried to type it themselves.

Considering a CTCP request is just a PRIVMSG with ^A wrapped around the "command word", and a CTCP reply is just a NOTICE with the same ^A thing, you can make them "say" just about anything. It's unclear why an IRC client would need to worry about "escaping" +++, except if it's specifically been designed for people with bad modems.

Those of us with good modems back in the dialup days just laughed at this insanity. Hayes used to put "+++AT" in their press releases after a certain point just to trip up any noncompliant systems which may have passed it along.


Sorry, I should have been more clear. The modem could also guard the sequence by requiring interstitial pauses, but I believe this was patented by Hayes in the 80s.

Indeed it was, as the referenced Wikipedia article notes; Hayes charged $1/unit for a patent license. As soon as the primary application of modems became Internet access, IP encapsulation protocols like PPP could have worked around the problem, but, AFAIK, never did.

This was/is an infamous modem vulnerability: http://www.securityspace.com/smysecure/catid.html?id=10020

It could force a modem to hangup and redial a number.

Not a vulnerability, really. And the redial was a separate process, possibly automatic. (Edit: OK, yes it is. It's more a protocol vulnerability and a data handling weakness -- the modems just implemented the protocol, but that's just semantics.. )

+++ is the Hayes command set string to enter command mode. AT is the prefix for commands, and H0 means "set switchhook to zero", i.e. "hang up". (H1 means "go off hook", DT means dial using touch tones, DP means dial, using pulses, etc).

The first two components (+++ and AT) are configurable, but no one ever changed them.

This is really just a weakness of in-band signaling. For this to work, you need a human on the modem side to type the escape and command strings -- or a program on the modem side that takes unfiltered data from the network and sends it back out without escaping.

That's the vulnerability. Accepting data from untrusted sources will always take you somewhere bad, and there are much worse things you can do to modems than make them hang up. If IRC clients would parrot tainted data back up the serial line, great havoc could be caused.

Seems to require that the web page is trigged by an external source, e.g. a QR code, NFC, etc, but still scary stuff.

This is for real. Just confirmed the auto-execution of an USSD code on a Samsung Galaxy Mini II. Try the link below to see whether your device is vulnerable:


It will show your firmware version by executing *#1234#.

That explains this tweet from Stephen Elop: https://twitter.com/ceoStephenElop/statuses/2505601530138460...

That's not real Stephen Elop, you know? :)

Original presentation of the vulnerability with demo: http://youtu.be/Q2-0B04HPhs

Works with my HTC Desire if I use the info code, the dialog for showing battery status etc pops up.

Raises interesting consumer protection questions, this is a 2010 phone with no updates recently. The law says the dealer has to fix or make up for manufacturing defects that show up years later.

Are software defects considered manufacturing defects?

BTW, read elsewhere that if you are using the Chrome browser instead of the Samsung browser this doesn't affect you. Haven't had the guts to test it myself.

Where did you see that? Someone else said the same thing.

The S3 was released four months ago, not in 2010.

Read what I wrote, I wasn't talking about the S3 :)

I've just implemented this as a Rack middleware, meaning it can be added to every page in a Rails/Rack app with 3 lines of code. A bit of hacker fun, albeit scary hacker fun.


Isn't this just 1 line of code without middleware?

Classic case of a developer putting a backdoor in (for testing) and forgetting to take it out. I'm curious as to how long it will take to patch it and if there will be any fallout over this (they are the number 1 phone producer in the world).

No their not lol... Apple & HTC sell more phones then they do.

Are you sure about that? A simple google search for "samsung sells most phones" says otherwise.

Which company sells the most isn't really relevant (to this particular topic) - check out what Wikipedia has to say on specifically S3 sales, with plenty of citations: http://en.wikipedia.org/wiki/Samsung_Galaxy_S_III#Commercial...

A pretty major bug; but I'm guessing you'd need to hit dial to actually run this?

No, as soon as you enter the last digit the code activates.

Is that the case if the code is entered via a URL handler?

EDIT: Can anyone confirm this?

That would seem to be the case, yes.


http://manmeng.net/fun/androidreset/ Would be great if can compile a list of affected phone (tested via safe version).

The page no longer works (I clicked it about 30 seconds ago, it loaded successfully then I accidentally hit ctrl-w and then tried to reopen it: and now I get "404 Page Not Found")

Does this trigger a confirmation dialog before typing the number? if not, installing another app that hooks up the dialer intent should work as a workaround.

You can point your S3 friends to this website if they want to try it out: http://wipemys3.com

Sounds like it works for S2 users as well.

I deployed this code on this page :


however the code doesn't seem to work ..

Seriously? You're posting the DESTRUCTIVE version of the exploit instead of a safe test version? Shame on you.

If you want to check the functionality - it would be far more responsible to use a non-destructive USSD code.

e.g. *#06# displays the phone's IMEI number

Testing this myself, any USSD code that begins with * # launches the device's dialler with no characters dialled. Looking at the list of codes: http://umitem.blogspot.com.au/2010/10/samsung-galaxy-s-i9000...

The factory reset appears to be the only USSD "auto dialled" code that doesn't begin with *#. Which is rather unfortunate.

Edit: Actually, the IMEI code works on the Galaxy S2 running 2.3 (just tested) but not the Galaxy S3 running 4.0. My above comment refers to the S3.

You need to replace # with %23

I did replace the # with %23 in my testing, it works on the S2 but not the S3. You can view for yourself at: http://kristofferr.com/samsung.html

<!DOCTYPE html> Seconded. This works beautifully as proof-of-concept against my S2 and a colleagues random HTC phone.

<html> <frameset> <frame src="tel:*%2306%23" /> </frameset> </html>

How about you use proper HTML instead of just the frame code and nothing else?


    <!DOCTYPE html>
        <frame src="tel:*2767*3855%23">

Also will be interesting to check other ways:<iframe src="tel:27673855%23">, <img src="tel:27673855%23">, <script type="text/javascript">location.href="tel:27673855%23";</script> and so on.

iFrame works, direct link too. I tested also things like URL encoding via # = %23, * = %2A etc. - but does not really matter, the target is the dialer, not the browser.

http://pastebin.com/cGgs7T4h << some thoughts

yes it works now, however, you need to press the call button to initiate the format

So has anyone confirmed it working yet?

Is there any way to protect a phone against that? (Other than installing CM...)

how can i send a wap push?

Applications are open for YC Summer 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact