Sure the digital baseband is all the same, as the signal coming in is usually at a specific IF regardless of the band.
It is the old fashioned hard wired analog circuitry that is the issue, and that is not just the antenna.
Think filters, duplexers, etc which are designed and optimised for a certain band. Not to mention amplifiers and mixers. As someone who has designed active RF & microwave circuits, it is not easy achieving broadband filtering and impedance matching at multiple bands. So you need to have multiple filters, components, etc, which adds $$ to cost. So you pick a handful of bands that you want to support, and swap the components depending on the regional variation of your model.
[1]: Along with SHAtter. Screw you, Geohot, for blowing a low level exploit because of your ego.
To be fair, it's possible SHAtter and limera1n would have been plugged at the same time by the same fix.
They both depend on bugs in the firmware read-back mode code in DFU mode. Limera1n exploits a bug in which the direction bit of the USB transfer is automatically trusted to match the command type, and SHAtter exploits a bug in which the read index offset (a global variable) is not reset after each call to re-initialize the USB code in the outer loop. Both bugs were "fixed" by the removal of the firmware read-back code in A5 devices.
It's substantially more complicated than that. If it were as simple as every buffer overflow being exploitable in this way, then jailbreaks would come thick and fast after every release.
With iOS you have:
(a) stack is never executable, so all payload must be ret-to-libC style (b) consequently, because user space address layout is randomized with about 8 bits of entropy, you have to find a way to leak address of a symbol, or else find some more sophisticated exploit (c) even if you defeat above, you still only have typically gained executable control over a restricted user account (d) now you have to trigger a kernel exploit from restricted process space sandbox OR
(d)+(e) break out of the sandbox or gain root with another userland exploit in order to be able to trigger the kernel exploit, which may depend on functionality accessible from root only
Anyway you get the idea. My hat goes off to pod2g and co for their dedication.
The fundamental flaw here is that cable capacity is shared between *all* users from the local node, i.e. everyone in your street, unlike ADSL.
Therefore, there's not really much improvement to be made. The only possible optimisation with this hypothetical IP system would be to "detect" that everyone is watching Australian Idol (or whatever people watch these days) and then allocate more capacity to that program perhaps to improve video quality. Otherwise, if everyone is watching something different it's no different to the current "broadcast" situation. DVB is compressed, usually with an MPEG-4 class of video codec, so it's already highly efficient.
Oh, and particularly with digital transmissions, there already is a substantial channel changing delay anyway, even with "broadcast" style DVB. Especially the case with MPEG-4 I've noticed, up to a couple of seconds even on modern receivers; even if the channel is on the same transport stream (i.e. same carrier), while it waits for enough key frame data to accumulate. Even worse delay if its on a different carrier, because the lower level receiver has to synchronise to that.
Warranty deadlines seem to be a very typical US-consumer-shafting.
If the product has failed due to manufacturing defect despite reasonable use, then the retailer (and then ultimately manufacturer) is required to replace it. If this is a few days out of the manufacturer's warranty it is usually irrelevant.
Statutory rights are not limited to a set time period. Instead, they apply for the amount of time that is reasonable to expect, given the cost and quality of the item.
This means a consumer may be entitled to a remedy under their statutory rights after any manufacturer’s voluntary or extended warranty has expired.
For example, it is reasonable to expect that an expensive television should not develop a serious fault after 13 months of normal use. In this case, the consumer could argue the item was not of merchantable quality and ask for it to be repaired, even if the manufacturer’s voluntary warranty had expired.
Those 300Mbps speeds are quoted for 4x4 MIMO configuration for 20MHz bandwidth.
Telstra are using a 2x2 MIMO with 10MHz bandwidth. The theoretical speeds are closer to 90MBps, and indeed, if you read the whirlpool forums, people are in fact getting close to that.
Further to this, here is an example of some paging traffic I captured over a live UMTS network (Telstra NextG, in Australia), using nothing more than a USRP with 900MHz daughterboard, and some custom Matlab code. The message has been unpacked from ASN.1 format to XML, but it clearly shows IMSI and TMSI in plaintext.
The concepts here are not necessarily specific to the GSM Um link. The same concepts used by the authors equally apply for UMTS and LTE, and most other cellular systems.
ALL of those systems page out phones based on some temporary (but plaintext) identifier when an incoming call needs to be routed and there is no active RRC (radio) connection. All of those systems try to mitigate this exact problem by using a temporary ID (the TMSI), rather than the permanent ID (the IMSI). The TMSI is re-allocated over a ciphered connection.
The TMSI rotation policy is up to the operator. It can in theory be rotated each connection, but few operators do this - too much signalling load on the core network. Most operators will hold the TMSI until the next periodic (i.e. after a certain number of hours - operator defined), or aperiodic (when the phone moves into a different paging domain [location area]), or when the phone is power cycled (which implicitly does a type of location update anyway).
One solution for future versions of the standard might be to encrypt the paging message (along with a random nonce to give uniqueness to each paging message) with the last known ciphering key, but this may not be known by the network entities in the new location areas.
I don't know how this myth keeps getting propagated. It is absolutely not true, for both the GSM and UMTS systems.
You don't need to have a background in cellular engineering to understand that if you want to use a service in near real-time (i.e. SMS), it is going to have to consume resources then and now.
Your phone is not using control channels constantly. This is for good reason - the control channels are extremely limited in capacity, and using them frequently would consume your battery as well.
Your phone is only using control channels typically when moving between cells or locations areas. You can easily see this on GSM phones if you have an old radio nearby; you will know when the phone is transmitting and it most certainly isn't often.
So if you want to write an SMS, and send it now. a radio connection must be established. In GSM, this requires an SDCCH (Standalone dedicated control channel). This is a finite network resource (even if you are using it for 5 seconds or so, it is still a finite resource). In most cells, a static reservation of 8 SDCCHes exists only. Also, setting up this SDCCH involves other temporary channels - it occupies capacity on the AGCH (access grant channel) and RACH (random access channel - to establish the request in the first place). If it is an incoming SMS, it additionally requires capacity on the PCH (paging channel). All of these latter channels have particularly finite resources.
In UMTS ("3G"), the scenario is similar. SMS is typically delivered over the FACH (forward access channel) mapped to the S-CCPCH. The S-CCPCH has very limited capacity in most networks, and is being shared between other requests to establish channels, mobility updates from phones moving about, etc etc etc.
The point is SMS does consume finite network resources, and they are more finite than you think. Your assumption/myth might be valid if you can piggy back SMS onto the back of the (typical) hourly location updates that occur, but who wants their SMSes to all be buffered once an hour?
A non-AT&T iPhone will almost certainly never do HSUPA on AT&T, and would almost certainly cost way more than just buying an AT&T iPhone.
Can I ask why? I've taken a UMTS850/2100 handset with E-DCH & HSDPA to the US and used it fine on AT&T prepaid? Are you saying I was only using a Release 99 channel in the uplink, not a HSUPA channel?
I would be very worried about any user mode code that can blue screen the system.
The bluescreen is simply an indication kernel mode state is horribly inconsistent. Whatever the code was able to do to corrupt OS state, there is a good chance this could be used as an attack vector.
Making an application crash is often the point of discovery of new exploits.
The IMEI is usually sent over an encrypted channel, after the CIPHERING MODE COMMAND has been sent in GSM (although the specifications do not mandate this).
It is not possible to track your long term movements. GSM and UMTS use what is known as the TMSI - the Temporary Mobile Subscriber Identity, which is a 32-bit temporary identifier which may not persist more than a few hours at a time.
Your IMSI (international mobile subscriber identity) is only ever sent over the air in clear text in 'recovery' situations, where your mobility context cannot be retrieved from the previous VLR. Otherwise, new TMSIs are allocated over an encrypted channel, so it is extremely difficult to establish a chain of TMSIs.
So in short, it is not possible to establish your long term visiting trends, but it is possible to establish the length of time you spend in a shopping centre (as phones periodically re-register themselves with the network, even in the same location area), if your phone is otherwise idle.
Our meters already do a spot empty check to clear existing funds out of the meter when someone leaves.
This is a serious dick move. Seriously. Just a dick move.
Agreed. The meter is paid, who cares who paid for it? Stop double dipping.
Though on the topic of dick moves, the US has it pretty easy. Look for these vermin (The Melbourne City Council) are up to:
http://www.melbourne.vic.gov.au/AboutCouncil/MediaReleases/Pages/NewparkingtechnologyforCityofMelbourne.aspx
In ground sensors - a device that records when a vehicle moves in and out of a parking bay. A five minute grace period will be built in and once a vehicle has overstayed the limit a signal will be sent to the nearest parking officer’s hand-held device. The in ground sensors will be progressively rolled out to 4,619 single marked bays across the CBD from 1 July to 30 October.
Licence plate recognition systems – image processing technology used to identify a vehicle via its number plate in some residential areas. The system consists of a high speed digital camera, integrated GPS system and optical character recognition software. Two systems will be in operation in Flemington, Kensington, North Melbourne and Carlton. The license plate recognition technology will be on the road from 1 July.
This is simply a myth. The sending of text messages consumes network resources that cost money. How much they cost is a different question - and I am not disagreeing with you that the markup may be exhorbitant, but I do have to correct your claim.
In GSM, sending a text message still predominantly operates over an SDCCH (standalone dedicated control channel), which requires a full paging (for network originated) or random access cycle, encryption setup messages, authentication messages. The whole process can take around 5 seconds (don't believe me? put your phone on top of an old radio so you can hear the radio transmission activity..)
Where your claim is correct is during a call - the SMS uses the SACCH (slow associated CCH) which places minimal additional load on the network, but the majority of SMSes occur when the phone is not in a call.
Some GSM networks allow the text message to be send as a packet of data over GPRS/EDGE which greatly reduces radio-link (Um link) signalling burden.
Your experience is dated. In Guangdong Province, 2010, I found facebook & youtube completely blocked.
I also found anything containing prohibited keywords appeared to be blocked by means of sending an RST packet after a packet or two of data, so briefly you would see the text of http://en.wikipedia.org/wiki/Dalai_Lama for example, before Firefox would advise that the 'connection was reset whilst the page was loading'. Furtheremore, additional requests to that website's IP were completely denied for some random time (typically a few minutes).
Even pages discussing the filter were blocked in much the same way.
Absolutely right. It does seem people have jumepd the gun on this. Whilst it is certainly an impressive feat of debugging/disassembly, the AACS scheme itself has not been cracked or compromised.
AACS were aware, like almost everyone on this forum, that media keys and even device keys will be leaked out of a player somewhere given enough effort. Indeed, the same argument holds for the content itself - if it can be viewed then it exists decrypted somewhere.
This is why at the heart of AACS is a revocation algorithm significantly more advanced than CSS (which allows revocation of a player key that is shared between many players of a manufacturer etc). In other words, every future disc pressed can revoke this player (WinDVD). AACS can cryptographically revoke any particular player or set of players it likes without significant overhead. For those interested, the subset-cover algorithm does about 1.25 subset-differences per revocation, and each entry for a subset-difference is 16+5 = 21 bytes, so every player in the world that is eventually revoked only adds 26 bytes to the MKB (disc header) of every disc produced from the on.
Actually I should include a shameless plug on a posting of mine which attempts to explain how this algorithm works, if you're _really_ interested.
Another poster responded to this parent that revoking WinDVD would inconvenience a lot of people using this player. And that I think is one of the weaknesses of the implementation of AACS - software players. On the other hand, it is fairly easy to update a software player over the internet to use new keys, but all any new version of WinDVD would be doing is hiding its AACS code/keys in more obscure ways, which we know is like throwing a chair in the path of someone chasing you =)
Yes this is how I've used NT (and later XP) with reasonable success. I usually just do a runas/user:administrator cmd.exe
and from then on if I need a program that *must* require Admin privileges (or change settings), it can be done from the command prompt:
i.e. "start ethereal" or "start devmgmt.msc" (Device Manager) or "netsh" (change network parameters).
For more stubborn programs that you use frequently you can usually track the non-execution to poor programming practice (via debugging utilities like Regmon) like attempts to write to the applications directory, or to HKEY_LOCAL_MACHINE\Software\CrapVendor\CrapApplica tion, both of which can be resolved changing ACLs.
The holy grail would be to scan the mobile phone command frequency band - one would only need to know one's target's phone number to triangulate his/her position. I don't know of anyone who's done this, but I'll be attempting it myself over the holidays.
This is difficult in both the CDMA and GSM systems.
In CDMA spread spectrum with scrambling codes makes it difficult to detect a transmission amongst noise without knowledge of the scrambling code.
In GSM frequency hopping makes it difficult to detect a transmission, particularly when multiple users are operating in the area.
As both of these technologies can operate over a wide band of frequencies (particularly if you don't know the operator the person is with) you won't be able to pull this off with amateur grade equipment.
Slashdot Mirror
Sure the digital baseband is all the same, as the signal coming in is usually at a specific IF regardless of the band.
It is the old fashioned hard wired analog circuitry that is the issue, and that is not just the antenna.
Think filters, duplexers, etc which are designed and optimised for a certain band. Not to mention amplifiers and mixers. As someone who has designed active RF & microwave circuits, it is not easy achieving broadband filtering and impedance matching at multiple bands. So you need to have multiple filters, components, etc, which adds $$ to cost. So you pick a handful of bands that you want to support, and swap the components depending on the regional variation of your model.
Is there a reason that there 'almost has to be a markup'(beyond the costs of shipping)?
Australia's position relatively far from anywhere
It's closer to the heard of world manufacturing than Europe OR the USA, by a long margin.
[1]: Along with SHAtter. Screw you, Geohot, for blowing a low level exploit because of your ego.
To be fair, it's possible SHAtter and limera1n would have been plugged at the same time by the same fix.
They both depend on bugs in the firmware read-back mode code in DFU mode. Limera1n exploits a bug in which the direction bit of the USB transfer is automatically trusted to match the command type, and SHAtter exploits a bug in which the read index offset (a global variable) is not reset after each call to re-initialize the USB code in the outer loop. Both bugs were "fixed" by the removal of the firmware read-back code in A5 devices.
It's substantially more complicated than that. If it were as simple as every buffer overflow being exploitable in this way, then jailbreaks would come thick and fast after every release.
With iOS you have:
(a) stack is never executable, so all payload must be ret-to-libC style
(b) consequently, because user space address layout is randomized with about 8 bits of entropy, you have to find a way to leak address of a symbol, or else find some more sophisticated exploit
(c) even if you defeat above, you still only have typically gained executable control over a restricted user account
(d) now you have to trigger a kernel exploit from restricted process space sandbox OR
(d)+(e) break out of the sandbox or gain root with another userland exploit in order to be able to trigger the kernel exploit, which may depend on functionality accessible from root only
Anyway you get the idea. My hat goes off to pod2g and co for their dedication.
The fundamental flaw here is that cable capacity is shared between *all* users from the local node, i.e. everyone in your street, unlike ADSL.
Therefore, there's not really much improvement to be made. The only possible optimisation with this hypothetical IP system would be to "detect" that everyone is watching Australian Idol (or whatever people watch these days) and then allocate more capacity to that program perhaps to improve video quality. Otherwise, if everyone is watching something different it's no different to the current "broadcast" situation. DVB is compressed, usually with an MPEG-4 class of video codec, so it's already highly efficient.
Oh, and particularly with digital transmissions, there already is a substantial channel changing delay anyway, even with "broadcast" style DVB. Especially the case with MPEG-4 I've noticed, up to a couple of seconds even on modern receivers; even if the channel is on the same transport stream (i.e. same carrier), while it waits for enough key frame data to accumulate. Even worse delay if its on a different carrier, because the lower level receiver has to synchronise to that.
Warranty deadlines seem to be a very typical US-consumer-shafting.
If the product has failed due to manufacturing defect despite reasonable use, then the retailer (and then ultimately manufacturer) is required to replace it. If this is a few days out of the manufacturer's warranty it is usually irrelevant.
See Warranties and Refunds - ACCC
Statutory rights are not limited to a set time
period. Instead, they apply for the amount of time
that is reasonable to expect, given the cost and
quality of the item.
This means a consumer may be entitled to a
remedy under their statutory rights after any
manufacturer’s voluntary or extended warranty has
expired.
For example, it is reasonable to expect that an
expensive television should not develop a serious
fault after 13 months of normal use. In this case,
the consumer could argue the item was not of
merchantable quality and ask for it to be repaired,
even if the manufacturer’s voluntary warranty had
expired.
Those 300Mbps speeds are quoted for 4x4 MIMO configuration for 20MHz bandwidth.
Telstra are using a 2x2 MIMO with 10MHz bandwidth. The theoretical speeds are closer to 90MBps, and indeed, if you read the whirlpool forums, people are in fact getting close to that.
The television has detected more persons in the room than this content is licensed for.
Please reduce the number of persons in the room, or press the RED button to authorise a payment of a $X per additional person in the room.
Transport Modules
Further to this, here is an example of some paging traffic I captured over a live UMTS network (Telstra NextG, in Australia), using nothing more than a USRP with 900MHz daughterboard, and some custom Matlab code. The message has been unpacked from ASN.1 format to XML, but it clearly shows IMSI and TMSI in plaintext.
File is here.
This shows the flaw is definitely not GSM only.
The concepts here are not necessarily specific to the GSM Um link. The same concepts used by the authors equally apply for UMTS and LTE, and most other cellular systems.
ALL of those systems page out phones based on some temporary (but plaintext) identifier when an incoming call needs to be routed and there is no active RRC (radio) connection. All of those systems try to mitigate this exact problem by using a temporary ID (the TMSI), rather than the permanent ID (the IMSI). The TMSI is re-allocated over a ciphered connection.
The TMSI rotation policy is up to the operator. It can in theory be rotated each connection, but few operators do this - too much signalling load on the core network. Most operators will hold the TMSI until the next periodic (i.e. after a certain number of hours - operator defined), or aperiodic (when the phone moves into a different paging domain [location area]), or when the phone is power cycled (which implicitly does a type of location update anyway).
One solution for future versions of the standard might be to encrypt the paging message (along with a random nonce to give uniqueness to each paging message) with the last known ciphering key, but this may not be known by the network entities in the new location areas.
I don't know how this myth keeps getting propagated. It is absolutely not true, for both the GSM and UMTS systems.
You don't need to have a background in cellular engineering to understand that if you want to use a service in near real-time (i.e. SMS), it is going to have to consume resources then and now.
Your phone is not using control channels constantly. This is for good reason - the control channels are extremely limited in capacity, and using them frequently would consume your battery as well.
Your phone is only using control channels typically when moving between cells or locations areas. You can easily see this on GSM phones if you have an old radio nearby; you will know when the phone is transmitting and it most certainly isn't often.
So if you want to write an SMS, and send it now. a radio connection must be established. In GSM, this requires an SDCCH (Standalone dedicated control channel). This is a finite network resource (even if you are using it for 5 seconds or so, it is still a finite resource). In most cells, a static reservation of 8 SDCCHes exists only. Also, setting up this SDCCH involves other temporary channels - it occupies capacity on the AGCH (access grant channel) and RACH (random access channel - to establish the request in the first place). If it is an incoming SMS, it additionally requires capacity on the PCH (paging channel). All of these latter channels have particularly finite resources.
In UMTS ("3G"), the scenario is similar. SMS is typically delivered over the FACH (forward access channel) mapped to the S-CCPCH. The S-CCPCH has very limited capacity in most networks, and is being shared between other requests to establish channels, mobility updates from phones moving about, etc etc etc.
The point is SMS does consume finite network resources, and they are more finite than you think. Your assumption/myth might be valid if you can piggy back SMS onto the back of the (typical) hourly location updates that occur, but who wants their SMSes to all be buffered once an hour?
A non-AT&T iPhone will almost certainly never do HSUPA on AT&T, and would almost certainly cost way more than just buying an AT&T iPhone.
Can I ask why? I've taken a UMTS850/2100 handset with E-DCH & HSDPA to the US and used it fine on AT&T prepaid? Are you saying I was only using a Release 99 channel in the uplink, not a HSUPA channel?
I would be very worried about any user mode code that can blue screen the system.
The bluescreen is simply an indication kernel mode state is horribly inconsistent. Whatever the code was able to do to corrupt OS state, there is a good chance this could be used as an attack vector.
Making an application crash is often the point of discovery of new exploits.
The IMEI is usually sent over an encrypted channel, after the CIPHERING MODE COMMAND has been sent in GSM (although the specifications do not mandate this).
It is not possible to track your long term movements. GSM and UMTS use what is known as the TMSI - the Temporary Mobile Subscriber Identity, which is a 32-bit temporary identifier which may not persist more than a few hours at a time.
Your IMSI (international mobile subscriber identity) is only ever sent over the air in clear text in 'recovery' situations, where your mobility context cannot be retrieved from the previous VLR. Otherwise, new TMSIs are allocated over an encrypted channel, so it is extremely difficult to establish a chain of TMSIs.
So in short, it is not possible to establish your long term visiting trends, but it is possible to establish the length of time you spend in a shopping centre (as phones periodically re-register themselves with the network, even in the same location area), if your phone is otherwise idle.
Our meters already do a spot empty check to clear existing funds out of the meter when someone leaves.
This is a serious dick move. Seriously. Just a dick move.
Agreed. The meter is paid, who cares who paid for it? Stop double dipping.
Though on the topic of dick moves, the US has it pretty easy. Look for these vermin (The Melbourne City Council) are up to:
http://www.melbourne.vic.gov.au/AboutCouncil/MediaReleases/Pages/NewparkingtechnologyforCityofMelbourne.aspx
In ground sensors - a device that records when a vehicle moves in and out of a parking bay. A five minute grace period will be built in and once a vehicle has overstayed the limit a signal will be sent to the nearest parking officer’s hand-held device. The in ground sensors will be progressively rolled out to 4,619 single marked bays across the CBD from 1 July to 30 October.
Licence plate recognition systems – image processing technology used to identify a vehicle via its number plate in some residential areas. The system consists of a high speed digital camera, integrated GPS system and optical character recognition software. Two systems will be in operation in Flemington, Kensington, North Melbourne and Carlton. The license plate recognition technology will be on the road from 1 July.
This is simply a myth. The sending of text messages consumes network resources that cost money. How much they cost is a different question - and I am not disagreeing with you that the markup may be exhorbitant, but I do have to correct your claim.
In GSM, sending a text message still predominantly operates over an SDCCH (standalone dedicated control channel), which requires a full paging (for network originated) or random access cycle, encryption setup messages, authentication messages. The whole process can take around 5 seconds (don't believe me? put your phone on top of an old radio so you can hear the radio transmission activity..)
Where your claim is correct is during a call - the SMS uses the SACCH (slow associated CCH) which places minimal additional load on the network, but the majority of SMSes occur when the phone is not in a call.
Some GSM networks allow the text message to be send as a packet of data over GPRS/EDGE which greatly reduces radio-link (Um link) signalling burden.
Your experience is dated. In Guangdong Province, 2010, I found facebook & youtube completely blocked.
I also found anything containing prohibited keywords appeared to be blocked by means of sending an RST packet after a packet or two of data, so briefly you would see the text of http://en.wikipedia.org/wiki/Dalai_Lama for example, before Firefox would advise that the 'connection was reset whilst the page was loading'. Furtheremore, additional requests to that website's IP were completely denied for some random time (typically a few minutes).
Even pages discussing the filter were blocked in much the same way.
All digital cellular phone standards in use today (GSM, UMTS, CDMA, etc) encrypt SMS messages and voice calls and it is almost always enabled.
That being said the strength of the various algorithms remains questionable (shameless plug).
But to say it is outright plaintext and broadcast is plain wrong.
Absolutely right. It does seem people have jumepd the gun on this. Whilst it is certainly an impressive feat of debugging/disassembly, the AACS scheme itself has not been cracked or compromised.
AACS were aware, like almost everyone on this forum, that media keys and even device keys will be leaked out of a player somewhere given enough effort. Indeed, the same argument holds for the content itself - if it can be viewed then it exists decrypted somewhere.
This is why at the heart of AACS is a revocation algorithm significantly more advanced than CSS (which allows revocation of a player key that is shared between many players of a manufacturer etc). In other words, every future disc pressed can revoke this player (WinDVD). AACS can cryptographically revoke any particular player or set of players it likes without significant overhead. For those interested, the subset-cover algorithm does about 1.25 subset-differences per revocation, and each entry for a subset-difference is 16+5 = 21 bytes, so every player in the world that is eventually revoked only adds 26 bytes to the MKB (disc header) of every disc produced from the on.
Actually I should include a shameless plug on a posting of mine which attempts to explain how this algorithm works, if you're _really_ interested.
Another poster responded to this parent that revoking WinDVD would inconvenience a lot of people using this player. And that I think is one of the weaknesses of the implementation of AACS - software players. On the other hand, it is fairly easy to update a software player over the internet to use new keys, but all any new version of WinDVD would be doing is hiding its AACS code/keys in more obscure ways, which we know is like throwing a chair in the path of someone chasing you =)
Tomorrow: Microsoft patents walking..
Even with incoming airtime charges the United States of America has far cheaper cellular call charges than in Australia.
Yes this is how I've used NT (and later XP) with reasonable success. I usually just do a runas /user:administrator cmd.exe
a tion, both of which can be resolved changing ACLs.
and from then on if I need a program that *must* require Admin privileges (or change settings), it can be done from the command prompt:
i.e. "start ethereal" or "start devmgmt.msc" (Device Manager) or "netsh" (change network parameters).
For more stubborn programs that you use frequently you can usually track the non-execution to poor programming practice (via debugging utilities like Regmon) like attempts to write to the applications directory, or to HKEY_LOCAL_MACHINE\Software\CrapVendor\CrapApplic
Isn't this in violation of Visa/Mastercard "no-issuer-discrimination" rules?
The holy grail would be to scan the mobile phone command frequency band - one would only need to know one's target's phone number to triangulate his/her position. I don't know of anyone who's done this, but I'll be attempting it myself over the holidays.
This is difficult in both the CDMA and GSM systems.
In CDMA spread spectrum with scrambling codes makes it difficult to detect a transmission amongst noise without knowledge of the scrambling code.
In GSM frequency hopping makes it difficult to detect a transmission, particularly when multiple users are operating in the area.
As both of these technologies can operate over a wide band of frequencies (particularly if you don't know the operator the person is with) you won't be able to pull this off with amateur grade equipment.