98 lines
6.8 KiB
Plaintext
98 lines
6.8 KiB
Plaintext
|
|
|
|
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.
|
|
|