SIERRAMONTANA: NSA Exploit of the Day

Today’s implant from the NSA’s Tailored Access Operations (TAO) group implant catalog:

SIERRAMONTANA

(TS//SI//REL) SIERRAMONTANA provides persistence for DNT implants. The DNT implant will survive an upgrade or replacement of the operating system—including physically replacing the router’s compact flash card.

(TS//SI//REL) Currently, the intended DNT Implant to persist is VALIDATOR, which must be run as a user process on the target operating system. The vector of attack is the modification of the target’s BIOS. The modification will add the necessary software to the BIOS and modify its software to execute the SIERRAMONTANA implant at the end of its native System Management Mode (SMM) handler.

(TS//SI//REL) SIERRAMONTANA must support all modern versions of JUNOS, which is a version of FreeBSD customized by Juniper. Upon system boot, the JUNOS operating system is modified in memory to run the implant, and provide persistent kernel modifications to support implant execution.

(TS//SI//REL) SIERRAMONTANA is the cover term for the persistence technique to deploy a DNT implant to Juniper M-Series routers.

Unit Cost: $

Status: (U//FOUO) SIERRAMONTANA under development and is expected to be released by 30 November 2008.

Page, with graphics, is here. General information about TAO and the catalog is here.

We have already seen the codename VALIDATOR. It’s the code name for a default, or basic, NSA exploit. It’s the exploit that FOXACID defaults to using.

In the comments, feel free to discuss how the exploit works, how we might detect it, how it has probably been improved since the catalog entry in 2008, and so on.

Tags: , , , , , , ,

Posted on January 16, 2014 at 2:00 PM • 33 Comments

Comments

Nicholas Weaver • January 16, 2014 3:32 PM

I’d like to see more variety in the “SpyMall Catalog Item of the Day”. So far its all been variations on the same thing: persistence of malcode by hiding in system firmware, and all almost certainly installed remotely, probably by QUANTUMINSERT-ing on the sysadmins.

Bryan with a beard • January 16, 2014 3:35 PM

@Steve Friedl
me too

@Nate
The article implies that NSA is not skimming metadata here… they are generating data (that could be called metadata) from the CONTENT of the text, which of course puts a(nother) lie to their claims.

Benni • January 16, 2014 6:05 PM

Well, because of this: http://www.theguardian.com/world/2014/jan/16/nsa-collects-millions-text-messages-daily-untargeted-global-sweep n

ext weekend, i must install cyanogenmod:

https://whispersystems.org/blog/cyanogen-integration/

So I can encrypt my sms when they are send to other cyanogen users.

I heavily think that stock android should also support such an encryption feature.

Perheps it would even be necessary, to implement a voice over ip function in android that encrypts the voice messages with a key stored only in the phone. Given that the GCHQ apparently saves the plain text sms for years, it would not surprise me, if they also try to get the voice messages, for some targets. It is easy for them, to fake a base station for smartphones in their embassies.

I find this horrible;

More than 5 million missed-call alerts, for use in contact-chaining analysis (working out someone’s social network from who they contact and when)

On average, each day the NSA was able to extract:

More than 110,000 names, from electronic business cards, which also included the ability to extract and save images.

Over 800,000 financial transactions, either through text-to-text payments or linking credit cards to phone users

The agency was also able to extract geolocation data from more than 76,000 text messages a day, including from “requests by people for route info” and “setting up meetings”. Other travel information was obtained from itinerary texts sent by travel companies, even including cancellations and delays to travel plans.

“In contrast to [most] GCHQ equivalents, DISHFIRE contains a large volume of unselected SMS traffic,” it states (emphasis original). “This makes it particularly useful for the development of new targets, since it is possible to examine the content of messages sent months or even years before the target was known to be of interest.”

It later explains in plain terms how useful this capability can be. Comparing Dishfire favourably to a GCHQ counterpart which only collects against phone numbers that have specifically been targeted, it states “Dishfire collects pretty much everything it can, so you can see SMS from a selector which is not targeted”.

They store that for years. What we buy, where we are, whose friends we have, what we tell them.

Lurker • January 16, 2014 11:27 PM

This technology has been anticipated for a long time.

“The technotronic era involves the gradual appearance of a more controlled society. Such a society would be dominated by an elite, unrestrained by traditional values. Soon it will be possible to assert almost continuous surveillance over every citizen and maintain up-to-date complete files containing even the most personal information about the citizen. These files will be subject to instantaneous retrieval by the authorities. ”

“In the technotronic society the trend would seem to be towards the aggregation of the individual support of millions of uncoordinated citizens, easily within the reach of magnetic and attractive personalities exploiting the latest communications techniques to manipulate emotions and control reason.”

― Zbigniew Brzezinski, Between Two Ages: America’s Role in the Technetronic Era (1976)

Icecave • January 17, 2014 2:05 AM

@ Tom Marble’s questions & Bruce Schneier

Do you physically possess the hardware your website is hosted on?

Do you reasonably believe your hardware can be secured against on-site threats?

What kind of threats can you anticipate, if any to “schneier.com”?

Do you have plans to integrate PGP at any time, or sign your posts/articles? Many if not most of your users may have the capability — and could easily verify your posts — though I do not see where a state actor stands to gain from attempting to impersonate you — since you are well versed enough to detect and thwart an intrusion in the short or long term. Hope make sense.

65535 • January 17, 2014 4:10 AM

It’s the same MO.

1] Juniper Enterprise edge router running Juno

2] Validator and a second virus ‘Sierramontana’ to root the BIOS consistently and call home with the data stream.

3] SMM pawned.

The only difference is “Sierramontana under development and is expected to be released by 30 November 2008.” That date has passed. So, the exploit is in the wild.

I assume there must be a re-boot of the machine (cold or warm) to install the BIOS hack. That a re-boot would be something to look for – especially a enterprise router re-boot. If there is no need for a re-boot that would make it hard to detect.

@ Benni
Gad, that Dishfire is ugly. I notice: ”MetaData [MSISDN#, IMSI personal ID; IMEI#] plus Content of System Generated Text Messages leads to analytic gems…” That goes overboard by combining the Metadata and the content. That makes me want to vomit! This mass spying must be stopped.

Marcos El Malo • January 17, 2014 10:49 AM

@Benni

“I heavily think that stock android should also support such an encryption feature.”

I think it is unlikely to happen, as encrypted email would harm Google’s bottom line. Stick with custom ROMs from probably trustworthy sources.

enkiv2 • January 17, 2014 11:30 AM

The only difference is “Sierramontana under development and is expected to be released by 30 November 2008.” That date has passed. So, the exploit is in the wild.

I’m not sure that it’s a safe bet to assume NSA projects aren’t subject to Hofstadter’s Law; all we can say is that the exploit may be in the wild.

enkiv2 • January 17, 2014 11:40 AM

Come to think of it, what are the chances that a handful of these programs have succumbed to bit rot and are either no longer active or used only on legacy systems? An exploit specific to XP is still good since many people still use it (and some systems, ex. SCADA, are limited by legacy software to using 9x still), but an exploit that only works on OS/360 is of limited utility against a zOS-dominated market.

While I won’t say that six year old linux/bsd exploits aren’t useful (routers and other hefty embedded systems are vulnerable), six year old smartphone exploits are very likely to need to be superceded, and a genuine improvement in security might require a fundamental restructuring in terms of what kinds of exploits and what target surfaces are used to get certain kinds of information (as an example, android 2.x had a bug where arbitrary code could be executed using hyperlinks; certain types of sniffing that could be done with this when it existed would be easier to do by sniffing the air or sniffing servers on the other end once it’s been patched, completely changing the topology of a multi-exploit attack).

01 • January 20, 2014 2:31 AM

@65535

Gad, that Dishfire is ugly. I notice: ”MetaData [MSISDN#, IMSI personal ID; IMEI#] plus Content of System Generated Text Messages leads to analytic gems…”

good thing SIM cards (imsi) are easy to come by, and many phones (begrudgingly) allow IMEI change (esp. Chinese MTK 65xx based phones)

Clive Robinson • January 20, 2014 3:05 AM

@ 01,

    … and many phones (begrudgingly) allow IMEI change…

A list of such phones and a “HOWTO” do it would make a very usefull piece of information.

However although no doubt well known to industry insiders, criminals and LEAs and intel agencies, I suspect if “ordinary mortals” started doing it the chattering political classess would legislate against it with only minimal preasure from the agencies…

01 • January 23, 2014 12:42 PM

@Clive Robinson
Well, first and foremost, it is kinda illegal in UK (and some US states, I think).

Now, as to IMEI change recipes – I am hardly an “insider”, but I know a few recipes.

I think I’ll share it right here 🙂

Let’s start with a nice USB 3G/LTE modem (technically, not a phone, but a useful little thing nonetheless). Because it has one of the most annoyingly fucked up IMEI reflash procedures.
The modem is Huawei E392u-21(one can find it on aliexpress.com and ebay.com )
The memory region storing IMEI on this device is write-protected until a “catastrophic failure” occurs, so in order to reflash the IMEI one would have to induce a catastrophe. But in order to prevent modem from getting bricked, we should start with backing up calibration data.
So…

=====(modem) Huawei E392u-21 IMEI change ======

Step one:

get QPST and perform backup. IMEI-related NV_Item will get backed up, but that is irrelevant (what we want to achieve at this point is calibration data backup). If one wants (and has QPST version with NV Item Manager), one can just select the calibration data, but that is irrelevant (IMEI will become non-writable again, after we re-write it, so restore of QPST backup will not change it back)

Step two:

get firmware update appropriate for the modem involved (I like 11.836.13.00 version) and apply via standard procedure (you can use HMF which is needed for step three anyway, or you can use any other tool).

Step three:

download Huawei modem universal flasher ( http://forum.gsmhosting.com/vbb/f804/huawei-modem-universal-flasher-1495518/ ) and unpack the firmware update file you got in step two.

Step four:

In the resultant material, find 07.bin and copy it to a safe place. Then corrupt the original 07.bin, by adding a new nv_item into the section corresponding to your modem’s product ID without correcting for resultant file size.
Just add something like 8,8a,16,32,0,21,43,65,57 and the file will be corrupt enough.

One might ask what your modem’s product id is… well, that’s a tricky one – mine was simply written in accompanying documentation. You can add an 8,8a,16,32,0,21,43,65,57 into every section, so that all product_id’s are covered.

Now the corruptor file is ready 🙂

Step five:
connect the modem again, and prepare it for flashing.
Follow standard HMF flash procedure using corrupt file.
A failure will occur and HMF will ask if you want to continue.

Continue.

A catastrophic failure will occur (Just as planned!) and nvram content will be purged, which will cause write protection will be temporarily lifted (till modem reboot)

DO NOT DISCONNECT MODEM! DO NOT REBOOT MODEM!
PROCEED TO STEP SIX IMMEDIATELY.

Step six:
verify IMEI purging via AT command (BTW, familiarize yourself with the modem’s AT interface, useful thing)
I use ATI (but PHYNUM should also work)

A random IMEI (not matching the old one), IMEI of all zeroes, or empty IMEI string all are indicators that we busted the contents of the memory allright.

Now that we’re sure that our little engineered catastrophe has corrupted the old IMEI (and unlocked memory), one should launch QXDM and proceed to write a new IMEI into item 550

There are two tricks to this

first (VERY important) – IMEI should stard with a particular byte sequence any other sequence can kill the modem

second, the IMEI is formated in a special manner.

It’s kinda hard to explain, so I’ll just show how we construct the new imei number instead (do note that the IMEI is right from the top of my head, so I dunno if luhn checksum checks out).

861230012345675 # IMEI number we want to write

80A861230012345675 # Adding the magic values 80A mentioned above in order to prevent bricking. Don’t try other magic values, it can irrevocably destroy the modem.

80 A8 61 23 00 12 34 56 75 # break up the sequence into pairs

08 8A 16 32 00 21 43 65 57 # reverse sign order in each pair.

Sequence is ready, let’s start writing it.

Oh, this stuff is HEX, so for the purpose of QXDM the sequence should be writte as 0x08, 0x8a, et cetera

Start writing procedure.
This can take a while.

Step seven:
Reboot the modem (I use AT commands, but power-cycling should, at this point, be safe to do)

When modem finishes rebooting, it has new IMEI, but all calibration is (for now) corrupted.

We shall fix that in step eight.

Step eight:
restore the QPST backup. IMEI will not be changed (we “locked in” the new IMEI when rebooting the modem) but all the calibration thingies will be back.

Step nine:
Verify IMEI via ATI and PHYSNUM commands.

If IMEI matches the one you intended – congrats.

Okay, that was one of the hardest recipes of mine. A mite later I will post a “recipe” for Zoppo phones, which is one of the easiest IMEI change recipes ever.

01 • January 23, 2014 1:23 PM

Now, Zopo phones…
…IMEI changes with are so easy a Republican could do it. Maybe not on the first attempt, but still.

A bit of background info – Zopo Mobiles make MTK-based android devices. MTK 65xx are known for a rather peculiar way of handling NVRAM content (which includes IMEI, calibration, “proper” WIFI MAC and shit whatnot), specifically, they copy NVRAM into /data/nvram/… folder, and then check if the contents are doing fine. The specifics of this process are vendor-dependent and part of (AFAIK) NVRAM daemon routines. Some vendors make a very sophisticated daemon which really does bother comparing whether the files in /data/nvram/ were tampered with (there should be some ways of crippling such a daemon, but buying a more permissive phone is a more prudent solution. Support permissive phones!), some vendors are lazy and only check whether the folder is present.
Zopo, however, take the cake because they are so ham-fisted that IMEI occasionally gets purged without any user intervention whatsoever.

Now, they also don’t give a single rat’s ass about tech support, so when waves of “where is IMEI, why nothing works” emails came crashing in, they wrote an APK that uses an internal mechanism (actually, same AT command sets that are used in ZP900 method, IIRC) to set a new IMEI (one for each SIM, mind you, their phones are double-sim)

The .apk works for Zopo phones based on following MTK chipsets: 6516, 6513/6573, 6575/77 (maybe on some other phones based on same chips – I know for fact it works for Lenovo A750 )

The .apk can be found here:
http://www.zopomobileshop.com/zopo-rom/zopo-zp100-imei-number-writing-english/

Sadly, .apk does not work for newer, fancier Zopos (like the ZP900 one)… but hey – a method exists for them, too, and you don’t even need a custom APK – it’s right inside.

http://www.zopomobileshop.com/zopo-rom/english-guide-for-writing-valid-imei-number-for-zopo-zp900-zp300-plus/

Incidentally, the AT commands seen in the last method work on a great number of MTK phones if one sends them to the right terminal (usually, /dev/pttycmd1 does the trick)

01 • January 23, 2014 1:52 PM

In our next installment, we shall discuss some Samsung Galaxy phones, as well as HTC phones.

If I don’t get shot by NSA, lol 🙂

01 • January 24, 2014 2:36 AM

@Adjuvant

well, first and foremost, it doesn’t do jack against single-use phone/sim pairs (expensive, but hey, if you are worried about three-letter folks, you should have money!)
Second, notice the calibration data I mentioned in the part about modem abuse… Well, the idea behind calibration is to minimize differences between individual modems…so tampering with it – and in that modem it isn’t even write protected – can result in altered “radio fingerprint”, loss of signal quality, improvement of signal quality, modem destruction, and maybe something else (I have not managed to set it on fire by poking around with those, but hey – I’m not a real engineer 😉 )
Zopo phones copy their calibration to /data/nvram from the partition.
I am not sure the phone radio doesn’t read stuff from the partition when data/nvram is properly populated, but the partition content itself is definitely not beyond tampering (zopo give no fucks), and I have seen considerable alterations in reception quality when swapping /data/nvram from GF’s phone (we have same model of Zopo)

One could likely alter his “radio fingerprint” quite considerably by tweaking calibration settings…

nb! calibration settings are rather poorly documented, unless you are fluent with Chinese. Care is advised.

01 • January 24, 2014 3:26 AM

One more thing – the huawei modem I mentioned above supports external antennae.

I’m sure Clive can give us a few ideas on how to leverage antennae and cables to screw with signal fingerprinting

littlefella • January 24, 2014 4:47 AM

Hey guys, I look and you discuss radio calibration, MTK and things.

I think this might be of interest:
qr.net/mtkrcal (MTK radio calibration English briefly)

http://qr.net/calbackup (backup of calibrations before manipulation)

Also, I read the paper about fingerprinting – not very sure much can be done about it, except maybe to somehow inject errors at a very low level (you would need radio source code for that, not sure anyone – MTK included – give that without much fuss)
Resisting fingerprinting (on android or any other phone OS) makes for interesting research.

Wonder what Mr. Clive would say

Clive Robinson • January 24, 2014 7:11 AM

@ Adjuvant,

With regards “radio fingerprinting” it’s nothing new, if you look back on this blog I’ve been talking about it for a very very long time with regards RFIDs and electronic passports . And technicaly what the researchers are doing is fingerprinting the transmitter not the receiver. Fingerprinting a receiver can be done which is why the comment about passive / undetectable is actualy not true it’s just very very difficult (remember we can see people and cameras directed at us by “red eye” effects there are similar effects for all EM frequencies which is what some of the other daily toys Bruce is posting do). I’ve demonstrated finding RFIDs and WiFi equipment and bugs even when switched off.

The idea on fingerprinting transmitters goes back to WWII and morse code transmitters used by military forces on all sides but especialy Germany where it was a requirment for Blitzkrieg. Due to the way morse transmitters worked (anode or cathode keying, and later safer grid keying) they would produce not just wide band splatter but also a narowband envelope whine.

So the British were not just identifing operators by “their fist” but the actual transmitters as well. Which is why they recognised German radio deception because they had operators recognised by their fist sending supposadly geographicaly seperated messages all using the same transmitter, which is extreamly unlikely unless somebody is running a deception…

The Germans meanwhile were identifing SOE and other agents by their receivers, not their transmitters. The field agent radio designs of the time used unscreened oscilators that made them like mini transmitters and the German wirless security service could Direction Find these from several miles away. After the war in the 1950’s and 60’s MI5 were still finding agents by this technique, they were also able to find out when the Russian’s were tuning into the MI5 “watcher radio net” of their VHF walki talkies.

More upto date I’ve demonstrated (for a fee) how to find non obvious / hidden wireless access points using different techniques which I’ve also used for RFID’s that I described just a very short while ago on another page on this blog.

Incidently you can fingerprint computers by the network packets they emit, which with a little further thought alows you to identify “honey nets” and other computers running multiple VM’s and Jailed services on different network cards and IP addresses by looking at “clock drift” which can sometimes also show what part of the world the computer is realy in due to it’s daily drift cycle…

As @ 01 notes swaping handsets is not a problem, and quite a few criminals are activly doing it quite successfully at little or no cost, in fact in some cases at a profit…

In London and presumably other places it’s known that there is a significant tie up between drug dealers and other criminals and mobile phone second hand sales outlets. So much so that changing their SIM is harder than changing the phone because all they have to do is reach into the display cabinet or draw to get another phone.

Further providing the phone is “fresh in” and the old user has not wiped the phone book placing a couple of calls to the numbers in the book kind of removes the extra step in the Two/Three steps the NSA and Obama seem to think makes it all OK. Even though the SIM is changed (most analysts would incorrectly belive the “calls placed on the phone” than “SIM used” due to the way people behave)…

As I’ve indicated in the past the OpSec behind phone swapping, SIM swapping, pool phones, burners and other obsfication techniques is difficult for many people (especialy journalists) it’s amazing though how a mixture of long jail sentances / death and the attendent “Darwinian selection” tends to make criminals better at it.

Whilst various aspects of a phone can be altered by calibration steps and swaping batteries as @ littlefella points out playing with low level software will change others but at the end of the day unless you’re good with a soldering iron and hot air gun there is not much else you can do to an individual phone and even then some things cann’t be changed.

That said the things that are hardest to change are also the hardest to detect, so whilst not a zero sum game it’s not got a significant gain factor. Importantly doing it over any kind of area would mean having specialised receivers at nearly all cell sites, whilst not impossible to do (especialy if you make the service provider carry the cost) it represents a significant cost for very little or no return due to “burner phones” and other broadcast services such as pagers etc, or even phones in call boxes, cafes, bars and other places of social gathering, befor the likes of the Internet.

There is even a trick you can do with credit cards to send a one bit message in a given time frame. When you check into a hotel etc if you had over your credit card rather than paying a cash deposit they automaticaly debit the amount from your “credit limit”. Knowing this you can check your current available credit limit. Thus if I have a Hotel, car rental or other similar business and I know your credit card details I can send you a message by changing your available credit limit…

01 • January 24, 2014 12:32 PM

@ Clive Robinson

Whilst various aspects of a phone can be altered by calibration steps and swaping batteries as @ littlefella points out playing with low level software will change others but at the end of the day unless you’re good with a soldering iron and hot air gun there is not much else you can do to an individual phone and even then some things cann’t be changed.

Well, randomly changing calibration profiles after IMEI change could be enough to thwart such profiling, in the sense “an automatic tool could not match it against previous record reliably”.
One problem is that the files are exceedi

Upon some thought, though, I think that the following alternatives might be curious to investigate:

1)
one could connect a small-ish circuit between the phone’s “baseband” module and the antenna proper. The circuit would feed disturbances into the signal, large enough to skew fingerprinting, small enough to avoid disrupting the connection
obvious problems:
1a:
the circuit will have to be small enough to fit into cramped bowels of your typical smartphone
1b:
it will have to be powered somehow, and one would have to fit in battery somehow, or connect to cellphone’s very own power supply (decreasing battery life)
1c:
it seems to me that “random” signal would be sub-optimal. It would be better to inject a deterministic signal in such a manner that it becomes more like a consistent (and fake!) profile.
When IMEI is changed, we (just) alter parameters to the “fake profile” to achieve a new profile
1d:
one would have to somehow manage the thing and it’s profiles
1e:
someone would have to develop this brilliant thing.

2)
derivative of a smart jammer – basically, a device which monitors adjacent GSM / 3G transmission and transmits specially crafted signals that subtly interfere with main phone’s signal so that an observer doing signal fingerprinting would see that as a different fingerprint.
this idea has less issues with power and control, but it’s still a lot of development effort for a rather speculative gain.
Still, maybe some radio hacker will one day look into this, cause it’s pretty cool

That said the things that are hardest to change are also the hardest to detect, so whilst not a zero sum game it’s not got a significant gain factor. Importantly doing it over any kind of area would mean having specialised receivers at nearly all cell sites, whilst not impossible to do (especialy if you make the service provider carry the cost) it represents a significant cost for very little or no return due to “burner phones” and other broadcast services such as pagers etc, or even phones in call boxes, cafes, bars and other places of social gathering, befor the likes of the Internet.

Well, yes, unlikely to become practical soon, but still, modifying phones to avoid this method of tracking is an interesting challenge, isn’t it ? 🙂

Adjuvant • January 24, 2014 1:48 PM

@Clive, 01, littlefella et al.

Thanks for the contextualization. I always figured the references to this technique of fingerprinting contained at least an element of FUD, since I’ve seen unqualified (and unsourced) statements and warnings of the capability pop up in the oddest places.

So as a takeaway I gather it’s reasonable to assume that this fingerprinting is likely to be a feature of, for instance, Uganda Telecom, Knightsbridge Extension (ht Jacob Appelbaum) or of various stings, but less likely to see routine use due to equipment and SIGINT analyst human resource limitations. And also that the most immediately practical way to deal with the problem is to avoid it by not reusing the hardware in the first place.

01 • January 24, 2014 3:29 PM

Let’s put it like this – authorities in my jurisdiction do use rise time parametrs to track illegal transmitters (think unlicensed “pirate radios”) and such, but shenanigans like ones in the article are nowhere to be seen, afaik. Also, regulatory compliance for cellie operators does not require recording such parameters, which, if I know my capitalistas 😉 means that no such capabilities are present.

Besides, in order to use the methodology for tracking in LEA/creepy-NSA abuse context, merely being capable of determining your fingerprint and comparing current session against a fingerprint db would not be enough.
One would have to retain the fingerprints of previous sessions so that it could be proven that a few days ago a call from this phone was made with a different IMEI/SIM pair.
That doesn’t seem practical….yet.

Still, I think that figuring out ways to disrupt fingerprinting (either through tampering with phone radio calibration profiles, or through dedicated hardware noise generators, or something else) is a wonderful academic and engineering endeavor.

01 • January 24, 2014 4:09 PM

Upon further contemplation, the attack described in the paper is far more worrying as part of “private sector spook” arsenal.

It allows a “kinda passive” adversary to reliably detect your cellphone (let’s face it, that is almost synonymous with detecting you) without any need for knowing your IMEI, IMSI, or even cellphone number (thus, any tech savvy private eye with a budget could do it even without any shady LEA ties)

Assuming the attacker knows some of the locations you visit, and times of visit (good old visual observation), attacker can use several SDRs to build fingerprints of all cellphones in vicinity (several SDRs can be used to add triangulation capability) at the moments when you are definitely present.
From then on and up to the point you burn the phone, attacker can track you as long as his SDRs can pick up your signal.
At no point does the private eye need to access phone company equipment or tap Ye Greate Transatlantic…

Attacker could very well do without knowing your phone number, at least initially.
If attacker has ties with corrupt cops (as private investigator he very well might 😉 ), he can use this capability as a beachhead to some more potent nasties.

Enabling consumer phones to evade radio fingerprinting is thus not only a fascinating engineering project, but a perfectly legitimate privacy endeavor.

Jana • January 26, 2014 1:35 AM

Well, my two cents regarding the whole radio-fingerprinting issue:

It won’t help us against criminals at all. In my whole life, I’ve only seen one person actually changing IMEIs, and he ended up being a witness.

Savvy criminals use “burner” phones which they discard together with SIMs, while dumb ones just don’t bother.

Numberguy’s suggestion that this can (and probably will) leak into “grey” parts of private sector is fairly disturbing, though my understanding of paper (limited as it is) suggests that during the test, phones were 4 meters away from the “fingerprinting machine”.

Dunno about you, but I can just read the brand on the case from 4 meters away (assuming it’s a phone that has branding on its body, of course) 😉

If the effectiveness of fingerprinting is dropping with range (an issue the authors don’t go into that much), it would be of paramount importance just how effective the machine would be at a practical range (~350-500 m, at the very least). Fingerprinting that only works when you’re (very) close is next to useless both for state-level and private sector “spooks”, IMHO.

01 • January 26, 2014 12:43 PM

Well, also don’t forget that even with rather small and forgiving (no fucked-up dual-tripple-quadrupple sim units, etc.) phone sample set (and forgiving experiment conditions, as Jana pointed out), they had a non-negligible confusion rate.
Also, I suspect IRL “learning phase” conditions would likely be less forgiving (>100m, similar units in close vicinity).

With realistic data sets (hundreds of thousands, if not millions, of mobile devices in same city) and realistic learning and detection conditions, confusion rate would likely be quite higher.

In my huble opinion, the Hemisphere approach to “IMEI/IMSI-independent phone detection” is more promissing.

Speaking of promissing…
… I promisssed more info on how to change them IMEIs didn’t I?

Here we go, :

===== Samsung Galaxy Note / Galaxy / Note 2 and many others ===

This method applies to many phones that have Qualcomm-based radios.

It is remarkably similar to the modem trick I outlined above (guess why ? Because similar chip!)

Basically, you use QXDM / QPST to write an imei.
This method usually suffices for me:
http://droidmodderx.com/galaxys3/?page_id=79
There is also a full-featured “imei restore tool” on XDA
http://forum.xda-developers.com/showthread.php?t=1308546
a bit of additional info can be found here (some asshole ROMs hide necessary menus)

http://dropandroid.com/content/fix-backuprestorefix-imei-issue-wqpst-updated-7312012

In case the above does not work, there is a MEID/IMEI repair tool that has been said to bypass write protection (didn’t test myself), and was banned from XDA . It’s name is XDA Samsung Repair Utility (seen here http://www.hackmyandroid.com/restore-lost-imei-eri-fix-data-roaming-issues-on-verizon-samsung-galaxy-s3/4212 )
Fortunately, kind folks re-uploaded to another file host, so you can try it here:

http://d-h.st/Jju

also

https://infotomb.com/6mosu

Now, sometimes, the nvram write protection just won’t let go. In that case, we will have to induce a fault in the memory writing process to be able to write an IMEI (like we did with that poor modem 😉 ).
There is no standardized process for Samsung phones.
However, at least one person at XDA has successfully induced an “IMEI 0” (aka memory corruption) in order to change IMEI

http://forum.xda-developers.com/showpost.php?p=46660674&postcount=95

Archive.is copy of the page in case “something” happens

http://archive.is/Vq2L4

Motorolla users can sometimes use RadioComm utility (As well as QPST)
genral information about it’s use here:
http://forum.xda-developers.com/showthread.php?t=2166542

To edit IMEI, just use a different nv_item (550 )

Finally, let’s talk about HTC phones…

====Changing IMEI on HTC ====

All phones that can be rooted by gfree method are vulnerable

For instance let’s take this thing

http://wiki.rootzwiki.com/HTC_myTouch_4G

when gfree root/unlock finishes, it leaves behind a backup file (backup of partition 7).
As all well-educated gentlemen have probably guessed, IMEI is there, in plaintext, and can be edited with a hex editor.

If one wants to keep the root / unlock AND change IMEI, they should just rename the old backup and force gfree to make a new backup (the already unlocked one) which can be edited with a hex editor and written back to partition 7.
gfree docs are here.

http://www.thinkthinkdo.com/trac/project1/wiki/gfree

Well, that’s all for now, folks 🙂 (Okay, I know more tricks, but I guess our kind host is probably tired of this more-than-a-little-offtopic-discussion)

P.P.S.:
In my first “reflashing” post, I mentioned Huawei Universal Flasher.
Turns out it’s hard to come by.
I decided to upload it to a pair of file hosts

http://d-h.st/0Ke

https://infotomb.com/cu0k5

admin hash • June 26, 2020 5:12 PM

Is there any alternative to QXDM? Once you have corrupted NVRAM, the IMEI will report as Unknown or 0, and then what to do from there if you can’t flash XQCN files with QFIL/QPST? Also, is it 100% 550? MSM8896

It’s easy to corrupt the radio image files using hex editor, but once corrupted I seem to be stumped.a

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.