-o[ Defeating the Caller ID system ]o- -o[ D4RKCYDE ]o- -o[ by hybr1d ]o---------------------------------------- -----BEGIN PGP SIGNED MESSAGE----- Defeating The Caller ID System With Simple but Effective Stealth. July 1999. hybrid (hybrid@dtmf.org) (http://hybrid.dtmf.org) quick disclaimer: I do not encourage any of the information provided in this file. I, or f41th cannot be held responcerble for your use of the information provided in this article, it has been provided for informational purposes only. (introduction) CallerID (CID) or CND (Calling Number Delivery), is an extension to the widley used ANI (Automatic Number Identification) system. The telcos use ANI as a means for billing information when you make a toll-call, however dispite what alot of people think, ANI is not used as part of the CID system, it was the first system used to allow the recieving party know who was calling and was widely used before the advent of the SS7 telephony protocol, but sinse the implementation of SS7 CID/CND has become popular, both in residential subscriber loops, and commercial lines. In this file I am going to show how the CID/CND system works, specific to different *bell specifications aswell as the differences in other countrys, such as the UK. Before we go any further, you need to know the basics of the *bell CID protocol; CID information (data) is transmitted on the subscriber loop using a method known as FSK (Frequency Shift Keyed) modem tones. This data is transmitted in ASCII format and contains the information needed to display the CID mesage at the terminating line. The actual data burst occurs between the first and second ring of the line, and contains basic information about the originating point of the call, such as the date, time, and of course the calling number. On more upto date systems, or in a local area, the name of the caller will be displayed next to their number aswell. Further advances in CID include a new system called CIDCW or (CID on Call Waiting), where the call waiting tone is heard and the CID of the second calling person is exposed. (definition) As I said before, Caller ID is the identification of the originating subscriber line. For example, say you had a line installed under your own name, your details would be stored alongside your line information in your telcos directory listings. So when you call someone with a CID unit that displays the calling partys name, your name would be displayed alongside the number, or whoever pays the bill for the line. Obviously the telco has no real way of knowing just _who_ is making the call, so the term Caller ID would be inapropriate, and should technically be refered to as Calling Number Identification because it is the name of the person associate with the line rental, and not your docs that are transmitted. The actual CID information is transmitted to the terminating subscriber loop, as I said before, between the first and second ring implementing a bell202 type modem specification. There are 2 tones that are tranmitted, one of them contains the mark transmission (logic 1) and the other contains the space transmmision (logic 0), mark and space. The transmitted message contains a channel seizure string and then a mark string followed by the actual caller information. If the recieving line only has basic CID information installed (where they only recieve the date, time and number of the caller) SDMF (Single Data Message Format) is used in the CID data burst. If however, the recieving person has a more advanced version of CID where they can see the name of the person calling, MDMF (Multiple Data Message Format) is used in the data burst. If the MDMF method is used, and you have withheld your CID, the recieving line will only see a message saying the information was blocked by the caller, or is unavailable. Later I will discuss ways of making your line information completly unavailable to the called party. In New Jersey 1987, the first CID service was offered to subscribers of NJBell because NJBell where at that time implementing new high-speed networks and wanted to rake in a little more money by offering this new service to its customers. Before SS7 ANI was used as a means of obtaining the calling number info as a means for billing purposes on certain lines. Before SS7, your ANI would go no furthur than your central office, and would not be forwarded to international calls. However, that was then and this is now, SS7 has been implemented big time over the international/national PSTN (Public Switched Telephone Network) and ANI can be a phreaks worst enemy. These days ANI information can be transmitted internationaly, and in some cases globably, depending on the similaritys of the concerned signalling/switching systems. Numbers that are renowned for implementing full ANI capture are 800 and 900 services (full SS7 based) aswell as operator services, and of course 911. ANI is _completly_ different from CID, so if you call a line that has an ANI service installed, you will not be able to block your line information from going through as ANI works on a different protocol than CID, ie, the * services used to withhold your CID wont work on an ANI system because they are designed _only_ for blocking of CID _not_ ANI, remember they are completly different things. There are alot of rumours that I have heard from people about ANI, such as its supposid ability to capture your line information, which ever method you use to call a number. The fact is, ANI is dependant on SS7, which in turn is dependant on translation tables, who says you have to use the SS7 network to call someone ;> I'll go into this further later in this file. Now, back to CID; Because of the mass implementation of the SS7 protocol, CID informaion is transmitted to the called party's central office. This is done using SS7, and is called CPNM or (Calling Party Number Message). Now, heres the bitch of SS7; when you call someone, your line informaion is sent to the persons central office _regardless_ of the fact that you may have reqested that your line informaion is withheld. If you have withheld your CID, the remote person's central office still get your line information, but notices that you reqested that your info is withheld (UNLESS the person you are calling has a deal with their local telco to expose any CID information held at their central office to be automaticaly transmited to their CID unit, Thats where things begin to get nasty (at the end of the day, the telcos are more concerned about the money they are recieving for providing _full_ CID services to people, and could'nt care less if you reqested your line informaion remains private). (lets get technical) -- exphunged from CallerID specifications by Michael W. Slawson Eventually standard CID (SDMF) where only the calling number and date etc are displayed will be completly phased out and replace by the enhanced CNAM (Calling Name Delivery) where the MDMF data burst transmission is used. The CID information is sent serially at a rate of 1200 bits per second using continuous-phase binary frequency shift keying for modulation. The two frequencies used to represent the binary states are 1200 Hz for the Mark (logic 1) and 2200 Hz for the Space (logic 0). The data is sent asynchronously between the first and second ring at a signal level of -13.5 dBm. The level is measured at the central office across a 900 ohm test termination. Following a minimum of 500 ms after the end of the first ring, the sequence of transmission begins with a Channel Seizure. The Channel Seizure is a string of 300 continuous bits (250 ms) of alternating "0"s and "1"s. This string starts with a "0" and ends with a "1". A Mark Signal of 180 mark bits (150 ms) is sent immediately following the Channel Seizure Signal. The purpose of the Channel Seizure Signal and the Mark Signal is to prepare the data receiver in the Customer Premise Equipment (CPE) for the reception of the actual CID transmission. Once the Channel Seizure and Mark Signals have been sent the CID information is then transmitted starting with the Least Significant Bit (LSB) of the most significant character. This is true for both SDMF and MDMF. Each character in the message consists of 8 bits. For displayable characters these bits represent a code defined by the American Standard Code for Information Interchange. When transmitted the character's 8 bits are preceded by a start bit (space) and followed by a stop bit (mark) giving a total of 10 bits sent for each character. The CID information is followed by a checksum for error detection. Figure 1 shows a visual layout depicting the association of the 1st Ring, Channel Seizure Signal, Mark Signal, Caller ID information, Checksum, and the 2nd Ring. The checksum word is a twos complement of the modulo 256 sum of each bit in the other words of the message. The Channel Seizure and Mark Signals are not included in this checksum. When the message is received by the CPE it checks for errors by taking the received checksum word and adding the modulo 256 sum of all of the other words received in the message. The addition done by the CPE does not include the Channel Seizure and Mark Signals, nor does it include the received checksum word. The result of this addition should be zero to indicate that no errors have been detected. Figure 2 shows a CID message in SDMF. For ease in describing the process of determining the checksum, the decimal values will be used for the calculations. Character Decimal ASCII Actual Description Value Value Bits (LSB) - ------------------- ------- ----- --------------- Message Type (SDMF) 4 0 0 0 0 0 1 0 0 Message Length (9) 18 0 0 0 1 0 0 1 0 Month (December) 49 1 0 0 1 1 0 0 0 1 50 2 0 0 1 1 0 0 1 0 Day (25) 50 2 0 0 1 1 0 0 1 0 53 5 0 0 1 1 0 1 0 1 Hour (3pm) 49 1 0 0 1 1 0 0 0 1 53 5 0 0 1 1 0 1 0 1 Minutes (30) 51 3 0 0 1 1 0 0 1 1 48 0 0 0 1 1 0 0 0 0 Number (6061234567) 54 6 0 0 1 1 0 1 1 0 48 0 0 0 1 1 0 0 0 0 54 6 0 0 1 1 0 1 1 0 49 1 0 0 1 1 0 0 0 1 50 2 0 0 1 1 0 0 1 0 51 3 0 0 1 1 0 0 1 1 52 4 0 0 1 1 0 1 0 0 53 5 0 0 1 1 0 1 0 1 54 6 0 0 1 1 0 1 1 0 55 7 0 0 1 1 0 1 1 1 Checksum 79 0 1 0 0 1 1 1 1 The first step is to add up the values of all of the fields (not including the checksum). In this example the total would be 945. This total is then divided by 256. The quotient is discarded and the remainder (177) is the modulo 256 sum. The binary equivalent of 177 is 10110001. To get the twos compliment start with the ones compliment (01001110), which is obtained by inverting each bit, and add 1. The twos compliment of a binary 10110001 is 01001111 (decimal 79). This is the checksum that is sent at the end of the CID information. When the CPE receives the CID message it also does a modulo 256 sum of the fields, however it does not do a twos complement. If the twos complement of the modulo 256 sum (01001111) is added to just the modulo 256 sum (10110001) the result will be zero. If the result is not zero then the message is discarded. It is important to note that there is no error correction in this method. Even if the CPE were to notify the central office of errors, the central office will not retransmit the information. If an error is detected, the CPE receiving the message should display an error message or nothing at all. Although Bellcore SR-TSV-002476 recommends that the CPE display an error message if erroneous data is received, most CPE manufacturers have elected to just ignore the errored message. The content of the CID message itself depends on whether it is in SDMF or MDMF. A message in SDMF includes a Message Type word, a Message Length word, and the actual Message words. A message in MDMF also includes a Message Type word, a Message Length word, and the actual Message words, but additionally includes Parameter Type and Parameter Length words. There are certain points within these messages where up to 10 Mark bits may be inserted to allow for equipment delays in the central office. These Stuffed Mark bits are generally not necessary. The Message Type word defines whether the message is in SDMF or MDMF. It will be a binary 00000100 (decimal 4) for SDMF or a binary 10000000 (decimal 128) for MDMF. The Message Length will include the number of characters in the message. This length does not include the checksum at the end of the message. For SDMF the minimum length will be 9 characters. The minimum length for MDMF will depend on whether the customer has subscribed to CNAM service as well as CND. In the case of CND only the minimum length will be 13 characters. If the customer also has CNAM then the minimum will be 16 characters. In all three of the minimums mentioned there will be no actual number or name delivered. The field will be marked either "O" (Out of area) or "P" (Private). Figure 3 shows an example of a minimum message layout for SDMF. The number will not be delivered because it has been blocked by the calling party. The CPE will receive the date, time, and a "P" to indicate that the caller's identification has been blocked at the caller's request. Character Decimal ASCII Actual Description Value Value Bits (LSB) - ------------------- ------- ----- --------------- Message Type (SDMF) 4 0 0 0 0 0 1 0 0 Message Length (9) 9 0 0 0 0 1 0 0 1 Month (December) 49 1 0 0 1 1 0 0 0 1 50 2 0 0 1 1 0 0 1 0 Day (25) 50 2 0 0 1 1 0 0 1 0 53 5 0 0 1 1 0 1 0 1 Hour (3pm) 49 1 0 0 1 1 0 0 0 1 53 5 0 0 1 1 0 1 0 1 Minutes (30) 51 3 0 0 1 1 0 0 1 1 48 0 0 0 1 1 0 0 0 0 Private 80 P 0 1 0 1 0 0 0 0 Checksum 16 0 0 0 1 0 0 0 0 Character Decimal ASCII Actual Description Value Value Bits (LSB) - -------------------------- ------- ----- --------------- Message Type (MDMF) 128 1 0 0 0 0 0 0 0 Message Length (33) 33 0 0 1 0 0 0 0 1 Parameter Type (Date/Time) 1 0 0 0 0 0 0 0 1 Parameter Length (8) 8 0 0 0 0 1 0 0 0 Month (November) 49 1 0 0 1 1 0 0 0 1 49 1 0 0 1 1 0 0 0 1 Day (28) 50 2 0 0 1 1 0 0 1 0 56 8 0 0 1 1 1 0 0 0 Hour (3pm) 49 1 0 0 1 1 0 0 0 1 53 5 0 0 1 1 0 1 0 1 Minutes (43) 52 4 0 0 1 1 0 1 0 0 51 3 0 0 1 1 0 0 1 1 Parameter Type (Number) 2 0 0 0 0 0 0 1 0 Parameter Length (10) 10 0 0 0 0 1 0 1 0 Number (6062241359) 54 6 0 0 1 1 0 1 1 0 48 0 0 0 1 1 0 0 0 0 54 6 0 0 1 1 0 1 1 0 50 2 0 0 1 1 0 0 1 0 50 2 0 0 1 1 0 0 1 0 52 4 0 0 1 1 0 1 0 0 49 1 0 0 1 1 0 0 0 1 51 3 0 0 1 1 0 0 1 1 53 5 0 0 1 1 0 1 0 1 57 9 0 0 1 1 1 0 0 1 Parameter Type (Name) 7 0 0 0 0 0 1 1 1 Parameter Length (9) 9 0 0 0 0 1 0 0 1 Name (Joe Smith) 74 J 0 1 0 0 1 0 1 0 111 o 0 1 1 0 1 1 1 1 101 e 0 1 1 0 0 1 0 1 32 0 0 1 0 0 0 0 0 83 S 0 1 0 1 0 0 1 1 109 m 0 1 1 0 1 1 0 1 105 i 0 1 1 0 1 0 0 1 116 t 0 1 1 1 0 1 0 0 104 h 0 1 1 0 1 0 0 0 Checksum 88 0 1 0 1 1 0 0 0 In Figure 4, if the number and name had not been included then the parameter types for those fields would be different. These alternate parameter types are used to signify that the data contained in that parameter is the reason for its absence. The parameter type for the number section would have been a binary 00000100 (decimal 4) and the parameter type for the name section would have been a binary 00001000 (decimal 8). When the parameter type signifies that the data contained is the reason for that fields absence, the parameter length is always a binary 00000001 (decimal 1). If the reason for absence is that the calling party does not want their number/name displayed then the parameter data would be a binary 01010000 (ASCII "P") for Private. If the reason for absence is that the information is just not available then the parameter data would be a binary 01001111 (ASCII "O") for Out of area. The number/name may not be available if the calling party is not served by a central office capable of relaying the information on through the network. (lets talk d1rty) The above specifications are relevant to the US CID system, and not to the UK specification. Enough of the technical stuff for now though, its time to look at CID systems from an attack and deffense point of view. First the real basics; if you are in US you can reqest that your CID is withheld by using *67 as a prefix when dialing a number. As I said before though, this is absolutly usless in completly withholding your CID because we know that CID information is passed onto the called party's central office regardless of *67 via implementation of the SS7 network. If you are in the UK you would prefix your call with 141, but again our nice systemX digital exchanges a real bitches at passing on our CID information to _other_ exchanges, so in essance your call routing is loged as it passes through exchange boundarys on the PSTN. So here I am going to discuss different techniques that can be used to completly render your CID information useless as it is transmitted through various excahanges and offices. I'm going to begin with some basic concepts so you can understand the more advanced techniques better. Now, lets consider this scenario for the following techniques; You are in Texas (RBOC: SWBell) and you want to set-up a call to someone in Chicago (Ameritech). Obviously, you know that *67 wont help you if the person you are calling has full CID (or has access to there central office ;>) so you consider the following techniques and call-setup examples. [ example A: simple diverting ] Here you can use a host that will be traced back to in the advent that the person has full CID. In other words, its real simple, you use a PBX (preferably a long distance one located in another RBOC). This is very self explanitory, but alot of people get it wrong. Heres how the call setup would look in a metaphorical diagram: ______ ______ ______ | | | | | | (800)XXX-XXXX | CO |------------->| CO |------->| PBX | POTS:(123)456-7890 |______| |______|<-------|______| | | | | | __|___ ( you ) | | | CO |----------------------> ( them ) |______| Now, whats happening here is you are calling the PBX at *671800XXXXXXX, you then login to the PBX and from there you dial the person you want to call. When the person checks there CID unit, they will see the number of the PBX you are calling from instead of your actuall originating number. Now, this is OK for very very very simple CID spoofing, but if the person you are calling is resoursefull, they could very easily have words with the host from which you where calling from (who would have your ANI -its an 800 number) The CO of the PBX would also have the time, date, and trunk setup information for when you called the PBX etc, so this example is still not quite as effective as you would imagine it to be. Now, to make a long story short, we can enhacne the above method by implementing our _own_ CID blocking methods along the above routing example. Look at the diagram in detail, and you will realise that there can be many different alterations made that can make the routing alot safer, and _alot_ more hastle for them to pin-point your OCP, or originating point. First we take into account the call we make to the PBX. For starters, you can op-divert to the 800 number (depending on where you live) so the 800 PBX recieves operator assisted call ANI instead of yours. This can be done very easily, and involves you calling your local operator and asking them to call the number for you. The central office located near to the PBX then has the OPC of your operator, rather than you. Now, the PBX host is your safgaurd when it comes to hiding your CID. For those of you who dont know, all PBXs or privatly owned switching and trunking mechanisms/systems log incomming and outgoing trunk setups for billing purposses etc. These days, most PBX exchanges have administration modules that deal with call routing. The call-setups are stored in the databases of the PBXs and can be intercepted. Most of the time, a PBX will have 1 if not several dialin modems that connect to the PBX administration modules for remote maintanance. Its simply a case of internally scanning the extensions of the remote PBX for a carrier, and checking out each one until you find what you are looking for. Once you have access, you could do _many_ things depending on how advanced the system is. For example, you could erase any log of your connection to the PBX (aswell as any furture connections), you can set up incomming and outgoing trunks on the PBX exchange that dont even exist, you can also select which trunk you wish to call your party with and therefore selecting which number you wish to be displayed to the called party. I wont go into to much detail here, you get the picture right? So now we are using a host to call through that will not log anything that could point towards you, with the exeption of the timestamping at the central officess along the routing path. (again, that could be delt with in a similar fashion). You could also implement op-diverting from the PBX to the dialed person, or triple the amount of hosts you use to place the call at the same time using the above methods, but via more PBXs and operators. In my opinion though, the above method is no way near as secure as you need it to be, so in the next examples, we take adavntage of ld-carriers, and global PSTN networks that do not co-operate with each other, ie: calling party data is not translatable or transmitable (electromechanical). Now, to really throw someone off track in the advent of a trace (realtime or aftermath) we take advantage of one of the biggest flaws in the PSTN known today: new digital exchange units such as digital ESS, systemX etc cannot effectivly communicate with older lesser implemented electromechanical exchanges such as crossbar, and CCITT#5 protocols implemented in lesser developed countrys such as Indonisia, Libia etc. The worlds telcos are also very lazy when it comes to passing on originating calling party information from country to country, simply because it is to much hastle for them, time and money runs into the picture once more. So ld call setups become a good counter defense when it comes to routing un-traceable calls. Now, I can think of literaly 100s of methods that could be implemented here, but I'm going to discuss the structure of how this type of call would be setup, I'll leave the rest to your imagination (if you have one) [ example B: international routing ] Now, consider the previous call setup example, and imagine how it would be trunked if you placed a long distance barrier in-between. Here we will imagine we have 2 PBXs, one in the US and one in the UK. Again, you are in Texas and want to setup a call to someone in Chicago without revealing your identity. The basic call setup would appear like this: ______ ______ ______ | | | | | | (800)XXX-XXXX | CO |------------->| CO |------->| PBX | POTS:(123)456-7890 |______| |______|<-------|______| | | ___ | [ US PSTN ] | ESS routing .--->|co | | __|___ ____|_ |___|------ ( them ) ( you ) | | | | | CO |------->| DMS | (international DMS |______| |______| gateway router) : : : [ super LD ] .........................\........................ \ : So here you have op diverted : to the US PBX, then from the : US PBX op diverted and called ______ ___:__ the PBX in the UK, already | |------->| | the UK PBX has lost the US | CO |<-------| DMS | (international DMS PBXs CID, and from the UK PBX |______| |______| gateway router) you call the person in chicago, |: which in turn is re-routed back |: through the international PSTN |: [ UK PSTN ] systemx routing effectivly deteriating your __|:__ origionating line. | | | PBX | (UK PBX) |______| The problem with this kind of routing example is that you are costing the 2 PBX exchanges involved big bux, and is generaly not a very nice thing to do, heh. Again, as in the previous example, you can implement the PBX administration for extra security, the above diagram could be used vise-versa whether your origionating point was the UK or US. It is howver inconvinient, both for you, and for the poor owners of the PBXs who have to falk out for your toll-fraud adventures. There are however other ways of implementing the above techniques. Now, probably the most favourable technique to use would be to box your way out of a country that runs C5, and from there re-route a call back to the US and even implement a few PBXs along the way, therefore you would have [ 0 ] CID worrys. A more advanced technique involves the forwarding of subscriber lines to a designated number (A C5 country direct, PBX etc). Now, if you are in the US, you could be super lame and simply have another US line forwarded to another number via the means of posing to the forwarded lines co as a field engineer requesting a line be forwarded to xxx while you carry out field 'maintanance' on it, _or_ if you wanna stay away from the lameness, you could so this: Lets take Indonisia for example. You can remotely forward an Indonisian residential line to anywhere you want (providing you can find an english speaking exchange). Indonisia is just an example, but like the US method of forwarding lines you have 2 options. You could a) pose a local field engineer, or if the country has a DMS[+] architecture you could forward the lines via the means of remote switch access. (Thats another file, but you get the general idea). So, when it comes down to it, its all about having the ability to route calls, not spoof them. So, there you have it, a brief guide to CID blocking (the effective way), its your choice, *67 (blah) or *67,00-->1800XXXXXXX-->*67,00-->1800XXXXXX(CD)--> KP2-44-141-0800-XXXXXXX-ST -->001-1800XXXXXXX-->*67,00-->555-555-5555 hello? :> I hope you enjoyed this file as much as I did writing it, take it easy and remember to check out my website.. :) Shouts to 9x, substance, downtime, ch1ckie, oclet, jasun, zomba, psyclone, bodie, digiphreq, w1repa1r, gr1p, t1p, jorge, b4b0, shadowx, osiris, essgurl, lowtek, pbxphreak, katkilla, drphace, prez, euk, simmeth, dgtlfokus, voltage, knight, siezer, oeb, lusta, infidel, devious, werd to #9x #darkcyde #phunc #b4b0 #2600 #2600-uk & wErd to D4RKCYDE. : . http://hybrid.dtmf.org ___ ___ _____.___.____________________ ____________ hybrid@b4b0.org / | \\__ | |\______ \______ \/_ \______ \ hybrid@ninex.com / ~ \/ | | | | _/| _/ | || | \ hybrid@dtmf.org \ Y /\____ | | | \| | \ | || hy_ \ \___|_ / / ______| |______ /|____|_ / |___/_______ / +++ NO CARRIER \/ \/ : \/ \/ . \/ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: cp850 iQEVAwUBN5dSy7TUyHciIYgJAQGcSgf/er3ngPoYsPon9rmU4VG0klcp9koc5aoA hBBheVxeeVQOzrUl0kPv5sCUPdHoEKbabHqAyDcoJY9feoM5aZ4U0kryuTBm415z M57ff31CH+T+8iUaW7ZlQkBfFuJfNr2B3pro6KvDGzU2S7nJhYSCugoCf3IExlLt +FSXEAl+HC0PCpDcEYlQ+2kNwgOBMLLQ9w3On/vFcRJnD26E9Hk4j5IMv8iv+37F sdQDDhqQ3ah2y1CN3KGAOrcsaYRhT1OyLjbw+JDwR1buCa38yqawBjpbAuM/PTfU eoNCmwzFEucjcFKpQJisT1428MgeuK2cWmIj8flfuIr9fhIi/7wdNA== =570J -----END PGP SIGNATURE-----