War Dialing Part 3: Modem Interaction

By Chris Patten ·

This is a continuation of our War Dialing series. Read Part 1 and Part 2.

Preparing for Modem Interaction

At this point, and likely sooner, we need to get our lab environment set up with all the necessary dialing gear. In previous sections, we identified techniques to determine tone detection, but now the task is more involved and manual as we need to interact with the target modems. In order to do this, I am going to provide a moderately inexpensive list of gear, along with the necessary steps to build out our environment. The following list of gear will be used:

  • A VoIP analog telephone adapter (ATA)
  • A carrier grade modem
  • USB to Serial DB25 cable


The VoIP ATA is used to convert from analog to digital signaling and back again. This is necessary in order to transition from a sinusoidal to a digital block waveform pattern representative of analog and Ethernet, respectively. The VoIP ATA must have at least one Foreign Exchange Station (FXS) jack and one Ethernet jack. The FXS is simply a specific telephony jack intended to accept an analog device such as a modem or fax. Additionally, the ATA must be capable of supporting the Session Initiation Protocol (SIP) used for establishment and teardown of the telephone calls. The ATA I have chosen is the Cisco WRP400 because it provides all the necessary features. However, others should work as well, while being a bit less expensive.

A couple of protocol details need to be explained prior to getting started with the ATA configuration. First, as mentioned previously, the unencrypted SIP (i.e., TCP/5060) protocol is used to perform call establishment and teardown, which has no effect on the audio stream. As a result, the protocol required to marshal the audio stream is handled by the appropriately named Real-Time Protocol (RTP).

The unencrypted RTP protocol is a connectionless UDP communication that is intended to transmit voice packets in real time. The UDP protocol is essential because unlike TCP, it does not attempt to perform error correction, flow control and packet retransmission. Therefore, packet loss can result in degraded voice quality or clipping (e.g., voids within a voice conversation). Alternatively, if TCP were used to marshal voice communication, packets might be retransmitted upon error or arrive out of order. The audio would then be placed within the order it was received, and that would make for interesting conversation.

Alright, so with that behind us, we need to transition into the actual configuration of the WRP400 ATA. The following screenshot is the default Linksys/Cisco operating system - sorry no DD-WRT supported firmware on this model - and illustrates the SIP/RTP configuration tab, et al.

Figure 1: The RTP codec configuration

The most important item when setting up the RTP communication is to select an uncompressed codec. Typical VoIP implementations use compressed codecs to transmit audio; however, this appears to be too “lossy” for modem signal survivability. Therefore, the use of the G711u uncompressed codec preserves the analog signal as it is transmitted via the RTP protocol.

Next, we need to make sure that the outbound dialing is setup so we forward traffic to our SIP trunk provider, in this case it is Vitelity.

Figure 2: Subscriber and outbound proxy configuration

On the WRP400 there was one additional audio configuration requesting the specific codec. Again, we must use the G711u uncompressed codec. This is likely an unnecessary configuration on other ATA devices but is required for the WRP400.

Figure 3: The preferred codec configuration

Now we move on to selecting the modem required to dial all of our target modems.

Carrier Grade Modem

The most versatile modem that I have personally found for performing war dialing and to manually interact with is the US Robotics V.Everything 33.6/28.8 device. I have provided a photo from my lab that illustrates the larger footprint typically associated with traditional carrier grade modems, and why yes that is a Samsung Galaxy Nexus and Droid OG phone stacked next to the modem.

Figure 4: The US Robotics V.Everything modem

Specifically, it is a solid device that supports the standard HAYES command set necessary to initiate dialing and establish sessions. How do we use the command set you ask? This is a question that will get explained in the next section.

Finally, Assembling Our Lab

Again, I have taken a photo of my lab to illustrate how each piece integrates together. I have also labeled each integration point in order to clearly articulate how each component is attached to one another. Note that the “Ethernet In” was excluded from the following photo as it will be connected to a router with outbound Internet access.

Figure 5: A standard lab setup interconnecting the router, ATA, modem and laptop

Interacting with a Modem

Finally, we are to the point of being able to manually interact with the modems that we identified during the prior Mass Dialing and Tone Detection phase. To get started, I am using a virtual machine running an Ubuntu Linux distribution. Furthermore, the versatile “Minicom” tool can be used to communicate directly with the modem via “/dev/ttyUSB0”.

Minicom is available within the APT repository and can be installed by simply typing “apt-get install minicom” from within a terminal, such as bash. Make sure that the modem is attached per the lab assembly instructions and that it is powered on. Type ‘minicom –s’ from within a terminal to enter the initial configuration screen. It should look similar to the following screenshot.

Figure 6: Initial Minicom setup

Note that if you are unsure of the location associated with line “A – Serial Device” the following should help obtain the necessary information. As the last line illustrates, the modem device is at ttyUSB0.

Figure 7: Determining the modem device location

Getting back to the Minicom configuration menu, next we want to make sure the initialization sequence is correct by selecting the “modem and dialing setup” option. The screen and configuration should look similar to the following:

Figure 8: The modem Init string located on line "A - Init string"

Figure 9: Save default configuration

At this point we should be able to choose the “exit” option, which will drop us into the actual modem terminal. A screen should appear momentarily stating “Initializing modem” and then look similar to the following screenshot. I have also dialed a “18135555555” number and my mobile “18134806505” in order to depict the level of verbosity provided during a busy and ringing state, respectively. The “NO CARRIER” is introduced when the call is dropped either intentionally or unintentionally.

Figure 10: Dialing via Minicom and the lab modem

There are a couple of items in this illustration that require further explanation. The AT, ATZ and ATDT are HAYES commands exclusively reserved for modem communication. The AT command explicitly tells the modem that commands are to follow. Therefore, appending “Z” to “AT” creates “ATZ” and instructs the modem to perform a reset. Lastly, the “DT” appended to the “AT” making “ATDT” is essentially telling the modem to dial the phone number using touch tones.

There are a number of HAYES commands, and various modem manufacturers have expanded the set to include their own proprietary commands, but the ones that I just explained are universally leveraged to interact with modems.

Finally, and to finish the post off with a real world example, we will take a look at an actual SCADA system that I ran into on recent project. The information is innocuous and doesn’t disclose anything sensitive; therefore, we will use this as I had legal permission to access this device.

Figure 11: Access to a SCADA device upon modem connection

Many of the options that were presented upon connection have been excluded for brevity. However, notice that there are ping, file and dir commands just to name a few. This was in a client environment without any credentials protecting the device, so anyone could have dialed the number and obtained access to the internal network. This really brings it all back to where we initially started: the convergence of Internet and analog traffic. Both are critically important to protect, but the analog network often is considered legacy or simply goes unchecked due to the infrequent use of the technology. It is just as import to ensure that phone blocks are protected as it is network ranges. With all of this said, I hope this was an interesting series that helped you set up a testing lab and reinforced the fact that telephony and war dialing are not dead.