I've been playing around with the A6 Gprs chip from Ai thinker.
So I was able to send a SMS:
AT+CMGF=1
AT+CMGS=0031612345678
Is it (technical) possible to change (spoof) the sender phone number?
Or can I do it with other chips, like SIM900?
AT commands A6 chip
Typically the phone number is not stored in the SIM card. You have IMSI inside the SIM card and this IMSI binded with your phone number and an authentication key named Ki in the network operator's databases.
When you want to use the operator services, your device (The chip, the handset, etc) send the SIM Card's IMSI to the network operator. Network operator search his database for that IMSI to see if that IMSI is valid or not. If it found that IMSI inside the database, then it generate a random number and encrypt it with the corresponding Ki (that is stored in the database) and returns that encrypted data to your SIM Card. As your SIM card is aware of its Ki, it can decrypt the random number and return it.
Finally if the network operator receive the correct random from the SIM card, your are authenticated to the network. after that, when you call someone or send a message, the network operator concatenate the phone number inside the database with your messages and send them to the other side.
So, no you can't!
If you want to spoof phone numbers yourself, you need to set up a PBX solution like Asterisk, and you need service with a VOIP carrier that allows you to self assign the outbound CNUM data. Those with a legitimate need to do this (corporate PBX admins for example) already know how to accomplish this trivial task. Many others who wish to spoof are up to no good, so I am not going to lay out the details beyond what I have already said. The simplest (perhaps only?) way to spoof cell phone numbers is to run your call through your PBX and back out. I do this all the time to protect my personal cell phone number - however, the number I am sending is simply my home phone number for my VOIP line. No dirty tricks here. If you have a legitimate business need talk to the business sales department at your carrier.
Related
I have experimenting with Bluez 5.50 Bluetooth Stack, Here i have some confusion about procedure Auto-connection using Whitelist.
Suppose,
Device A - Advertiser
Device B - Scanner
Add Advertisers(Device A) Bluetooth address as white list in Scanner(Device B)
Device A will advertise with "Connectable Un-directed" adv type & default adv params
Device B will start scanning with "Accept only PDUs from device in white list" configuration
If B scans A's address, than explicitly B will send connection request to A(Without sending Connection create command)
What is basic difference between paired device & white listed device ?
The white list can be used both when just scanning as well as when connecting.
Note that the packet exchange during advertising is this, when the central device is just scanning:
Advertiser sends ADV_IND.
Scanner sends SCAN_REQ.
Advertiser sends SCAN_RSP.
When the central device has a pending initiation (i.e. connection attempt) to a peripheral, the packet exchange is this:
Advertiser sends ADV_IND.
Initiator sends CONNECT_IND.
The connection is now established.
Note the timing between between to packets in the flow above is 150 microseconds (T_IFS), which is quite quick. If the advertiser does not detect SCAN_REQ, it does not send SCAN_RSP. If it also does not detect CONNECT_IND, it does not enter the connection state, but continue to advertise. There is a need to have a white list because the host would not be quick enough to decide if the packet should be dropped or not. Therefore the white list is implemented directly in the Bluetooth controller hardware.
A central device using the white list, will simply drop any ADV_IND having an address that cannot be found in the white list. Therefore no SCAN_REQ or CONNECT_IND is sent in this case.
"Auto-connect" therefore refers to when the initiator is constantly looking for ADV_IND packets where the sender's address is in the white list. If one is found, a CONNECT_IND is sent and the connection gets established, resulting in an "LE Connection Complete" event. Using the white list is the only way to have two or more pending connections, since otherwise you need to specify exactly one target address when initiating a connection. (Although a workaround sometimes used when the white list cannot be used, for example if it is too small to contain all desired addresses, is to let the central first perform a scan, then initiate a connection to the target addrerss, with some short timeout. This introduces latency as at least two ADV_INDs must be sent.)
Paired/Bonded device is a completely different thing. It means that both devices have stored in its database, information about the remote device, such as encryption keys, client characteristic configuration descriptor state, gatt db cache. Bonded devices are usually listed in a user interface as well.
When the white list is used when establishing connections, you can have addresses in this list of non-bonded devices. You can also have bonded devices which you do not currently want to connect to, which are then not included in the white list.
What I've written above is general BLE without any specific Bluetooth stack in mind. BlueZ might have certain conditions/flows when the white list is used.
I am engineering two BLE devices, a central and peripheral. (Using a PSoC 4 BLE, not that it matters)
There will be a lot of these in a small space, maybe up to 8 within range, but hundreds of peripherals and tens of centrals all coming and going, with no particular rhyme or reason behind which one central/peripheral the user will want to pair at any given time.
I also have an unrelated technology that makes it very easy for the user to move a blob of data from the central to the peripheral of their choosing. I believe this will make pairing much easier in most but not all scenarios.
I figure the non-BLE blob would contain at least the central's mac address, and maybe a randomly generated pin or shared key. Because the blob can only go from the central to the peripheral, the receiving peripheral is really the only device that knows the addresses of the two devices that are supposed to connect.
However, as I understand it, peripherals can't make outgoing connections. I can't swap roles because I still need the BLE search to work the traditional way.
I can think of a lot of ways to get this done, but I'm very interested in hearing the opinion of someone who has worked with BLE long enough to know what might fit best (or if I'm wrong about some assumption).
Some constraints I'm working with:
The peripheral is battery powered.
The usual search and pair method must also still work.
My own half-baked ideas:
Make the peripheral able to be a central too, but then does that
introduce more nuances and complications?
Broadcast from the peripheral, "whoever has X mac address,
please connect to me"
Put a similar message in the advertising packet and increase advertising
rate.
Directed advertising similar to above?
You could let the "non-BLE blob" contain a static random address which the central generates. After the peripheral receives that, it starts advertising with that static random address. The central is also configured to initiate a connection to that particular static random address. Will this work?
Being somewhat of a newbie I was wondering if there is a way to hard-code something on a peripheral that would only allow a single unique central/master to connect.....?
i.e. / eg
I have the ‘simple chat’ Arduino app on a RedBearLab Blend-Micro (which is for all intensive purposes the same as a Arduino Uno with a BLE shield) and I only want one single / unique phone to BE ABLE TO connect with it and therefore work with it.
My understanding is that the GAP handles security features during a BLE connection.
Therefore, is there some way to ‘code’ the peripheral device in / below one of the following includes:
spi.h ?
boards.h ?
EEPROM.h ?
RBL_nRF8001.h (or similar) ?
Other?
Didn't quite get an answer from Restricting the BLE peripheral device to connect to only one Master
OR
Am I stuck with EVERYTHING connecting but coding the peripheral in some other way in a GATT profile (I think) to ONLY do something with a predefined unique central/master (how/where to code?).
Many thanks for thoughts in advance
Being somewhat of a newbie I was wondering if there is a way to hard-code something on a peripheral that would only allow a single unique central/master to connect.....?
Theres the "Advertising Filter Policy" as specified in the Bluetooth Core V4.0 specification. Its a Byte in the Advertising Parameters as specified in Section 7.8.5 LE Set Advertising Parameters Command.
For example the value 0x02 reads Allow Scan Request from Any, Allow Connect Request from White List Only.
Then theres section 7.8.16 LE Add Device To White List Command.
That said, if your device confirms to the Bluetooth 4.0 specification, it should support these HCI commands. However there might be functions that simplify these procedures, wrapping those HCI commands for easier use. Check the Documentation of your device for such methods.
Good Luck!
I was asked to answer this question via email. It's been almost a year since I quit working on BLE. So I only answer this question based on my memories.
Basically #dominik has it right.
If the device is freshly new, it should advertise normally (without setting the whitelist only bit), then any central device could connect and bond. Once it is bonded, you should save this bonded flag and the bonded master's bd_addr to EEPROM. If the next time the master is lost, you will advertise with that white-list-only flag set. If a new central tries to connect, you could verify if its address is the same as your master.
I don't have the BLE spec at hand and I kind of forgot a lot about BLE already. Probably the spec says somewhere that if a central sees a peripheral device is broadcasting with white-list-only flag set, it wouldn't try to connect if it doesn't recognize that peripheral device. This saves both some effort.
But a master could always initiate a connection to your peripheral device regardless the white-list-only flag. So checking if the connecting central device's address is the same as your previously bonded master is the last resort.
[Update]
I used CSR1010 chips. I remembered that the BLE stack actually allows me to insert a list of bd_addr to the white-list data structure maintained by the stack. Then, with the white-list-only flag set, the lower-level stack layer will help you filter devices that are not in that white-list without your knowing.
However, you can always filter bd_addrs from your application code.
We have a web application and would like its users to enter PIN numbers for their debit cards in the web-based UI. However, we must be able to perform DUKPT key management and TDES encryption on the PIN number, and we are beginning to think that DUKPT will force us to use an actual, manufactured "PIN Entry Device", like a swipe card reading device.
This seems to be the case because the key management scheme requires the device to have a list of 'Future Keys' and/or a 'KSN'/'Key Serial Number'.
Does anyone know for certain if this DUKPT requirement will mean that we must enter PIN numbers via the PED all the time? If so, that will likely kill our hopes to have users enter them into a web page.
Thank you!
I would like to use a GSM modem to make a voice call to a phone number, play a recorded message, wait for a digit to be pressed and then disconnect the call. The system needs to know if the line was busy, if the user answered and which digit was pressed by user (if any). It should drop the line if nothing is pressed in 30 seconds. If user presses the digit before the question is completed then the voice should stop (user doesn't have to wait). Also, it would be nice if system could handle invalid digits (play "invalid digit" message, play original message and wait for input). Multiple calls in parallel would be nice, but I guess this is not possible?
I have found this article which explains low-level interface quite nicely. However, this question is more pragmatic - which libraries and which GSM modem would you recommend? OS is Linux, modem can be either RS232 or USB. I would prefer Python, but C(++) is ok too.
BTW: this is not telemarketing, it is a notification system. Not that it matters... ;)
EDIT: I learned this system is known by keyword "IVR" (added for future searchers).
A modem is generally used for data transmission but it sounds like you are actually transmitting voice, albeit prerecorded voice, and tones.
Although you can achieve this with the extra voice capability of a voice modem as you have identified, it might actually be easier to use a GSM to VoIP gateway, unless you actually need the modems data capability for some reason.
You could connect the VoIP to GSM gateway to a low cost or free open source PABX (such as Asterisk) and use this to build your particular application.
Some gateways even support multiple SIMS so you can target the SIM which gives the lowest call rate for the number you are calling - for example if you know that the number you want to call is on a particular operator, then that operator may offer free 'on network' calls between it's SIMs. This might be an advantage if you are expecting to make a large number of calls.
If you do a web search for 'VoIP GSM gateways' you will find some examples.
The following link provides an overview also:
http://www.voip-info.org/wiki/view/VOIP+GSM+Gateways
I am no expert in this field but it is something of a personal project that I have wanted to dive into.
Here is what I think will be the best way to do this.
1 Get yourself a VOIP GSM Gateway like this: VOIP+GSM+Gateways
2 Link into an existing PABX system or download a free one like asterisk
Then you will need to follow the instructions of the PABX development to create your dial plans and routing. I don't know if there are any already out there but I'm sure you will find many examples of the bits and pieces you need.