==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 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 ]=---------------------------------------------------------------=|