💾 Archived View for gemini.spam.works › mirrors › textfiles › phreak › verify.asc captured on 2023-01-29 at 10:51:32.

View Raw

More Information

⬅️ Previous capture (2020-10-31)

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



                                 Verification

                               By Fred Steinbeck



From TAP issue # 88  10-83



   There has been a great deal of controversy in the realm of phreakdom over a

mysterious subject known under a number of different names, including

"Verification", "Autoverification", "Verify", "Autoverify", "Verify Busy", and

even "VFY BY".  All of these names basically mean the same thing: the ability

to listen to another person's telephone line from any telephone in the

direct-dialable world.

   Needless to say, Bell System is very tight lipped about knowledge regarding

verification.  Indeed, the infamous book 'Notes on long distance dialing' ('68

edition) says, "Care must be taken to insure that the customer never gains

verification capabilities."  With a printed policy like that, you can imagine

what their real-world policy is like!  Even their own rate and route operators

will not give verification on routing codes (at least in my experience), one

even responding, "What?! You must be crazy! We don't give those out!" Before

you get too far into this article, I will state simply: I don't know how to

verify. However, I have been fooling with various things related to it, and

collecting information on it for some time now. Therefore, while I can't do it

(yet), I may be able to point some other bright TAPer on the right track, and

perhaps he or she will show us all how.  If you have knowledge not covered in

this article, but don't want to write an article on your own, please send your

ideas, comments, or information to Project Verify, C/O TAP   Verify has also

been called "Autoverify", and I have no idea why.  This is not, to my

knowledge, a Bell System term (at least I've never seen it in any manuals)  As

far as I know, there is verify, which means being able to listen to speech

(kind of; see below) on a line, and there is the "Emergency Interrupt which

allows you to take part in the conversation taking place on the line in

question.  It has been suggested that "Autoverify" is the same as an emergency

interrupt , but I tend to disagree with this idea.  It should be noted that the

verification circuitry does not actually let an operator listen to a

conversation without making a beep on the line every so often.  Instead, she

will hear encrypted speech.  However, I believe with the proper methods, verify

can be converted to an emergency interrupt.

   Verification is normally done either by your normal "0" (TSPS) operator, if

the call is in your home NPA (HNPA), or by an inward operator (IO).  If the

call is outside your HNPA, your normal operator will call the IO for the

NPA,and say, "Verify Busy" or "Emergency Interrupt" please, 555 1212."  The IO

will perform whatever magic he or she must, and then report back.  If the call

is in your HNPA, though, the "0" operator can do the verification herself by

using the "VFY BY" key on her keyshelf.  However, in some areas, the operator

uses a routing code to accomplish verification, and this the is loop hole we

shall attack.

  It follows that if a IO or "0" operator can do it, so can we, with a blue box

Now, courtesy of Robert Allen (who brought it to my attention) and Susan

Thunder (who apparently discovered it), here is what used to work for getting

operators to hook you into conversations with other people (i.e.,let you listen

to them till you hung up): You'd call the operator and say "Operator, TSPS

Maintenance Engineer Calling.  Ring forward to 001 + NPA + 7d, ring back to my

number, hit ring forward, no AMA, and then position release.

   This creates some problems, and you must be familiar with the TSPS

console(by dialing "0"), you are on the "back", or incoming part of a loop.

When she places a call for you, the call goes out on the "forward", or outgoing

part of the loop.  If an operator wants to make a call, she punches KP FWD

(keypulse forward), the number, and ST. Ring FWD puts a 90 volt ringing signal

across the forward part of the line (and may dial the number as well).  The

problem arises from the fact that I don't know if Ring FWD will actually dial a

call, and if there is some other subtle difference between it an KP FWD.

   Let us assume ringing forward makes a call from the TSPS console to whatever

number is given.  Ring back causes your phone to ring (it is assumed you hung

up after giving her your instructions; if you didn't you'd hear an annoying 90

volts across the earpiece...) "No AMA" means "no automatic message accounting",

so nobody gets billed for the call, although it will show up on a tape

somewhere.  "Position Release" removes the operator from the circuit, and

allows her to receive other calls.  This leaves an unaccounted-for ring

forward.

   The verification circuit, as you know, likes to encrypt conversation, which

is something we don't want.  Well, the second Ring FWD sends another  90 volts

crashing against the verify circuitry, which Juda Gerad thinks removes the

voice encryption from the line, puts the operator (and you) in circuit, and

puts a beep tone on the line every five seconds.  This seems to make sense, and

I am inclined to agree with him.

   The bit about "....001 + NPA + 7D" causes the thought "MF routing code" to

spring immediately to mind.  Now, the above trick was supposed to work in the

213 NPA.  I have tried both "KP+001+213+7D+ST", and some other area codes.  I

generally get nothing, a reorder signal, or a tandem recording.

   Here's some food for thought: On an official Telco sheet I have, labeled "

213 NPA MF Routing Codes", 001 is listed as "VFY BY", or verify busy for the

213 NPA.  002 is listed for the 805 NPA.  Ma Bell likes to have standardized

routing codes, such logical, then, that 001 would be a sort of "standard"

verify code, and other prefixes would be tacked on at 002,003, etc. However, I

have heard from a retired operator that verification codes are different from

area to area, and are not always nice numbers like 001, 002.  Ah, well, a guy

can hope, can't he?

   Some suggestions for future attacks on this dilemma: Everyone call your

operators and subtly ask questions.  I have found the tend to give information

out easier if you ask for something that you would ordinarily have to be a

company employee to know about, such as rate steps, operator routings, etc.

    Casually let slip that you used to be (or still are) an operator, or that

you work for company security.  Also, you might want to blue box some codes

like 001 followed by your NPA and the last 7D of a busy number.  If you get a

sort of "whispery noise", try blasting the line with a ringing signal (you

might piggyback another line onto yours and call the piggyback to generate the

90 volts) and see if that does anything.