💾 Archived View for clemat.is › saccophore › library › ezines › textfiles › ezines › K1INE › k-1ine_… captured on 2022-01-08 at 16:18:05.

View Raw

More Information

⬅️ Previous capture (2021-12-04)

-=-=-=-=-=-=-

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 -. �                                                          |


 _____________________________________________________________________________

 � .- 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:

 <BEGIN HCSW INTERNAL MEMO>

 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.

 <END HCSW INTERNAL MEMO>

 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:

 <BEGIN HCSW INTERNAL 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.

 <END HCSW INTERNAL MEMO>

 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

 ---

 <theclone> 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:

 <!-- notes from thief: have fun! -->
 
 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

--

<Flopik> now is time to make love with my girlfriend
<Flopik> love is all you need

<FlopikSleep> I dont have a girlfriend shrug
<FlopikSleep> 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   ;..;..
                          .;..;               ;..;..
                     ;  .;..;.;..   .; .  .;. ..;..
                    .;..   . .;  ..;..;..;.. .;
                ;..;.   .;.. . .;.. .;.;.
              ..;. ..;.. .;.   ;.;..;;..;.;
                ;.;;..;..      ;.;.; .; .
                   ;.;..;. .;. ;.;:.;.
                     ,;....;.
               .;.;. .;.;
              .;.;.;
            .;.;
            ;..;.
           .;.;;.; .;. ..; ;. > > > > > > ... <warVamp> I'm going to kill you, clone!