Mirrors/Zines
1
0
Fork 0
mirror of https://github.com/fdiskyou/Zines.git synced 2025-03-09 00:00:00 +01:00
Code Issues Releases Wiki Activity
Zines/phrack/60/14.txt
Rui Reis a998d1b065 1st import into tree
2016-12-14 22:07:35 +00:00

479 lines
21 KiB
Text
Raw Permalink Blame History

==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 ]=---------------------------------------------------------------=|
Reference in a new issue View git blame Copy permalink