k-27-(13)-02 .,..,...,.,.,.,................,.,.,.....,..........,...,.,.,.,.............,. i ,;t; .,ijfLLLfti.i i ,jf' ,jLGGGGGGGGGG; i . LL :tLGGGGGGGGGGGGG i .ij' tL' :jLGGGGGGGGGGGGGG i '` .;tftP ;E' :jGGGGGGGGGGGGGGGG i .;:, ,;c ,Li af' fP .LL jGGGGGGGGGGGGGGGGG i :fS"fi ,iLi tf" kP ;f fP ,El;, .iLGGGGGGGGGGGGGGGDD i SGk ,pitp ,iL,y' jf iP ,A ,;AL,LE"' ` tLGGGGGGGGGGGGGGGGEE i fSDk:, ,P"'iG tEe;' jC, ,iEf^tGf"'` iLGGGGGGGGGGGGGGGDEf: i "fSG: dL ,G; Ei ,t^Gic"' ..,,. ,LGGGGGGGGGGGGGGGDEL.: i fSj.M:it" `ift:' .,::iitjfGGGGDL. ,fGGGGGGGGGGGGGGGDD,..; i i; .;j; DP' .,:;;tjffjttfGGGGGGEG.. ;fGGGGGGGGGGGGGGGDD,.. i i `tS;i' G; .,;ttj;;::. :jGGGGGGGDD,. ;LGGGGGGGGGGGGGGDEL... i i iG .,;tt;:. .ifGGGGGGGDEi.. ,fGGGGGGGGGGGGGGDD;.. i i :Pt:,;ii,.. ;fGGGGGGGGGEL.. ,fGGGGGGGGGGGGGDEf:.. i i .;i,i;:. .;jLGGGGGGGGGDE:.. ifGGGGGGGGGGGGGDDt.. i i ::,.: .iLGGGGGGGGGGGDE;.. iLGGGGGGGGGGGGDDi... i i ... :ifGGGGGGGGGGGGDEL.. iLGGGGGGGGGGGDEL,.. i i . .,tLGGGGGGGGGGGGGGEj.. ,tGGGGGGGGGGGDEf:.. i i ;jLGGGGGGGGGGGGGGGDE... ,fGGGGGGGGGGDED;... i i ,ifGGGGGGGGGGGGGGGGGDE;.. .iLGGGGGGGGGDEf,.. i i ,tLGGGGGGGGDGGGGGGGGGGEL.. ,tLGGGGGGGGDEGi... i i :ifGGGGGGGGDEjiiGGGGGGGGDG:. :tLGGGGGGGDDEj,.. i i .ifGGGGGGGGGDEi..:fGGGGGGDEi..:;fGGGGGGGGDDL,... I i :jLGGGGGGGGGGDE;.. iGGGGGGGDG :tLGGGGGGGDELi.... i i .iLGGGGGGGGGGGDEi.. :fGGGGGGDE;:jGGGGGGGDDj;... i i .ifGGGGGGGGGGGGDD:.. :jGGGGGGGDL iLGGGGGGGGEt,.. i i:jGGGGGGGGGGGGGDD;.. .tLGGGGGGDE;:fGGGGGGGGGDEEi... i fjGGGGGGGGGGGGGDE,.. iLGGGGGGGEG..iGGGGGGGGGGGDKf... I DGGGGGGGGGGGGGDD;.. iLGGGGGGGDE;. .iGGGGGGGGGGGDE;.. i EGGGGGGGGGGGGEG:.. .;LGGGGGGGGEi.. :LGGGGGGGGGGGKj... i EGGGGGGGGGGDEj... .tLGGGGGGGGDD:. .fGGGGGGGGGGGKf... i GGGGGGGDDDDj;.. .tLGGGGGGGGGEt.. :fGGGGGGGGGGGKf.. i i.;jjfjji,... :jGGGGGGGGGGDD:.. ,LGGGGGGGGGGDK;.. i i .... ifGGGGGGGGGGDEj.. .tGGGGGGGGGGGDK,.. i i ,jGGGGGGGGGGGGDE.. iLGGGGGGGGGGGDE:.. i i .;LGGGGGGGGGGGGDEj.. .fGGGGGGGGGGGGDE... i i ,fGGGGGGGGGGGGGGDG:. ,LGGGGGGGGGGGGDE.. ,## @@ i i ;fGGGGGGGGGGGGGGDE;.. iLGGGGGGGGGGGGDE.. ## yy kggg, ,nnn, i i :iLGGGGGGGGGGGGGGGEf.. tGGGGGGGGGGGGGDE.. ### #M ## MN NG #ggg# i i :jLGGGGGGGGGGGGGGGDD:.. iGGGGGGGGGGGGGDE.. ## G# #N #N #t i i :jGGGGGGGGGGGGGGGGDE;.. ,LGGGGGGGGGGGGGE;. .G#, MM NG NG 'E##t, i i jGGGGGGGGGGGGGGGGDDj.. :LGGGGGGGGGGGGGDG,. i i ;LGGGGGGGGGGGGGGGDE;.. jGGGGGGGGGGGGGGDG. i i iGGGGGGGGGGGGGGGDEi.. ,LGGGGGGGGGGGGGGGL, i i ;GGGGGGGGGGGGGDED;.. ,GGGGGGGGGGGGGGGGGLLL i i .LGGGGGGGGGGGDDt:.. ;GGGGGGGGGGGGGGGGDEG.. i i .tGGDDDDDEDLi... .iLGGGGGGGGGDDDEfi.. i i ,;tjtti;:... .;tfLLLLLfjti:... i i .... i i i i - K-1ine - 27 - May 2002 - 'Phone Wars Episode II: Attack of The Clone' i i i #,::,:::,:::,;,;,;,::::;:;:::::,;,;,:::::,;::;:::::;,:::,;,;,;,::::::::::,::,# ":;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;:cyb0rg/asm:;;:" ":;;;;;;;;;:;;;;;;;;;;;:;;;;;;;;;;;;;;;:;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;:" `''''''''"'''''''''''""'''''''''''''""""'"''"'''''''''''''''''"'''"' _____________________________________________________________________________ » .- Words from the Editor -. « | *: [-] Introduction .......................................... The Clone :* *: (-) Contact Information ................................... The Clone :* *: (-) Advertisment .......................................... HackerSalvage:* *: (-) Link of the Month ..................................... The Clone :* *: (-) K-1ine Mirrors ........................................ The Clone :* *: (*) K-1ine Desktop Backgrounds ............................ os :* ____________________________________________________________________________ » .- Documents -. « | *: (x) 'Smart Card Reverse Engineering Project' .............. Fractal :* *: (x) 'The Telecommunications Fraud Prevention Committee'.... nemesystm :* *: (x) 'Illinois Video Network Specifications' ............... Google-Girl :* *: (x) 'Clone' ............................................... Firefly :* _____________________________________________________________________________ » .- Conclusion -. « | *: [-] Credits ............................................... The Clone :* *: [-] Shouts ................................................ The Clone :* _____________________________________________________________________________ Introduction - "Not Such A Long Time Ago, in a Galaxy Closer Than Your Local CO..." Welcome to the latest issue of K-1ine zine... Phone Wars II: Attack of The Clone. Thanks to everyone who submitted articles, after I harrassed them once again on the K-1ine mailing list (201 subscribers). I knew that my pain in the ass tactics would pay off again! Enjoy this issue of K-1ine zine, and don't forget to send me more articles in the future. Oh yeah, I spent today working on K-1ine instead of seeing Star Wars Episode II in the theatres. If people tell me it's as bad as the last one, I'll just save myself money and wait 'till it comes out for rental. Enjoy... --> Contact Information; Comments/Questions/Submissions: theclone@hackcanada.com Check out my site: (Nettwerked) http://www.nettwerked.net --> -- Advertisment -- +++ WWW.HACKERSALVAGE.COM +++ HackerSalvage.com is a non-profit website dedicated to keeping old hardware in circulation. Many of us have piles of it sitting around but can't just toss it out. Here you can post computer items for sale or post a want ad for items you are looking for. A perfect place to get rid of perfectly good junk.... and get some new stuff to rebuild the pile. +++ +++ -- --=[ LINK OF THE MONTH ]=-- Every month I post one really great "link of the month" on every issue of K-1ine magazine. The link can be anything in the technology industry, music scene, rave scene, punk scene, or even a good article you read on a news site. I'll be taking submissions via e-mail or IRC right away; so get your links in and maybe you'll see it in the next issue of K-1ine! For the month of May, the link of the month is: www.4os.org 'One Semicolon (0.2) - My Information Systems Security Contribution' [submitted by: os] -- K-1ine Mirrors: http://www.mirrors.wiretapped.net/security/info/textfiles/k1ine/ (Now mirrored in two places, one in Belgium and another in Sydney) "Wiretapped.net is an archive of open source software, informational textfiles and radio/conference broadcasts covering the areas of network and information security, network operations, host integrity, cryptography and privacy, among others. We believe we are now the largest archive of this type of software & information, hosting in excess of 20 gigabytes of information mirrored from around the world." http://www.access-failure.net/files/k-1ine/ Tekk250's mirroring of the K-1ine issues --- K-1ine Desktop Backgrounds: Available in the following formats: 800x600 and 1280X1024 http://www.nettwerked.net/k-1ine-images/index.html Thanks to os of 4os.org for the cool images! --> Smart Card Reverse Engineering Project ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ April, 2002 www.hcsw.org Some time ago, HardCore SoftWare acquired an American Magnetics 170 smart card device and an attempt at reverse engineering it was initiated. No real progress was made, however, until HCSW came into contact with a live smart card implementation. This document attempts to sum up our research into the fascinating field of smart cards. * Goals * Getting a 170 * Interfacing your 170 with a PC * Software * Tips on reversing a smart card implementation * Difficulties in writing * Other areas of research: We need your help! * References Goals ~~~~~ Smart card research is, for many people, a difficult area to get into. High prices and lack of information are the main obstacles to this interesting and rewarding field of experimentation. Many would-be hobbiests are turned away because of the credit card requirment for the purchasing of most equipment. A case could be made by citing free market ideologies and claiming that anyone who really wants a smart card reader will be able to get the money and means of purchasing one, but we at HardCore SoftWare feel this is absolutely unfounded. We believe this attitude is just another corporate strong-arm tactic with greater implications than are immediatley obvious. We believe that this is just another instance of corporations attempting to intellectually neuter the population so that they can maintain a technically elite upper class. We believe this is inexcusable, and must be fought every step of the way. Since it is looking increasingly likely that smart cards will become commonplace in North America, we feel that public participation and experimentation in this field are essential in order to keep large companies and possibly even our own government from abusing this flexible and powerful technology. Accordingly, this document attempts to give you a brief introduction to smart cards, and start your experimenting off by guiding you through the construction of a smart card-PC interface that should end up costing you virtually nothing. Getting a 170 ~~~~~~~~~~~~~ In 2000, an anonymous article [1] was posted to Hackcanada that suggested a cheap, easy, and effective method of obtaining 170s: Ripping them out of the new, obiquitous millenium payphones. The information in the article is for the most part accurate and should be consulted, but I found that attacking the yellow metal from all sides, continually weakening it's attachments, was a more effective and less risky method than the brute-force-and-ignorance (BF&I) method suggested in the article. The 170's seem to have been custom designed for nortel, as the American Magnetics website (www.magstripe.com) doesn't even mention them, and very little information is known about these readers. As such, you may have difficulty obtaining a 170 through legal channels. Should you entertain the common, if unfounded, idea that theft from your telco is immoral, you may have no choice but to ingest some malt liquor beforehand in order to sufficiently lower your fear of getting caught and to reduce your inhibitions. I suggest no more than one 40 isle: You ought to have your wits about you. Interfacing your 170 with a PC ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A crucial breakthrough in our understanding of the 170's pinouts was posted by skarface in [2]. It seems skarface had access to a 170 datasheet long enough to take a screenshot of the pinouts. Fortunatley, this now provides us with more than enough information to interface the smart card component with a PC, and possibly the magstripe too, although this has yet to be researched in depth. Here are the pinouts, thanks again to skarface: .-----.-------------------------. | pin | function | `-----'-------------------------' | 1 | IC CARD C7 (DATA) | | 2 | IC CARD C5 (GND) | | 3 | CARD SEATED SENSOR | | 4 | MAG READER VCC1 | | 5 | IC CARD C1 (POWER) | | 6 | CARD PRESENT SENSOR | | 7 | IC CARD C6 (PROG POWER) | | 8 | IC CARD C2 (RESET) | | 9 | MAG STROBE | | 10 | IC CARD C4 (NOT USED) | | 11 | MAG DATA | | 12 | IC CARD C8 (NOT USED) | | 13 | CIRCUIT GROUND | | 14 | IC CARD C3 (CLOCK) | `-----'-------------------------' NOTE: The RED wire on the ribbon cable of your 170 is considered pin #14. If, for whatever reason, your ribbon cable doesn't have a red pin (or you don't have a ribbon cable at all), pin #14 is the pin closest to the FRONT of the reader (where you insert your card). Reading Luis Padilla Visdomine's article [3], we learn that parallel ports and smart cards use roughly the same electrical levels, and as such can be almost directly connected. Unfortunatley, for most chip cards to work, we need to have a clocking mechanism, which the parallel port doesn't intrinsically provide. We can solve this in the software. We decide that this isn't a signifigant problem, and decide to use the parallel port. We also choose to use Visdomine's pin scheme so as to avoid any confusion. Consulting the ISO7816 standard [4], we find the pinouts of the chip card: 2.2.3) Pin Assignement: C1 : Vcc = 5V C5 : Gnd --------------- C2 : Reset C6 : Vpp C3 : Clock C7 : I/O C4 : RFU C8 : RFU Without getting too heavily into the theory, here's the procedure: 1) Get a bidirectional parallel cable (printer cable) that you don't mind cutting up (Incidentally, you can use any cable that has a DB-25 connector; we used a serial cable). Odds are, you already have at least one lying around in your house. If not, go down to your local used computer shop and you should be able to pick one up for a buck or less. Or you could steal it from Futureshop. Heh. 2) Find some way to make sure you know which pin on the connector goes to which wire. HCSW, like fools, cut the parallel cable in half and had to use an ohmmeter to test each single pin on the cable. This, as you can imagine, was tedious and unrewarding. Ideally, getting a female interface would be the best plan, but you might have to spend money on it, which defeats the whole purpose of this. Actually, if you can find a dead printer, rip the female DB-25 out of there. Check every connection that you make in this way with a ohmmeter, as many parallel cables don't correspond pinwise on either end of the cable (for example, Laplink cables). TIP: Ensure that none of the wires on either the parallel port or the 170 are crossed, as this can easily screw up your voltmeter testing. 3) Connect these pins on the parallel cable to these pins on the 170: Hopefully these badly drawn ASCII diargrams will help you: -------------------- 1 ----RED WIRE---------- \ 1 . . . . . 13 / 2 ---------------------- \ 14 . . . . 25 / . . . --------------- 14 ---------------------- Parallel Cable 170 -------------- --- 4........14 7........12 (OPTIONAL) 5........10 (OPTIONAL) 3.........8 6.........7 2.........5 25.........2 (*) 15.........1 (**) (*) Actually, any one of the numerous ground pins of the parallel port can be used. 25 seems like a good, out of the way one, though. (**) Double check that this connection actually goes through. This would be the most common pin for a parallel cable not to support. Software ~~~~~~~~ Luis Padilla Visdomine has written two BASIC programs [5,6] specifically designed to read european phonecards. Unfortunatley, I found his code difficult to understand, and even more difficult to extend and adapt. These BASIC programs DO work, however, and I suggest you check them out if you have an old tandy laptop or you run windows. Here is a program by HCSW, written in C for the Linux platform. It should be able to be ported to any x86 unix distribution that uses gcc. I imagine a DOS port would also be possible. NOTE: You must be root to run this program. This program is fairly specific towards the laundry cards that we were analyzing, but the code is very modular, and you shouldn't have much difficulty extending it for your own application. This program is covered under the General Public License (GPL). See the file LICENSE included with the program for details. We encourage you to adapt and extend this program. However, by the terms of the GPL, you must make this adapted code public. So, without any further ado, here's the tarball: http://www.hcsw.org/card/smart-1.0.tgz The programmer's interface is relatively straightforward, and you should be able to figure it out by reading the main() function. First off, you must must call the paropen() function, which will return 1 if you have appropriate privileges, and 0 if not. Please preform error checking on this call, otherwise your program will almost certainly segfault. Next, you must call open_sc(). This function will reset the card and prepare it for reading. After the card has been opened in this fashion, you are free to use the lower level I/O routines paraddrinc(), parsend(), and parget(), but be warned, parget() only returns 1 useful bit of information. Preform bitwise AND with parget() and 8, and if the result is positive, the bit is a 1, otherwise it's a 0. Luckily, we've provided a higher level routine, dump_sc(), which takes 2 arguments: an array of integers, and the maximum amount of bytes to read. Ideally, we ought to use unsigned chars instead of ints for this, as only 1 byte of information is stored in each int. Live with it, or change it yourself. So, each int will contain a value between 0 and 255. If the card isn't inserted properly, or the connection is bad, all ints will be 255. There is also a function, amount_on_sc(), which takes an array of integers dumped with dump_sc(), and tells you the amount of credit remaining on our card system (See next section). This is application dependant, and probably won't apply to your smart cards at all. Don't forget, when compiling programs that use outb() and inb() on linux, you must compile using either the -O or the -O2 switch in gcc (The Makefile takes care of this for you in our program). Tips on reversing a smart card implementation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We will take HCSW's experience with smart cards as an example here. We analyzed the CardMate laundry card system using the device and software described above. Naturally, we were all interested in the credit system, so that's what we pursued first. We were all stumped until one morning an HCSW member who wishes to remain anonymous excitedly came up to me and said he'd cracked it wide open. It looks like CardMate had tried some simple obfuscation techniques in order to hide the location of the credit. It was some excellent reverse engineering done by the anonymous member, and I was most impressed. Here's an abstraction from one of our memos: Bytes 52-54 seem to be the location where the credit is stored. Many dumps yield this: Both $4.00 cards: 00 3E 80 003E80 in decimal is 16000 in decimal. 16000 / 4000 = 4.00 A $5.00 card: 00 4E 20 004E20 in decimal is 20000 in decimal. 20000 / 4000 = 5.00 A $6.00 card: 00 5D C0 005DC0 in decimal is 24000 in decimal. 24000 / 4000 = 6.00 A $0.00 card: 00 00 00 00000000 in decimal is 0 in decimal. 0 / 4000 = 0.00 A $0.10 card: 00 01 90 00000190 in decimal is 400 in decimal. 400 / 4000 = 0.10 Since the cards use 3 bytes to store the credit and 4000 seems to be equivalent to $1, we can perform this calculation to find out the maxiumum amount of money a card can hold: FFFFFF in decimal is 16777215. 16777215/4000 = 4194.30375. Therefore, the largest amount possible would be $4194.30, which would be represented on the card by FF FF F0. We dug up a few other pieces of info on the cards. Interestingly enough, there were differences between the newer white cards and the older black cards. Here's another memo: -The first 2 bytes are always 39 and FF. This is probably an identifying header. -Byte 51 seems to be FA on the new, white cards after they've been initialized, but 7D on the older, black cards. Uninitialized cards have 00 at byte 51. -White cards hold exactly 200 bytes of readable storage, where black cards hold 128. All dumps from now on will take this into consideration. Exploring this was a very interesting experience. Had we known what we know now, we would have started off quite a bit differently though. Here are some tips that will hopefully help you in your reverse engineering: * BE ORGANIZED! I can't stress this enough. Label all your dumps well, and keep them catagorized and ordered. Also, mark your cards in some fashion so you don't get THEM confused. * Find out just how much data the cards actually hold early on. With our program, if you read past the end of the card, it will start repeating the stream of data again, so look for repetition of the first few bytes, then only dump that much data in all subsequent dumps. * Analyze the differences in various states of the card. For instance, if you're trying to find out where the credit is stored on the card, dump a card when it's empty, dump the same card with $1, with 2$, with 3$, etc. Then dump it after having spent money. Also, try to get dumps of different cards too. The more data, the better. * If you're analyzing several K of data, you might want to write up a little program that will look for consistent fluctuations in the data. * If you write any programs for your smart card experimentation (in fact, any programs at all) PLAN AHEAD. Make it modular and conceptual so that it will be easy to extend and fix. Difficulties in writing ~~~~~~~~~~~~~~~~~~~~~~~ Forunatley for us, laundry fraud was easy to commit despite the high tech credit system by exploiting a trivial mechanical flaw, so writing to a card wasn't always our top priority. We HAVE been looking into it, and it's now our main goal. Unfortunatley, there is very little information on writing to smart cards that we can find. We do have a few ideas about how to get this information though: See the next section. Other areas of research: We need your help! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * We're always interested in hearing about your success or failures in getting this method to work. Don't hesitate to contact us if you have any questions or comments. * We'd love to hear about other various smart card systems that you've figured out. * We're currently toying with the idea of building a sort of reverse smart card that we can stick into the actual laundry machines so that we can measure the actual electrical levels and signals used to deduct money from the card. The crediting process should be similar, but we don't have access to the machine that adds money on the cards, unfortunatley. Unfortunatley, the parallel port doesn't have enough inputs to measure all the pins at once, so some fanciness might be involved. Obviously some data recording software would have to be written too. * We'd also like to start messing around with the magstripe capabilities of the 170. If you have any info/stories on this, we'd love to hear from you. Contacts ~~~~~~~~ Come visit us at http://www.hcsw.org or E-Mail me, Fractal, at doug@bearcountry.cjb.net You can talk to my idle client as Fractal on irc.hcsw.org, EFNet, irc.h410g3n.com, irc.openprojects.net One other HCSW member. Bright guy. If he comes on IRC, I'll point him out. References ~~~~~~~~~~ [1] - Assaulting Payfones - Anonymous http://www.hackcanada.com/canadian/payphones/payfone_assault.html [2] - AMC 170 Pinout - Skarface http://www.lineman.bell-system.com/texts/amc170_pinout/ [3] - PC-smart card connection - Luis Padilla Visdomine http://www.gae.ucm.es/~padilla/extrawork/pcsmart.html [4] - ISO7816 asynchronous smartcard information - Stephane Bausson http://www.hackcanada.com/ice3/card/iso7816.txt [5] - Program to read/write 1st generation phone cards - Luis Padilla Visdomine http://www.gae.ucm.es/~padilla/extrawork/1smart.bas [6] - Program to read/write 2nd generation phone cards - Luis Padilla Visdomine http://www.gae.ucm.es/~padilla/extrawork/2smart.bas --- don't be such a hate filled alcohol induced pony --- The Telecommunications Fraud Prevention Committee (TFPC) written by nemesystm, member of the dhc. http://dhcorp.cjb.net : neme-dhc@hushmail.com [introduction] In this article I will talk about the TFPC and what this committee actually does. I will take an issue that was raised during a meeting of the TFPC, explain its contents and what is going to happen in the (near) future to clarify exactly what the TFPC's activities are. I have added some miscellaneous information like a contact address and other Anti fraud initiatives in case you want to write to the TFPC or if you want to look into other similar initiatives. While making this article I was amazed how little information people I contacted were willing to give. This was also the reason why I decided to write this article as I stumbled upon the TFPC some time ago and found little to no information about them. I hope this article will be of use to you. please e-mail neme-dhc@hushmail.com if you have questions. nemesystm [What the TFPC does.] According to the guidelines that can be found on the TFPC website(1), "The TFPC is an open industry committee under the Carrier Liaison Committee (CLC). The TFPC provides an open committee to encourage the discussion and resolution, on a voluntary basis, of industry-wide issues associated with telecommunications fraud, and facilitates the exchange of information concerning these topics."(2) This told me next to nothing; a little searching was in order. The following factors affecting telecom fraud are handled by the TFPC:(3) SPI's - Service Provider Identification An SPI is a 4 character code that can be used in SS7 to identify who provides the service of a call. If you would like a short description of SS7 or Switching System 7, go to: www.cid.alcatel.com/doctypes/techprimer/keywords/ss7.jhtml Number pooling Number pooling refers to the blocks of ten thousand numbers and thousand numbers that a provider draws from to provide customers with phone numbers. An example of a ten thousand number block is 214-745-xxxx Merging of the BVDB - Billing Validation DataBase The BVDB's are used by RAO (Revenue Accounting Offices) of the carriers to calculate how much a customer has to pay. Currently BVDB's are not merged so some people try to stay ahead of them. Expansion of the LIDB - Line Information DataBase The LIDB sends a message to the BVDB's telling them about a call that is being made. Fraud happens for example when the LIDB cannot connect to the proper BVDB to write the bill. Additions to LSR - Local Service Requests LSR requests basically occur when you make a local call in North America. You do not pay for the call and therefore it is not recorded in any way. The TFPC is working together with the OBF (Order and Billing Forum) to find a industry wide solution to make it that those calls are also recorded by the DVDB's for the RAO's. A second source(4) also added the following: "While much of the TFPC's activities are shrouded in secrecy, it is actively addressing third number billing, incoming international collect to cellular, incoming payphone and PBX remote access fraud." I think that clears things up a little. [who is in the TFPC.] The TFPC membership consists of a group of carriers including Ameritech, AT&T, Bellsouth, Bell Canada, British Telecom, Sprint and Verizon.(5) A TFPC member must be an organization, company or government agency that is affected by Telecommunications Fraud. Because the TFPC discusses sensitive information a non-disclosure agreement must be signed.(6) When becoming a member of the TFPC you also have to pay a membership fee. The membership fee is relatively small and really more a sign of good will.(7) [what they decide - case study] In the infinite wisdom that the TFPC has, ;) they decided that it was alright to make one of the issues public. The issue I was able to get was Issue #0131(8), subtitled: "Identification of Service Providers for Circuit Switched Calls". The issue was raised by Norb Lucash of the USTA. "Issue statement: In a multi-service provider environment (e.g. resale, unbundling, interconnection) there is a need for a defined architecture(s) to identify entities (companies) that are involved in circuit-switched calls to facilitate billing and auditing." If you look into this you'll see that it means that there was no identification of the individual service providers when phone calls were circuit switched. Apparently Local Service Providers (LSP's) were identified by the originating phone number, but because of the current "environment" this is not working properly, so sometimes calls that cost money can not be properly billed. To solve this problem phone calls are to be accompanied by a SPI. Then everyone can just check the SPI to find out who to bill for the call. There are several solutions to the problem so a strawman was created called "Service Provider Identification Architectural Alternatives Report"(9). Quite the mouthful. This issue was first raised on 11/17/98 and is still being worked on. In general session #28 (one of the tri-yearly meetings) on May 1st of 2001 it was concluded that this was allowed to be made available on the NIIF site. The NIIF were the people that made the strawman. NIIF stands for Network Interconnection Interoperability Forum and is part of the CLC, just like the TFPC is. I believe this will be a recipe for disaster. What if a rather disgruntled individual manages to get the SPI of company X? This individual truly dislikes company X. So he hooks into a main phone line and calls the most expensive places and does it quite often. The company handling the phone calls recognizes the SPI to be from company X. Company X gets the bill and thinks: no problem, we'll just bill the person who made the calls. When company X finds out none of their clients made those calls they have lost money. The choice made from the solutions below will decide how the attack would be done. [the alternatives - case continued] As I said before, there are several solutions to the problem of the SPI's. Here they are: A. Switch-Based Alternative B. Non-Real Time Database Alternative C. Network Database Alternative D. Non-Call Setup Network Alternative E. Phased SPI Implementation Alternative What follows is a run through of how each solution would work. A. Switch-Based Alternative When a call is coming in, information about the account owner of the person calling becomes available as a line-based attribute. Both the acount owner and switch owner information is forwarded in a new parameter in the (SS7) call-setup signalling of the IAM (Initial Address Message). This information is then made available to every network node on the route of the call. When the calls reaches the final switch, similar information of the SPI of the called number is returned via (SS7) response messages, (e.g, ACM (Address Complete Message) and ANM (Answer Message)). When that information is received the originating switch has the option of including it within the originating AMA (Automatic Message Accounting) record of the call. An advantage of this would be that the information would move in real time between the companies involved. But this solution has some problems, it would require that all switches get enhanced, the AMA will have to change to make this possible and it doesn't take care of situations where SPI-type information is needed for numbers which are neither owned by the called nor calling person. B. Non-Real Time Database Alternative With this alternative it is the idea that SPI information should be put in one or more databases not directly connected to the processing of separate calls. The information could then be made available on request to the phone network some time after the call. The time between the call and the receipt of the SPI information can range from mere milliseconds up to weeks. This is actually an alright approach because only one (minor) problem gets created and only one problem remains. Everyone would have to agree who would be the third, independent, party to maintain the database. This alternative would not allow for SPI-based screening for call routing purposes. C. Network Database Alternative Sort of like the Switch-Based Alternative, this does real-time receiving and sending of SPI information when the call gets made. But the Switch-Based Alternative gets the SPI information from the switch. This alternative gets the information from an external database connected to the network. SPI information would then by grabbed by IN (Intelligent Network) or AIN (Advanced Intelligent Network) queries when the call is made. The information could become part of one of the queries currently in use (LNP, LIDB and Toll Free for example) or a completely new query that gets handled by a separate SCP (Service Control Point). D. Non-Call Setup Network Alternative The idea behind this solution is that the SPI information still comes through network signalling but detached from the call setup portion. ONLS (Originating Line Number Screening) and GET DATA (SS7) messaging are a way to get information outside of the standard call setup. E. Phased SPI Implementation Alternative The NIIF analysed the other solutions and figures alternative C is the best way to go as it comes closest to the requirements of the system that is needed. Implementation of any alternative that provides SPI in a real-time way will have a serious impact on the phone network and it will take a long time before it is completely implemented. Not all carriers have a SPI right now, so an expedited solution must be found for their problems. The NIIF thinks a segmented implementation of a limited SPI capability with a non real-time database will be best. In the future the database could be enhanced. A phased approach that begins with including SPI information with a non real-time accessible line-level database appears to be possible to implement in the near future that gives a lot of the wanted attributes. The NIIF thinks it will be best if existing LIDB's get used as a database at first because a lot of the LIDB's will already contain an Account Owner field, are available to most facilities-bases service providers and may not require that much change. Problems with LIDB's are: Potential overload of LIDB queries. Inability to perform batch processing to do off hour downloads. Potential call delay set ups because of the higher amount of queries. [so what is it going to be?] Right now no final decision has been made, all this information has been sent to the OBF (Order & Billing Forum) to make a RFP (Request For Process) so a final decision can be made. By the sounds of things alternative E is probably going to be the "winner" in all of this. [miscellaneous information] The mailing address for the TFPC is(6) TFPC Secretary - ATIS 1200 G St. NW Suite 500 Washington, D.C. 20005 Of course the TFPC is not the only anti fraud initiative. A lot of telephony associations have a anti fraud section as well. I noticed that the following five were mentioned on quite a few websites on telephone fraud. One such source was Agilent(10). Agilent is one of the members of the TFPC. http://www.cfca.org - Communications Fraud Control Association (CFCA) http://www.asisonline.org - American Society for Industrial Security (ASIS) http://www.htcia.org - High Technology Crime Investigation Association (HTCIA) http://www.iir.com/nwccc/nwccc.htm - National White Collar Crime Center (NWCCC) http://www.fraud.org - National Fraud Information Center (NFIC) [conclusion] Judging by the amount of planning, who are members and the work found you can rest assured that once a decision is made all members will implement it. This makes things harder for a phreak. As the discovery of a problem by one company gets shared with other companies even greater vigilance is needed by individuals who do not want word to get out about their tricks. I do not think that committees like the TFPC will succeed in banning out all the mistakes in the telephony network. This article showed that with the introduction of a solution for one problem another potential problem opened. I am sure there are many more. [sources] (1) http://www.atis.org/atis/clc/tfpc/tfpc/tfpchom.htm from "TFPC Guidelines v1.0" published February 2001, (2) found in section II, Mission Statement. http://www.atis.org/pub/clc/tfpc/tfpcguidefinal201.pdf (3) according to a slide show taken from Nortel.com called "Securing Your Net", presented by David Bench, Senior Staff Manager-Industry Forums Liaison US Standards & industry forums team. monitor.pdf and portability.pdf I have lost the links so I have put them up at http://www.emc2k.com/dhcorp/tfpc/monitor.pdf and http://www.emc2k.com/dhcorp/tfpc/portability.pdf (4) from a overview of The Operator, volume I, number 10. read in the letter from the editor section. published October, 1992 http://www.whitaker.com/theoperator/opop0010.htm (5) from "TFPC Company Participants" http://www.atis.org/atis/clc/tfpc/tfpclist.htm (6) Non-disclosure agreement http://www.atis.org/pub/clc/tfpc/nondnew.pdf (7) as assumed by reading "2001 Funding fees for the TFPC" http://www.atis.org/pub/clc/tfpc/tfpc2001fees.doc (8) History of decisions from 1998 until 2001 for issue 131 http://www.atis.org/pub/clc/niif/issues/0131.doc (9) The original link died. I put it up for people to view at http://www.emc2k.com/dhcorp/tfpc/131strawr8.doc (10) The following URL is cut up a bit to fit properly. http://www.agilent.com/cm/commslink/hub/issues/fraud/*CONNECT* fraud_prevent_initiatives.html -- Illinois Video Network Specifications Stolen by: Google-Girl The IVN network architecture consists of Madge Model 20 IMUX switches connected by T-1 circuits to either Madge Model 60 or Model 200 slotted hubs. Traffic is routed from the end user's Model 20 through the T-1s and slotted hubs to the intended recipient of the call. If the desired recipient of the call is not an IVN end user site, the video call is routed through the IVN and out an SBC or Verizon PRI circuit to the outside world. Call specifications on the Illinois Video Network Although the IVN is capable of T-1 speed, the majority of call made on the IVN are 384 KBPS bonded call, utilizing ITU H.320 standards. Off-net sites wishing to make a test call with an IVN user should attempt to make calls conforming to these specifications. Making a test call to the Illinois Video Network The IVN has several "loopback" numbers that are available for testing the connections of both IVN users and those sites wishing to connect a videoconference call to an IVN site. They are also used as network troubleshooting aids by IVN personnel for diagnosing possible network and equipment trouble at IVN end user sites. These are for testing use only; please do not "camp" in a loopback, as these numbers need to be available for all IVN members. Below is a list of available loopback numbers: Springfield Loopback A 217-263-1005 Springfield Loopback B 217-263-1007 Chicago Loopback 312-814-4075 Carbondale Loopback 217-263-0278 Collinsville Loopback 217-263-0249 Peoria Loopback 217-263-0066 Joliet Loopback 312-338-8148 Rockford Loopback 312-338-8146 Network Control Center (217) 524-4784 Open seven days a week, twenty-four hours a day. Please call the Network Control Center only for network problems and only when the Help Desk is not open. --- Clone Clone me, let my mirror walk the world, read my mind and find, something on hind, sight not so bright. Clone me, and find the things, you didn't want to know, want me to show. In your thirst, you clone me, and then you find, you didn't want two, that do what they do. And you didn't want two, That fuck up and screw you. Clone me, and find your fears, lose your happy cheers, for my existence, is your extermination. Your loss: my win. Your loss: my gain. You might be smart, but I'm insane, something that'll get me further, further then a brain. Clone me, and be sorry. Clone me, and be abhorred. Clone me and repent, for all wasted time spent, for all DNA bent. Clone me, and hate yourself, for being able, to buy me off the shelf, or off the rack. You might crack, but I'm cloned, so kill me, And I live. If I'd kill you, I'd give YOU, your reality, your imperfect world. But I'd look in the mirror, knowing, because of that mirror showing, that I am doing the same thing, in a different place. Clone me, and see. Feelings of hate and anxiety, for I am disturbed, and will create a problem. You will have to exterminate me terminate me, Like a little insect. I have copies, so who cares? I have backups, so who dares? To bring me back, to make me crack up, and open, something hidden, something lurking, murking, what you didn't want to know, but you get the knowledge, and look at your sorrow. So clone me and see how confusing it gets. All the problems it creates, in a world with no safety nets. Clone me, and fear the day that comes, where sons are clones, created by moms, in white jackets. Silly faggots, Clone me, and be sorry. - Firefly -- now is time to make love with my girlfriend love is all you need I dont have a girlfriend shrug I just want to look cool -- -- Credits Without the following contributions, this zine issue would be fairly delayed or not released. So thank you to the following people: Firefly, Fractal, Google-Girl, nemesystm, os -- Shouts: CYB0RG/ASM, Wildman, H410g3n, warVamp, The Question, plappy, rt, Magma, Hack Canada, HackTel Corporation, The Grasshopper Unit, Flippersmack, *Mandy*, soapie, `enjoy, Flopik, the security expert wannabes @ MONTAGE.DMC, and lastly to everyone and anyone who contributes to the Canadian H/P scene. ;. .;.. ; ;. ;.. ;.. .;..; .;.; .;; ;.. .;..;. .;..; .;.;...; ;..;.. .;. A .;. .;. ;.. N E T T W E R K E D ;.. ;..;.. P R O D U C T ;..;.. .;..; ;..;.. ; .;..;.;.. .; . .;. ..;.. .;.. . .; ..;..;..;.. .; ;..;. .;.. . .;.. .;.;. ..;. ..;.. .;. ;.;..;;..;.; ;.;;..;.. ;.;.; .; . ;.;..;. .;. ;.;:.;. ,;....;. .;.;. .;.; .;.;.; .;.; ;..;. .;.;;.; .;. ..; ;. > > > > > > ... I'm going to kill you, clone!