==Phrack Inc.==

               Volume 0x0b, Issue 0x3c, Phile #0x0e of 0x10

|=------------------------=[ Traffic Lights ]=---------------------------=|
|=-----------------------------------------------------------------------=|
|=-----------------------=[ plunkett@hush.com ]=-------------------------=|

.:Saving the planet, again:.

/* 
 * This is purely educational; 
 * Any knowledge gained from this document is self imposed and thus
 * the author cannot be held responsible. Any activities resulting from
 * knowledge gained in this document is not accountable by the author.
 * If you do not accept this, please refrain from reading further.
 *
 */
#include <disclaimer.h>

A more environmentally friendly way of traveling by car. As some
of you might recall in almost all the hacking movies, books, TV shows, etc.
there has been a case of someone fiddling with traffic lights. Well we all
just giggled at the unrealistic aspect of it and didn't think twice. Well in
my quest for a more appealing planet for our children I felt compelled to
think of a way in order to reduce the amount of pollution emitted by
vehicles of today.
Standing at a intersection, nobody else around, you're still stuck behind the
red light, and this invisible barrier of governmental guilt has enough power
to let you wait there and pollute the air more and more, just for a measly
green light. Wouldn't it be leet having a laptop in the car where you could
just select the intersection off a list, change the timing or current stream
running, and ride off with fewer time wasted and fewer pollutants exhausted
and a clear conscience.

Now, enough crap about the reasons, now for the technical shit.

Today's traffic controlling system is a well oiled redundant network that
utilizes the same protocols that we are all aware of. Yes it is hackable
and it is like in the movies. :)
here we go!

a description of some of the terms used.

 - controller
        This is the technical term for a traffic light and will be
        referred to that way.
 - UTC
        Urban Traffic Control, solid-state signal controllers connected
        to central computer by means of PSTN. Provides communication
        standard for controllers (see fig. 1)

 - SCOOT
        Split Cycle Offset Optimization Technique.
        A standard now implemented across majority of traffic systems
        across the world. It provides adaptive control of controllers,
        this is done by the controlling office, it receives the traffic
        flow data from closed loops around the intersection, which it
        analysis and relays back current configurations in real-time
        back to the controller.

 - ITS  Intelligent Transport Systems, This is just a buzzword to describe
        the whole system covering everything, UTC, SCOOT, CCTV(video) and
        the whole protocol stack interlinking all of it. (see fig. 2)

 - NTCIP
        This is the protocol that is in process of becoming a standard
        for traffic management communications. It is based on TCP/IP and
        revolves mainly on SNMP that has specific MIB's for use in
        controller messaging. (protocol may vary from country to country)
        Some controllers in US are NTCIP compatible, namely Thereon and model
        170 of NEMA controllers. CCTV, VMS, Field Processors, Ramp metering
        are all linked via NTCIP.

 - ATC
        Area Traffic Control, This is the Central office that control
        all the aspects of traffic control management.

 - FEP
        Front End Processor, Virtual Processing for controllers. located
        before management computer, and connected directly to controllers
        via instation modem rack or telemetry hardware. One FEP
        supports up to 512 PSTN lines.

 - OTU
        In UK this is the Outstation Transmission Unit, this provides the
        means of converting serial data coming from the central computer
        to parallel data for use in the controller, and provides
        interchangeability of controllers.
        (I'm not sure if this system is a standard across the world, for
         South Africa it is done by a CCIU Controller Communication Interface
         Unit}
 - CMU
        Cabinet Monitoring Unit, This is what detects when you fiddle inside
        the box next to the road. It reports hardware/software faults and
        packages the data for reporting to the FEP and ATC.



Figure 1.  Different link arrangements
-------------------------------------

                  ---0 junction 1
                 /
   0------------0----0 junction 2
 CENTRAL  LOCAL  \ 
 OFFICE  EXCHANGE ---0 junction 3

              [UTC Radial Arrangement]


                  ---0  junction 1
                 /    \
   0------------0      \
  C.O          L.E   0-- junction 2
                       /
                      /
                     0 junction 3

           [UK Multi-drop UTC arrangement]



Figure 2.  ITS Topologies
-------------------------

         ________     ________        ________
        |COMPUTER|---|COMPUTER|------|COMPUTER|
        `--------'   `--------'      `--------'
  (coax)    |_____        |  (dialup)    |__    (radio)
                  |       |                 |
      __________  |   ____|_____       _____|_____
     |CONTROLLER|-|  |  MASTER  |__   |FIELD PROC.|__
     `----------' |  `----------'  |  `-----------'  |
      __________  |   __________   |   ___________   |
     | VAX/VMS  |-|  |  VAX/VMS |__|  |CCTV CAMERA|__|
     `----------' |  `----------'  |  `-----------'  |
      __________  |   __________   |   ___________   |
     |COUNTSTION|-|  |CONTROLLER|__|  |CONTROLLER |__|
     `----------'    `----------'     `-----------'  |
                                       ___________   |
                                      | VAX/VMS   |__|
                                      `-----------'

    (Physical links   (Physical links   (physical links
     EIA 232)          FSK-modem)        Fiber)




Introduction
------------

The traffic controller boxes that you see on the road have all a standard
configuration set when commissioned, but they are all linked to a central
office for remote configuration changes, fault reporting, resetting, etc.
The ATC houses a FEP which connects to each controller or the local exchange.
The FEP is the direct network connection to the controllers and queries the
controllers per second bases and receives the responses which are transported
to the central controlling computer [OS/2 or ALPHA VAX in S.A and UK] via
DECnet on coaxial or other means via the LAN. The controlling computer then
analysis the result and determines faults or other data and places it in the
central controlling database on a VAX/VMS. The database is then prioritized
and can be accessed via web interface on the local intranet to see fault
reports and timing info.

When a reconfiguration is issued, an operator can set all configurations
remotely even if a total controller reset is required. This includes stream
timings (streams are the various timing configurations), local time, light
dimming, emergency stream (for ambulances and such), the different settings
will be discussed later. When the operator requests a change in configuration,
it is sent to the FEP in a large datagram which is split up and modulated
for communication to the controller. The protocols between the OTU/CCIU and
the FEP is usually not a standard, and propriety protocols are setup by the
manufacturers of the units.
                  
a diagram of how UTC is interlinked is shown. (fig. 3)
                           
figure 3. Protocol and physical link diagram of UTC system
----------------------------------------------------------
                            ATC                  IN CONTROLLER BOX
   ____________                           :
  |UTC COMPUTER|           RS232 SERIAL   :
  `------------'                          :         SERIAL
         |                    ___ ______  :   _____   :   ________
         | DECnet-> _______  |___|MODEM |-/--|MODEM|-----|OTU/CCIU|
TCP/IP   |---------|  FEP  |_|___| RACK | :  `-----'     `--------'
ETHERNET |         `-------' |___`------' :                  | RS232
LAN   -> |                                :                  | SERIAL
         | (NTCIP encompassed)            :               ___|______
         |   protocols                    :              |CONTROLLER|
         |    _______                     :              `----------'
         |___|       |                    :
             `-------'                    :
             misc. devices                :
             like VAX/VMS for             :
             fault monitoring
             and such.


The communication between the controller and the ATC is done via a 
bit stream signals where certain bits represent a preprogrammed
function in a controller.
A serial second-by-second bit stream is received by each controller
continuously and is converted to parallel for use inside the controller.
The stream consists of 16 bits, Thus 32 parallel connections can be initiated
with the controller, and certain bit streams control certain functions and
some have a return value for example to notify the controller which stream
currently is running. The communication may look similar to this.

1001011011011101 sent
1000101111010101 received

as said, the comms protocol is more than likely to be propriety and thus non
standard. eg. The control bit 10 may 'mean set max green time 30s' and in
another, 'hold vehicle stage'. but according to ATC standards globally,
there are a couple of standards like stream control, emergency control
and resets and more nifty features. 

But this is not important because access to the controlling computer is in
anyway necessary for control of the controller, and thus the specific
protocol used doesn't matter.


----------------------------------------
communication technical details, yummy!
----------------------------------------

UTC messaging
-------------

Below is a typical description of the communication between the controller
and ATC. UTC is the current system that is used in majority of ATC
centers across the world. And communication is pretty much standard.
The specific messaging data bits might be different in different
countries since it is done proprietly by the controller and system
manufacturers. But they tend to stick to a standard, South Africa is based
on the UK system, And the UK system is the same as America, and so it all
will look basically the same, except for area specific functions.

UTC Control and Reply Bits  (Fn = F1,F2,F3... different stages, same for Dx) 
---------------------------
Control      Description                        Reply

Dn (or Dx)   Demand Individual  Stage           SDn/SDx
Fn           Force Stage
FM           Fall Back Mode                     FC
HI           Hurry Call Inhibit
             Stage Confirmation, Stage n        Gn
             Hurry Call Confirmation or Reqst   HC
             Manual Control                     MC
             Emergency Vehicle                  EV
             Vehicle Red Lamp Failure 1         RF1
             Vehicle Red Lamp Failure 2         RF2
SFn          Switch Facility                    SCn
SO           Solar Override
SG           CLF Group Timer Synchronization    CG
LO           Lamps On/Off                       LE
LL           Local Link Inhibit
TS           Time Switch Sync Stored Value
TO           Take Over
TC           Transmission Confirm
CP           Close Car Park                     CL
             Detector Fault Monitor             DF
             CLF Group Timer in First Group     GR1
             Remote Reconnect                   RR
             Entry in Controller Fault Log      CF
             Handset Connected                  TF
             Lamp Fault                         LFn
             Car Park Occup Thresh Exceeded     CA
             Pedestrian Green Confirm           PC
             Queue Detector Presence            VQ
             Detector Vehicle Count             VC
             Car Park Information               CSn
             Queue at Car Park Entry Reservoir  CR
             SCOOT Detector Presence            Vsn
             Cabinet Door Open                  CO
PV           Hold Vehicle Stage
PX           Demand Pedestrian Stage
             Puffin Clearance Period            PR
             Vehicle Green Confirm              GX
             Wait Indicator Confirm             WI

A controller is typically setup to receive 16 to 32 bits of control bits
which can be be replied to by the controller using a reply datagram.
(note that SCOOT specific functions are done in the same way)

typical Control UTC message:

Bytes 1,2 Control Bytes (Address 2)
Byte 3 (F1,F2,F3,D2,D3,DX,SO,-)    (check above table for bit descr)
Byte 4 (-,-,-,-,-,-,-,TS)
      
0 0 0 0 0 0 1 0 0 1 0 1 0 0 1 0 0 0 0 0 0 0 0 0

typical Reply UTC message:

Bytes 1,2 Reply Bytes (Address 2)
Byte 3 (G1,G2,G3,-,-,DF,CF,-)      (check above table for bit descr) 
Byte 4 (-,-,-,-,-,-,-,RT)
      
0 0 0 0 0 0 1 0 0 1 0 1 0 0 1 0 0 0 0 0 0 0 0 0

The communication is done asynchronously and in the controller represented
as parallel, whereas in the FEP its serial. The modulation can be done
either by FEP or instation specific controller cards.


NTCIP Messaging (UK and some US ATC's)
--------------------------------------

I am not going to discuss the specific NTCIP messaging system because it
is not set as a standard yet, and basically, because I haven't had the
pleasure of playing with it. America (except NY and other big
cities), South Africa, Namibia and I think majority of countries
across the world still use SCOOT capable UTC primarily whereas
UK is adopting it as standard.

The NTCIP stack:

Layer           Class A         Class B         Class C
-------------------------------------------------------------
Application (7) SNMP/STMP       SNMP/STMP       SNMP/STMP/FTP
Presentation (6) -              -               -
Session (5)      -              -               -
Transport (4)   UDP             -               TCP/UDP
Network (3)     IP              Null            IP
Data Link (2)   HDLC            HDLC            HDLC
Physical (1)    RS232/FSK       RS232/FSK       RS232/FSK

A and C are not standard but could be used. For
tcp compatibility and routing.
A and C can be implemented as well as additional TCP/IP stacks.

B is defined as standard and is used for bandwidth efficient exchange of
data but does not provide assurance of delivery, this is in turn done
by the physical layer for necessary retransmission.

B only contains three layers, application, data link, physical layer.
This is because the constant line between office and controller is fixed
and thus no routing is necessary and SNMP includes the session features.

NTCIP and SNMP and some STMP:

SNMP commands:
-get
-set
-get Next/get Bulk
-trap

The manager (ATC) may send out 'get' command to retrieve information from
the agent (CONTROLLER) and waits for a reply. But SNMP does not provide
for the agent to initiate contact, and thus the manager polls periodically
with the 'trap' command. This is done on a per second basis.

The typical SNMP frame is 37 Bytes
----------------------------------------------------------------------------
|ver|community|command|req id|error status|error index|objct id|objct value|
----------------------------------------------------------------------------

ver=
      SNMP v1 -NTCIP v2 included security features which they thought
      was a waste of bandwidth- ;)

Id flag=
      is used for matching up the messages with replies

community name=
      essentially a password

core message in Object ID and Value=
      the controller control data and reply section

SNMP is a bandwidth eating protocol, so they designed the STMP
(simple transportation management protocol) which is a cut down vers of SNMP.
It uses the same commands but has the added benefit of having no header and
using dynamic objects. Dynamic objects can encompass a number of variables
like time, date, year and all in one object. The objects are defined online
and both the instation and outstation parties know what the object describes
and thus just a single value needs to be transmitted. The typical size of
an STMP message is 1 byte, with a maximum of 13 dynamic objects.


Comparison Between UTC and NTCIP Messaging
--------------------------------------------
                        UK UTC          NTCIP Class B
Polling cycle           1s              1s
Message size            Fixed           Variable
Device Variables
transmitted             All             Only parameters to be changed
Value of device
variable                Bit             Integer or Bit
Protocols               Proprietary     Standardized



-----------------------------------------------
Hacking the Traffic lights GOdDamnit! #$@#%@#%
-----------------------------------------------

Ok I wanna save the environment now, with my new UhbEr
technique.

Basically, the idea is to get access to the VAX/VMS database or the controlling
computer itself. Now since this is on a internal LAN, and runs on DECnet
we have to find clever ideas to get in.

Some social engineering can help you a whole lot.
Phone your local municipality, or check out websites, newspapers or
anywhere, where specifically, the ATC is situated. Now you will get the contact
numbers of people who work there or such, maybe a fault reporting number.
Fire up your wardialer and start scanning the prefix. They should have
a server where they dialup to commission a new controller or when a new
software d/l is needed in the field. In South Africa this is a computer
running DOS with pc-anywhere on. But if they are clever, like all of the
centers I've seen, they would have a dial-back facility, if not, your in luck
cause then you are directly linked to the internal LAN, and should start
hacking the VAX or FEP. The FEP note, is normally a propriety system, like
in South Africa, runs on DOS with some major serial comms protocols. Better
the get access to the VAX/OS2 controlling computer for a more familiar
system, although the FEP has more control of controller system messages.
And you can access the serial connections to the modems directly.

If you are unlucky and have a clever ATC. You must devise another means of
access to the internal LAN. In my experience the LAN is always connected to
the local municipality WAN for mail purposes and for access to the local
intranet for database driven fault reporting. Now to gain access to the local
WAN is not that difficult, since they are usually very big and provide
gazillion services like websites, mail servers for municipal workers and such.
Now Hax0r a web server or something and backdoor it *VERY* *VERY* well. You
gonna need it a lot, maybe backdoor a couple. :)

Now on the local WAN, you can probably access the nameserver to the ATC LAN
or you can access it directly. I'm not providing a tutorial on hacking, just
means of access, so sniff email, network traffic blah blah... till you get
access to the VAX or controlling computer.

Now once your in, backdoor it *VERY* *VERY* *VERY* well ;)
you should use all the vax hiding tools and shit, look thru phrack for VAX/VMS
hacking. There are a couple of nice SHOW USER hiding tools and stuff 
written by mentor and a few others. And once you are in, check
what is on the DECnet, and maybe see if it is linked to other ATC's.
From here you can access the controlling computers, FEP's and everything.
Try to see the serial connections directly via FEP or see the communication
from the controlling computer, so you can figure out the format of messaging
controllers. Or if you are lucky, you can access the program itself 
used for messaging, if its terminal friendly.

Now find a controller that you have the location for, the addresses are
pretty easy to figure out most of the time or just browse through the
VAX database of fault reports or check the local intranet. Now construct
a suitable message and datagram from captured data, and make it do something
noticeable like:   UTC message - PX    DEMAND PEDESTRIAN STAGE
Hopefully, you have a laptop or something, go down to the controller
that you intend to send the message to. Now you will notice that all this is
done over tcp/ip, since you link to the LAN where you get onto the VAX/VMS
DECnet and in turn the controlling computer/FEP. So send through the command
and watch if the controller obeys you. If it does then you can start script
the whole procedure ;). make nice timings for ENVIROMENTLY friendly travels
between destination A and B. Also the commands to force a stage is nice to
have, UTC message - Fn  ; now if your stuck behind a red light, and just
sitting there polluting the air, just force to next stage in stream, and
off you go without the guilt of crossing a red light ;)

Also if you are browsing the LAN, look out for nifty info like, the source
to the firmware of controllers since the firmware gets updated quite often.
It might lay around on the dialup server or some internal ftp server.
The exact frequency and bit sequence used to initiate the emergency cycle
in the controllers, for ambulances and emergency vehicles is also nice. 
There is also the software that is used to commission the controllers 
and the hand unit for field monitoring.  

Of course hacking the traffic system can be abjo0zed and have disastrous 
effects, but i feel, if you have the skill to access a system like that, 
then you have the sense not to fsck it up.


|=[ EOF ]=---------------------------------------------------------------=|