Yes social engineering has its technology too. One of the most useful devices of the modern age is the telephone and it is the core tool of the Social Engineer. In the next few articles I'd like to Selective Call Interception. Its undoubtedly the most useful box for the social engineer as it gives you instant credibility.

In fact, it is SO useful that MI5 use the technique extensively (Albeit mostly at the exchange rather than the connection point)

Okay, I know you're itching for the juice so lets dive in:

NOTE: The first parts of the article are going to show the various modules, their purpose and how they generally fit together. There will be a number of ways to put these modules together and we will look at each. Don't be dismayed by the apparent lack of actual circuit diagrams - Those will come towards the end :)

SELECTIVE CALL INTERCEPTION

We begin with a scenario:

Lets put you in the place of a corporate spy. Your target is the rival office of your client and although its so easy to place a member of staff (employee positioning) it is costly and you cant get into management very easily. The best you have so far managed is to place a minimum-wage phone-monkey who, for the past week, has been answering phones and wants out pretty soon.

Your phone monkey (when not answering endless customer complaint calls) has found that there is an office laser printer which would be great to tap as it is used for the printing of client proposals, contracts, meeting notes, etc.

Now although you can tap an ethernet printer using a 802.11 wireless module (re-tuned illegally to be off-band) and use a similarly modded device attached to a parabolic or VAGI antenna to listen in to printer traffic at range, there are some problems.

Unfortunately, there’s no way she can open the printer, unscrew some panels, and start poking around in there with a screwdriver. You need to get an engineer on the inside without anyone getting suspicious, but how? Lets face it - if you just call the office and claim to be 'maintenance group' sending someone over for the printers annual check-up it just ain’t gonna fly.

Time to grease the wheels with a little hacker magic...

Your monkey takes her timetable and asks if she can print it... no problem. Takes a walk over to the printer and looks puzzled. Goes back to her PC... sends again, goes back to the printer and looks more puzzled!

Why? Because a little clear nail varnish works wonders at insulating the pins of an ethernet socket, that’s why... and so the printer isn't working. Now the IT Deptartment probably fix all the computers onsite but a laser printer is always an outside job ... Time to call an offsite maintenance contractor. If only we could intercept that call.

I mean, they are *never* going to be suspicious of an offsite worker that they called in themselves. They just issue a guest pass and show them where the problem is. So, with that as our goal lets take a look at how a professional corporate spy would leverage this to get their own 'technician' invited on-site.

NOTE: I really don't want to get into the usefulness of bugging printers, since that's not what this article is about... If you have a problem with this imagine that the printer usage is uninteresting. Instead, we're using a WiFi tap to give us a concealed node onto the sensitive LAN without negotiating the perimiter - the printer is just a convenient box to put it in. If you still have a problem with the whole concept, PM me, and I'll write up an article on miniature 802.11 modules and how we can build passive ethernet taps designed for rapid deployment.

Introducing...
SELECTIVE CALL INTERCEPTION

There’s a handy device called a 'Selective Intercept Box' (Somehow it missed being given a 'box colour'), which sits between the subscriber and the exchange and selectively diverts calls based on dialled number. It’s so damned useful at creating credibility in any given situation that I'm quite frankly surprised very little has been written about it. Essentially they work by monitoring line activity (incoming, outgoing or both) until a call condition arises which needs to be intercepted - It then removes the physical connection between the target and the exchange, and connects to call to a fake endpoint (or, alternatively, routes the call via the exchange to an endpoint other than the one dialled)

The simpler boxes allow digits through till the last digit is dialled. Then, if the dialled digits match the target number, they disconnect the user from the exchange... pick up the exchange side ... speed-dial the divert number ... and then reconnect the subscriber to the line to hear the ring. The boxes of this type I have seen generally use salvaged automotive relays for the switching but this is noisy... others switch via capacitors to soften any 'clicks' on the line. And some very early ones used use complex arrangements of CMOS counters and logic ICs rather than a dedicated microcontroller.

Whilst this works it is cheap and dirty and has a few problems...

Firstly it will cause a delay and a 2 second drop in background audio for the subscriber. It tends to click loudly on reconnect. It also causes the real number to ring for a brief moment which may be enough to have them call back (Although, it must be said that it normally wouldn't be enough to get CallerID which occurs between the first and second ring)

The more modern devices don't cause the line to lose power, are microcontroller based, can be programmed with multiple numbers to divert and can watch multiple outgoing lines. They are also completely transparent in operation.

All are homebrew.

THE DEVICE

General…

We’re going to build a device that sits between the subscriber and the exchange. It will prevent audio in either direction whilst allowing the DC voltage through to power the subscribers equipment. It will also allow the RING voltage through so that the subscribers equipment rings normally. This will free us from having to generate line voltages ourselves. When the subscriber lifts their handset they will draw power from the line and this will alert the exchange as normal. Essentially, everything works but the audio.

Since the audio cannot pass through our device the subscriber will hear no dialtone. Our device will therefore present a dialtone onto the subscribers side of the circuit whenever an off-hook condition is detected.

When the subscriber dials we will halt this dialtone – thus emulating the exchanges normal behaviour.

Outgoing calls…

The dialled digits from the subscriber cannot reach the exchange. However, our device will detect these digits and buffer them. Our device will keep checking the number against its own internal phonebook.

The phonebook is a list of numbers that we wish the device to divert.

If the device determines that a number is NOT in our phonebook it then begins to empty its buffer of dialled digits towards the exchange thus relaying the subscribers original intentions. During this time it continues to add any additional digits onto the end of this buffer. When the buffer is empty (Whether the number has been completely dialled or not) the exchange is assumed to be ‘synchronised’ with the subscriber – The device then bypasses the audio block on the line, and by doing so allows the remaining dialled digits to reach the exchange directly. This will be entirely transparent to the subscriber.

If we determine that a number IS in our phonebook (ie, the dialled digits match a complete entry in our devices phonebook) then we must take some form of action on this call. The action to take is also listed in the phonebook, and includes:

- Substitute the dialled number for another of our choice
- Connect the subscriber to our live operator via DECT

The device continues to monitor the line until the call is terminated. It then resets and returns to its waiting state. This may involve disabling the audio path between subscriber and exchange (If it were opened to let a normal call go through). The cycle will begin again should the line go off-hook.

Incoming calls…

Our device must detect when the line is ringing. This is important as our audio filter would also block the FSK Called-ID signals which are presented between rings. We therefore will allow audio for the duration of the ringing condition.

When a ringing condition stops it can be for one of two reasons: Either the calling party hung up or the subscriber answered. If the subscriber has answered we will need to continue holding the audio path open until the subscriber replaces their handset. If the calling party hung up we should disable the audio path and reset the device to its waiting state.

To simplify this, we enable audio when ringing is detected. The device then waits for the ringing to end, once ended we then wait for an on-hook condition before finally disabling the audio path. If the call is not answered there will be no time between the end of ringing and the on-hook condition and the audio path will close immediately. Otherwise, the device will wait for the duration of the call and then close the audio.

This will ensure that:

- CallerID functions correctly
- The subscriber can talk to inbound callers
- The audio path is always off when not required

This is the basic operation of our device.

All of the above will be achieved cheaply under microprocessor control. It will be designed to be modular and easy to maintain. We will provide circuit diagrams for most of the required modules.

The technology of Social Engineering (Part II)Background and modular overview

Okay, you’ve got the general theory. You know what an SCI/SCD box is and have some idea of what it needs to take care of. Now comes the technical theory... What, no ‘woohoo’ ? (Trust me, it does get better)

BACKGROUND

Its important to note that telephone audio is an AC waveform superimposed over an essentially DC power line. Normally the power line is at around 48v and the audio, created by varying the current drawn from the line, causes an AC audio waveform a few volts either side of the DC voltage. On a 48v line this voltage would drop when the hook is lifted (Current drain from phone) and the audio would appear as fluctuations in this lower voltage of a few volts either side.

When the phone rings it is caused by a RING signal from the exchange. This is a large AC wave superimposed on the existing DC causing a swing of as much as 100v peak-to-peak (ie, 50v either side of the 48vDC line power) at anywhere between 25 and 50hz (Cycles per second)

Luckily, unlike the older boxes, we don’t need lead-acid cells and transformers to simulate the exchange. That’s because we’re not going to sever the line, but instead use a filter to separate the subscriber from the exchange in terms of audio – but not in terms of power supply. We also do away with long chains of logic circuits counting each pulse-dialled digit and instead use specialised chips and our magic ingredient ... the PIC microcontroller (Which you’ll be familiar with from my last article)

As you can see, this isn't the most hospitable environment for low-voltage logic IC's - and is also a pain to simulate due to the voltages and waveforms used.

ISOLATING THE SUBSCRIBER

We need to know what number the customer is dialling *before* deciding whether to allow the call to complete. Unfortunately, we won't know the numbers being dialled until they ARE dialled - by which time the exchange is already putting the call through. Problem!

We need to be able to read the digits the subscriber dials WITHOUT passing them on to the exchange and completing the call. As stated earlier this could be done by simulating an exchange and providing the 48v DC from a car battery but this is wasteful. Instead, we allow the subscriber to connect to the exchange for DC line power but insert a 'filter' between the two which prevents audio passing in either direction.

Note that the filter will not block the ring signal from the exchange (25-50hz remember), so that’s another thing we don't have to simulate. It will however block voice and touchtone frequencies. Unfortunately it will also block the dialtone - so we need to provide that to the subscriber ourselves (Not a problem since we just mix two sines from a signal generator IC or even replay a short looping sample stored in a cheap SRAM memory) I will provide examples of this later.

In actual fact, filters are tricky and its often VERY difficult to get what you're looking for. After experimenting with various arrangements, stacking filters, and tweaking around - we eventually settled on a simple but aggressive capacitative 'smoothing' scheme that flattened all of the audio and also semi-clobbers the ring signal... we detect the high-peaks of the ring signal and disengage the smoothing circuitry whilst these are present (After all, you don't have to kill line-audio whilst the line is ringing) The result is superior to our previous filtering efforts. Since I doubt things have changed too greatly since the 80's I'd suggest this approach.

Whether you manage to filter small audio AC >200hz without clobbering the high-voltage RING signal at 100hz -or- whether you smooth out all the variance in the line, and switch-out this smoothing for the duration of the High-Voltage swings of the RING signal ... you still have a switchable 'filter' module with roughly the following properties

We test this by making sure telephones RING and ANSWER correctly, but no audio can be heard on the line in either direction, however hard either party yells. If you got that, you're good to go.

GYRATOR AND AUDIO BRIDGE

We now form an 'audio bridge' around this filter. Reading digits off the subscribers side and reinjecting them onto the line at the exchange side of the filter.

We can do this the old fashioned way using an large inductor, but that’s bulky and relatively expensive. A modern alternative is to use a Gyrator circuit. A gyrator allows the flow of DC and impedes AC signal. Whilst this appears to be the inverse of what we want it does mean that the small AC signals cannot be dissipated by the gyrator circuit and can instead be capacitively coupled to our audio circuitry.

Note that a gyrator works in both directions. It can strip the AC signal (audio) from the DC loop - or Inject our own AC signal onto the DC loop. We use both functions here:

And to allow audio to bypass the filter, we can either simply switch the smoothing filter off, or... crossover the audio IO of the two gyrators to form a bridge over the filter. The last approach is better as there is less chance of line clicks or any abrupt change in ambient line quality.

Our DTMF modules come in two flavours. A DTMF DETECTOR IC which will be our ‘ears’ and a DTMF GENERATOR IC which will be out microcontrollers ‘voice’

Again, I’ll give you circuit diagrams for all this later – but for now its important that we understand the modular relationships.

So. We must connect this DTMF detection/generation circuitry into our line interface where it will form a kind of Microcontroller-delayed DTMF bridge around the audio filter, allowing the PIC to read the dialled digits from one side and, if needed, play them (or a substituted number) upline to the exchange.

To do this we:

Couple the Encoders Audio Output to the Exchange-Facing-Gyrators AC input so that tones generated by the PIC are sent out to the exchange on the loop.

Couple the Decoders Audio Input to the Subscriber-Facing-Gyrators AC output so that tones generated by the subscribers equipment are fed into the decoder for detection.

Our microcontroller can now hear digits pressed by the subscriber, and pass them to the exchange (bypassing our filter which prevents the subscriber from sending DTMF to the exchange directly)

USER DIALTONE

Theres still one other tone that we need to generate besides sending DTMF to the exchange. We need to present a dialtone to the subscriber as our filter prevents them from hearing the natural one. We could get the microcontroller to generate this tone but it is wasteful on processor cycles. Instead, we create a dialtone generator which simply mixes two sine waves to produce the familiar dialing tone. We then can enable or inhibit dialtone presentation by turning this generator on or off under microcontroller control using another microcontroller output.

Dialtone generation methods include :

- A single IC combining two signal generators... mixing the output from both sides of this chip gives an accurate dual-tone dialtone.

- A very cheap record/playback IC (As used in recording pens and digital dictaphones) sounds fantastic at higher bitrates (Normally the bitrate is low to allow longer durations, but our looping sample is a fraction of a second allowing much higher bitrates and better resolution)

- Produced by a seperate microcontroller with a sine-table, detecated to generating both the 'busy' and 'dialtone' signals simultaneously.

Note: If your busy signal is voice based (Rather than a tone based) then you will need the record/playback IC approach. I'm going to provide basic schematics for both methods. Lets look at the new functional diagram with dialtone generation in place.

Heres the layout showing where a dialtone generator fits in a simple 'one-target' interface. (Later we will show how multiple interfaces can be used to monitor multiple lines – and many of the modules, including the dialtone generator, will be shared by multiple interface modules)

When the Hook-Detect circuit trips (Because some equipment at the subscribers side has gone off-hook) it signals the microcontroller on an input pin. This pin is high for off-hook and low for on-hook.

Whenever the line is off-hook (Hook-Detect line goes high) the microcontroller raises the Dialtone-Enable line which causes a fake dial tone to be presented into the AC input of the subscriber-facing gyrator. We will turn off the dialtone generator (lower the Dialtone-Enable line) if a DTMF digit is received or the phone goes back on-hook.

Ring detection is required and can sit with either the exchange facing gyrator (in opposite fashion to our hook detector) or as a combined hook and ring detector, or even as part of the DTMF detection system.

Personally, I prefer the latter. This is possible because some DTMF Detector ICs also include ring detection circuitry. They contain the required rejection circuitry to ignore transient conditions on the line (such as 'tinkling') and thus give a clear, reliable, ring detection signal to our microcontroller. It also saves us from additional detection components and reduces cost.

Later I'll show different Ring-Detection schemes, but for now heres how it would look if we go with the integrated DTMF IC approach. Note that the input is now Ring/Tip from the line rather than Audio from the gyrator.

Okay, I've decided to kick off the schematics with one of the more interesting aspects of the device. That is, generating the Call Progress Signals that the subscriber expects. There are two main ways to do this and I will cover both.

DIGITAL TONE GENERATION

As discussed earlier, our device is required to produce (at the very least) a dialtone... and for flexibility or multiline capabilities, other tones and telco prompts such as the BUSY INDICATION, and RINGBACK (What you hear when the other side is ringing)

In order to do this we're going to need some circuitry in one of two classes:

- A tone generator, which mixes sine-waves to produce distinctive telco patterns for DTMF or SingleTone dial/busy indications as required.

- A digital playback module, for playing back samples of 'real' telco indications

Which you require will depend upon your country and the telco involved. If your country uses a 'voice' indication such as 'The party you have called is busy, please try again later' then you're going to have to use a digital playback module which will store the appropriate samples in its ROM. If you're fortunate enough not to have such prompts you can settle for using a signal-generator IC to produce the various sinusoidal waveforms needed (You can mix two waves if your dialtone is DTMF)

If you are not sure which you will need, or you need a unit that will be able to cope in any country or under a variety of telcos, you should choose the digital-playback option. However, I will show both units here:

METHOD 1The sinewave generator

For this method you're going to need a 'Signal Generator IC' ... These come in many shapes and sizes and require varying amounts of external components to get the job done. All produce your choice of SQUARE, TRIANGULAR and SINE outputs, but we are only interested in SINE outputs for this application.

For this example I'm going to use a common 8038PCD chip. You really don't need anything fancier as we're not aiming for perfection. The 8038 comes in a 14 pin package.

There will either be a dimple in one corner of the chip, indicating the position of pin-1, or a U shaped depression indicating the 'top' of the chip ... the chip shown here is seen from above. Other packages may be available, you will need to check with the supplier if you are unsure of the pin arrangement and appropriate supply voltage for the package you order.

- The 100k Log Pot preset adjusts the frequency of the sine wave.
- The 1k Trim Pot provides a way to adjust the duty-cycle of the wave if needed.
- The 100k Variable resistor on pin12 corrects sine distortion.

There are better circuits, but this is cheap and easy : )

To create a Dual-Tone dialtone source (such as the US 350+440Hz standard dialtone), stack two modules like this...

Now that you have a signal source it is very easy to gate it on and off using the microcontroller. By gating such generators on and off in a specific pattern you can simulate broken-dialtone, backringing and busy signals.

You will need to look up the frequencies used by your telco as they vary from country to country (And even between different providers in the same country)

So, that’s it - Your Dialtone/Busy generator!

Another thing I should mention at this point is that on some systems, particularly those in more rural areas, the dialtone gets 'clobbered' by the length of the copper cabling... I've found that the dialtone can sound unrealistically 'clean' in these circumstances. Sometimes, detuning the 'distortion' pot slightly can actually improve the overall realism. Something to bear in mind if you're operating in an area with long runs of older copper.

Now, despite typing all this I don't actually use Tone Generation via Signal IC's - I prefer the flexibility of the next method... so lets rush ahead to Digital Sampling and Playback. Its pretty much essential if you're on a telco which uses voice messages in their busy indications.

METHOD 2Digitally sampled DIAL/BUSY indication

All the boxes I've built have used SRAMS (Static RAM) to hold looped samples of dialtone/busy messages which loop endlessly onto the appropriate BUSses of the matrix switch... I use a matrix switch even though I've never personally used the device to monitor more than two lines at once (However, the line-interfaces were much smaller because the signals and logic were on the base unit) The reason for this is, if needed, I could create more basic line interfaces and expand the system to 14 concurrent target lines or DECTS - But as a first I suggest sticking to a simple one-line, monolithic, device... you can always get creative later)

Whilst this all sounds complicated it needn't be so - You can equally well built this onto a single circuitboard with no need for a matrix switch and bus arrangement and even leave out the DECT capability... The basic 1-line system really is as simple as our first few schematics indicate.

Essentially you got a HUGE range of cheap record/playback ICs... In fact, the choice is quite daunting:
- some need power to retain their message, others don't
- Some allow you to change the sample rate, others don't
- Some allow only a few seconds, others as much as 8 mins
- Some require external memory, others have built-in storage
- Some can play back multiple messages, some can't
- Some can play back multiple messages at random, some can only play each in sequence

You can get away with any of them, but my best tip is go for something with internal storage to keep the parts count down... You idealy want as much storage as you can get on-chip, provided that you can increase the sample rate (If you double the sample rate, you get better audio, but half the duration) If you're only building a 1-line unit you won't need to generate dialtone AND busy at the same time, so a multiple-message chip can save you space and lower your chip count ... just make sure you can SELECT which message to play, sequential playback units are more trouble than they are worth.

My old chips needed to store around 30 seconds of looped audio, and I had an expensive 2 minute onboard memory. The quality was fair... I doubled the rate (The maximum for my chip) and the result was 60 seconds of storage of which I used half. It sounded much better. Today, the chips are cheaper, have better shaping and sampling abilities, larger memories, and a wider range of sample rates ... You have plenty of choice. Lets look at one of the main contenders:

The ISD4002 is a 3v device with superior anti-aliasing and smoothing. It uses on-chip flash memory which retains its data during power-off conditions. It has a very small footprint and requires few external components. It allows multiple messages. It is designed with the microcontroller in mind (Controlled via SPI or Microwire - So, as seen in my article on DataBugs, the CCS compiler already has the drivers for talking to it, which makes integration quite easy), it allows message playback from any position in a sound-file till the first EOF marker. It has an internal clock, so that saves us some parts.

Don't be fooled by the 28pin package - only 17 pins are actually connected and others are redundant. The pins can be broken down into functional groups, as follows:

Chip communication
SS (1)
MOSI (2)
MISO (3)
SCLK (28)

Audio IO
AUD_OUT (13)
ANA_IN+ (15)
ANA_IN- (16)

Power
VssA (11, 12, 18 and 23)
VssD (4 and 27)

Talking to the ISD4002

Talking to the 4002 is easy. You can talk to it using SPI or MicroWire (And your CCS compiler handles this for you) There are two main communication lines, they are labelled MOSI and MISO, and a select line labelled SS.

The select line is used when talking to multiple devices over the MOSI/MISO lines. Consider the following example...

Each device 'slave' listens CPU 'Master' on the MOSI (Master OUT/Slave IN) line they reply using the MISO (Master IN/Slave OUT) line

Each bit transmitted on the MOSI/MISO line is synchronised using a Serial Clock (SCLK) which the Master provides (The driver included with the CCS compiler will handle this synchronisation for you)

Messages on the MOSI/MISO lines are not 'addressed' to anyone in particular, therefore we must 'select' a device... we do this with the SS (Slave Select) line. Each slave device has an SS line... When the line is LOW the device listens to MOSI and can talk on MISO. When the SS line is HIGH that device ignores MOSI and stays quiet on MISO.

Actually, the 'Slave Select' line should really be called 'Slave Inhibit' since the HIGH signal causes the slave to ignore whats happening on the MISO/MOSI bus. Only one slave should have the SS line 'LOW' at any given time.

Now, unless you are planning to actually use multiple devices (For example a multi-line interface, where you may need DIALTONE and BUSY signals at the same time for different telephone lines) then you don't need the CPU to 'tell' the device that it is selected ... you can just tie the devices SS pin to ground, and it will be permanently selected (always listening) - This saves you an IO pin on he CPU.

This is how we will configure the device for a single-line interface. Next we need to know what to 'send' on the MOSI line to make the device do what we want (Record, Play, Stop, Etc...)

The messages we send are 2 bytes (16 bits) long. They consist of 10 bits of 'address' (You can imagine 'address' as the 'position counter' on a tape recorder) .... this is followed by a ZERO ... then 5 bits of control data (Which indicate the operation we wish to perform)

The memory is configured as 1600 blocks of 600 bytes. You can only start playback or record from the start of a block. This reduces the range of address from 0-960000 to 0-1600. This would require 11 bits of address data, but we have only 10 bits. Well, we can only start record and playback from an EVEN numbered block (0, 2, 4 ... 1598, 1600) and this means the 11th bit is always ZERO. This accounts for the fixed ZERO between the 10 ADDRESS and 5 CONTROL bits.

Therefore, it is better to think of the address as a 10-bit entity from 0 to 799

When recording, the device overwrites everything from the current address onwards, until a STOP command is sent, or the device runs out of memory. If a STOP command is sent, the device places an EOM (or End Of Message) marker at that point.

When performing Playback the device plays audio from the current address until a STOP message is received, an EOM is encountered (See Recording above) or the device reaches the end of memory.

When cueing mode is set, the device doesn't PLAY but rather SKIPS at 1600x speed to the first EOM (End Of Message) marker it finds.
Message Cuing only works for 'playback' operations.

When IAB is set, the device ignores the Address bits and uses whichever address it is currently at. Thus STOP and PLAY become PAUSE and UNPAUSE ... The position is unaltered.

AAAAAAAA AA 0 00111 Play from supplied address
-------- -- 0 01111 Play from current position
(Same as above, but with IAB set)

AAAAAAAA AA 0 00101 Rec from supplied address
-------- -- 0 01101 Rec from current position
(Same as above, but with IAB set)

-------- -- 0 011-0 STOP the current operation

AAAAAAAA AA 0 10111 Skip from supplied address to EOM
-------- -- 0 11111 Skip from current position to EOM

Thus, if we record 60 seconds of DIALTONE with ...

00000000 00000101 (Recorded from position 0)

And then 60 seconds of BUSY with ...

01100011 11000101 (Recorded from position 399)

We will have partitioned our 120 second chip with two samples. Playable using...

00000000 00000111 Play Dialtone
01100011 11000111 Play Busy tone

Since we are specifying the address we don't need to worry about cueing.

The chip doesn't allow us to 'loop' the audio... so we must keep sending the 'play' command at appropriate intervals in order to get a smooth dialtone. However, we will probably find that we rarely are required to play any single tone for more than 60 seconds anyway.

Note that if our telco has a BUSY message which is 'dynamic' ... IE, it says 'The number you have called... 555..1234...is busy, please try again later' we can divide the memory up into smaller chunks, as follows.

Your PIC can then generate the correct message based on the numbers provided by the DTMF Decoder when the user dialed. However, again, this is normally not required for a single-line outgoing-only call interceptor - In fact, your first box will probably need nothing more than a dialtone sample.

Okay, But how do you know when a sample is ended ?

Well the chip sends an interrupt using pin25. If you need this, pull pin25 high using a pullup resistor. The pin will go LOW when an EOM or memory overflow condition occurs - thus indicating your message has stopped. Want to watch the message ticking along instead ? The RAC (Row Address Clock) on pin24 goes up and down with each memory row, giving you a handy progress indication if you need it.

And, you can always get information back on the MISO line. For example, if you get an interrupt on pin25 you can send a special message with control-bits 011x0 and the device will signal its status, including whether an EOM (End Of Message) or OVF (A memory OVerFlow) caused the interrupt. Although, in this application I don't think you're going to need it.

An alternative to all this is just to get the processor to count time, retriggering the sample after a preset interval. The PIC operates fast enough that you can get very precise loops by simply retriggering the sample ‘blindly’ after n processor cycles.

To save my poor fingers, the format of messages on the MISO bus (Information FROM the slave playback chip TO the CPU) is described in the application notes for the chip if you need it. I don't think you will... If you don't think so either then remove the MISO connection between the chips and save yourself an extra IO line - there, multiple digital audio samples from a 2-wire interface... and the CCS compiler provides all the code - You just need to send two bytes and the chip will do the rest.

I'm sorry, but it doesn't get much easier than that : ) Its certainly easier than hacking apart an old MP3 player or dicta-pen. Even if you never build an SCI/SCD box – you might use the technique for something else... Like a PC ‘cold-start’ noise to accompany your BIOS screen.

How easy is that! When you combine the simplicity of the circuit design with the face that you only need to send 2 bytes to control the sound (And that the drivers for sending and synchronising those commands are built into the compiler) then you actually see that the perceived complexities of using this IC really are superficial. Just call the driver with the 2 byte command : )

(You may also want to place two 0.22uF caps. One between pins 18/23 and one between pins 4/27)

Thats not quite the full story though ... You're also going to need to connect a MIC for recording your samples. Theres two methods provided.

And thats it. Connect your MIC and LINE, Select the SPI or Mircrowire driver in the CCS compiler ... And send 2 bytes using C. Experiment with Record, Playback and Looping - and then you can integrate the complete module into your line device.

We will break down the other modules in the next few articles. Soon you should have everything you need to start putting together your own SCI/SCD box.

-Meds

Last edited by M3DU54 on Sun Nov 27, 2005 10:18 pm; edited 1 time in total

The technology of Social Engineering (Part IV)DTMF Encoder/Decoder modules

The whole concept of Selective Call Interception/Diversion hinges around the ability to read DTMF from the subscriber and later relay them to the exchange. Our PIC microcontroller must, therefore, have the ability to receive and transmit DTMF. Whilst this is possible to do in code it presents huge timing problems for the microcontroller which would need to be high-end in order to simultaneously analyse and generate the sine waves. Even from a lookup table we would require 100% duty cycle to manage.

We simplify things considerably by moving the DTMF signalling capabilities away from the microcontroller and into cheap purpose-built IC’s which then free the processor up for other tasks and greatly simplify our code.

So, lets take a look at the DTMF modules

DTMF HANDLING – The basics

Audio bearing the dialled DTMF (stripped from the subscribers side of the filter by our gyrator) is fed into a cheap DTMF Decoder IC. This provides a Binary Coded Decimal output of the 16 possible DTMF tones on four latched outputs and then sets a fifth output (valid tone detected) high.

_________________
| | DTMF Encoder allows us to set which of the
| DTMF Encoder IC | 16 tones we require by applying power to its
|_________________| four data pins
A A A A A
| | | | | In this case the binary 0010 (2 in decimal)
0 0 1 0

_________________
| | When we have done this we can apply a signal
DTMF <-/\/\,| DTMF Encoder IC | to a 5th pin, and it will generate that tone
2 |_________________| for as long as we wish, until we stop applying
A A A A A a signal on that 5th pin.
| | | | |
0 0 1 0 1

So, we connect these five pins to our microcontrollers outputs. This will be our microcontrollers 'voice'

The KT3170/Mitec MT8870 IC range...

There are so many equivalent ICs that it would be impossible to list all of them here. Which you use is going to depend on local availability. However, here’s a sample circuit based on the KT3170 (or MT8870) detector IC.

The chip comes in MT8870-01 and MT8870-02 versions, the pinouts for each are different so you MUST check the datasheets. With the –02 version you might like to additionally take pin5 high to enable detection of ‘ABC & D’ tones.

Note pins 1-4 of this IC (seen in the circuit diagram above) interface it to either the audio (from the Gyrator) or to the line (directly) – There are a few possibilities available, again, these diagrams show the –02 version:

Regardless of how you connect the DTMF device (Direct to line or Single-ended/Differential from Gyrator) you will note that when a DTMF digit is pressed the device presents the binary representation as HIGH/LOW states on pins D0-D3

The processor monitors the STATE line. When the state pin (Pin 15) goes HIGH this indicates that a valid DTMF tone has been detected and that the digits are available for reading from the 4 data lines.
Most decoders have a matching encoder or generator. The operation will be exactly the same but in reverse. Set lines D0-D3 to a binary representation of the tone you require, and then pulse the fifth line to generate the tone.

And once again, the datasheet and application notes for the IC will give you anything else you need to know, such as timing diagrams, which do vary from chip to chip.

Crystals and timers and chips... oh my

Talking about two similar ICs that reminds me... You will probably find that both your Encoder and Decoder will require the same crystal oscillator. You can use one crystal for both by chaining across devices. Check the diagram below:

This allows you to use one timing bus for all of your devices which require similar crystals... neat and cheap : )

Alternatives

I actually use a different method on my boxes. Essentially, my DTMF decoder also handles FSK (For decoding the inbound callerID) and my DTMF encoder also generates FSK... And despite this extra functionality they use only 2 IO pins of the pic instead of 5. This allows my device to selectively divert incoming as well as outgoing calls for greater flexibility. It also allows the modification of CallerID from specific numbers (In order to masquerade)

The same IC, which was designed with CallerID in mind, also presents a microcontroller compatible RING notification thus negating the need for additional RING DETECT circuitry. This proves quite handy.

Since it is not necessary for a basic SCI/SCD this method will be presented later in advanced modifications

So, what have we got so far ?

Well, we’ve got three PIC interfaceable modules. A dialtone/Busy generator, A DTMF decoder module and a DTMF encoder module. That pretty much wraps up the signalling systems – Our PIC is ready to both speak and hear the basic CCITT5 dialling standards and also to present a Dialtone that would trick the most competent engineer.

We still need to get the audio signals out onto the line, and for that we need to look at one of the most important circuits in conventional telecoms... the Gyrator Circuit. So, I guess that’s up next.

The technology of Social Engineering (Part V)Building a Line Interface

The Gyration Module

No, our device ain’t gonna breakdance like a malfunctioning AIBO (Although, that would be pretty cool) In electronics a Gyrator is just a simple device to simulate the properties of a large expensive coil. Whilst not as exciting as a breakdancing AIBO it is nevertheless damn useful when it comes to telephone electronics and is largely responsible for the small size and low component count of modern telephone handsets compared to their contemporaries.

MODULATED GYRATOR

To be honest I was truly dreading typing up the notes for the gyrator circuitry till I remembered an article on modulated gyrators I read a few years ago when researching better ways to power a PIC from the telephone line without lifting the hook (It was for a ‘pen-register’ application, a device which records numbers of the incoming and outgoing calls from the line it is attached to)

Luckily the article is still there so, rather than make this tutorial any longer than it needs to be, I’ll post the link instead. It is essentially the same as the gyrators we use, although it also draws a very low-current 5v supply from the line. It also gives far more background information that I was going to present.

As well as a great treatment on gyrators, Kens article also shows some PIC based code for handling line control, and also his own method of generating tones using a ladder network and a PIC. Whilst these are useful, I’d suggest sticking with the DTMF encoders/decoders for this application due to the need to simultaneously listen and generate tones.

That gives me some space to discuss alternatives so, whilst a gyrator is undoubtedly the preferred method, I’m going to also show a much simpler audio line interface which is perfectly acceptable for this application.

The two back-to-back Zeners prevent flow in either direction (As you would expect from two diodes) however at 5.6v they open up and allow current to flow – This provides a short loop.

You can use this circuit as either an audio input or an audio output. It does not hold the line open and therefore does not need a hookswitch. The benefit of an audio interface which does not open the line is that it can listen constantly ... it will therefore pick up the FSK CallerID signals.

Where you require to both send AND receive audio I would suggest two such units as shown below.

By connecting the audio IN/OUT on the subscribers side, to the audio IN/OUT on the exchange side in a crossover configuration we would expect the two to be able to talk normally. This is the principle of the ‘Bridge’ which is a switchable module that sits between the two.

In actual fact the bridge is more than this, it is two small transistor amplifiers which sit between the two line interfaces, effectively bridging over the filter – The amplifiers take the weak signals received on one side, and amplify them into the send coil on the other side.

The two amplifier gain is carefully tuned so that they don’t cause a feedback loop between the four coils (The loss in the coils helps damps this as long as we don’t over amplify the signal) – We tune the amps so that in normal operation the audio is clear but no louder than with the entire unit disconnected... if you find an echo then the amplifier gain is too high.

The microcontroller can turn these amplifiers on and off, this effectively controls the audio signal path between subscriber and exchange. If this bridge is turned on the subscribers dialled digits will reach the exchange and be acted upon. When we turn the bridge off there is no path around the filter and so neither side can hear the other.

This is how the PIC controls the audio path and dialtone presentation, received DTMF digits and later transmits them to the exchange.

Note that we should NEVER have the bridge open when we’re transmitting DTMF to the exchange as this will be heard by the subscriber. The bridge is ALWAYS closed unless we actually let a call go through.

It seems like a lot of work just to monitor a single line doesn't it ? Well, there are occassions when you need to monitor a company with multiple outgoing lines and this is why I deliberately took a very modular approach to the subject.

Next article will give an operational walkthrough of the phonebook handling. I'll try to make that fun : )

If the customer dials 0 and then 1 ‘01’ there is a partial match with one of the phonebook entries and so we are still not sure if this call will be interesting or not.

The customer then dials a 2... ‘012’ – This does not even partially match a number in the phonebook and is therefore ‘uninteresting’... so we’re going to allow it:

We start emptying the buffer by speed-dialling the exchange – first a 0, then a 1, and then a 2. Whilst we do this the subscriber has dialled another ‘1’ and so this gets added to the buffer and, in turn, emptied to the exchange.

Now the customer has dialled ‘0121’ and the exchange has received ‘0121’ so they are said to be ‘synchronised’ ... We now enable the audio bridge and ignore any further DTMF from the subscriber.

Unaware of this, the subscriber finishes dialling ... ‘444222’ – The exchange receives these last six digits directly from the customer and the call goes through. Because the audio-bridge is open the customer hears the ‘backringing’ and when the remote side answers she will hear them answer.

When the subscribers phone goes back on-hook the PIC will disable the audio-bridge and reset ready for the next call.

An interesting call...

Now the phone goes off-hook again. Again, the fake dialtone is presented but this time the subscriber dials an ‘interesting’ number. The dialled number is ‘4424442’

Since the number exists in the phonebook the audio-path stays disabled for the entire duration of dialling.

When the last digit is dialled, the ‘dialled digit’ buffer reads ‘4424442’ and this is a complete match. The PIC reads the next field in the phonebook which is a ‘D’ meaning we will Divert this call. We therefore delete the ‘dialled digits’ buffer (4424442) and replace it with the last field (5551234) and then continue as if the call was uninteresting

The PIC then resumes ‘uninteresting’ processing. It empties the ‘dialled digit’ buffer quickly towards the exchange at around 6 digits per second. And, once done, since the buffer is empty ... it opens the audio path and waits till the call terminates.

The difference this time is that the number reached ‘5551234’ and the dialled number ‘4424442’ are different because we changed the buffer before emptying it to the exchange. A switch has been made. And provided the new number answers correctly the subscriber will never suspect that they are being tricked.

This time the number dialled is ‘01912223000’ and this results in a lookup as before. This time the action flag is an ‘I’ which indicates an Intercept.

If we have a DECT telephone base attached to the device this will be connected to the customers line (As a parallel extension) – The audio bridge will NOT be enabled because we are not dialling the exchange. The exchange will wait... and wait... and wait... and then start audibly complaining but the subscriber won’t hear any of that.

Cus shes been routed to Jim on DECT...

Meanwhile, in a Ford Galaxy not so far away ...

In a nearby van a DECT telephone is being powered from the vehicle battery. It’s DECT antenna is missing and instead a coaxial cable leads to an external antenna hidden behind the plastic rear bumper. Its headphone and microphone have been cut off and connected to both a noise-cancelling headset microphone and a PC soundcard. The computer has a soundboard of prepared audio files and a software DTMF decoder. A script automates the playback according to DTMF cues unless interrupted by the operator. Yep, its mobile call-steering, and all roads lead to Jim.

On the headset (where there was previously absolute silence) Jim now hear a ‘hiss’ and some background noise. Jim jumps. Hitting space causes the soundboard to introduce itself... First it sends two rings, then it plays a familiar menu.

The subscriber dials a number from the menu and the soundcards input catches it as a DTMF ‘2’ ... the soundboard then plays the next-level menu associated with the number ‘2’ – Technical Services.

The subscriber dials a ‘3’ and again, the soundboard changes and plays the audio ‘Please wait, you are in a queue for technical assistance’... followed by the usual cheesy musak

After composing himself and subjecting our subscriber to the ‘usual’ queuing time our operator cancels the soundboard, unmutes his mic, and says (as though the 300th time today) ‘Good morning, my name is Jim at technical services, may I take your customer or site code ?’

Jim listens, smiles and politely informs the subscriber that an engineer will be there in the afternoon although he cannot give an exact time.

The system worked, the recorded menus you sampled the day before fooled the target completely, and those 5 exploratory calls where you recorded the engineers greetings and questions really paid off. In a couple of hours you can send an engineer through the door

After Jim hangs up he will continue to monitor and intercept other calls to ‘SupaMegaPrinterServe Inc’ just in case there are any follow-ups – He will also stay in the vehicle monitoring whilst the ‘technician’ is in the building – just in case there are any verification calls from security.

The rear windows of the VAN face the telco SCP some 100ft away where the SCI/SCD box is currently sitting.

The moral ?

Never trust anyone, even if you asked 'em to come... then called their company and verified em 3 times...

And that, is how you walk right through site security with a handshake and a contractor pass. Soon, the printer will be found to have a simple fault and will resume working again after a little board change (It’s the same board - albeit, with a freshly soldered trailing lead from the underside of the socket) This connects to the small plastic-box the engineer has stuck to the inside of the case, and two miniature Insulation Piercing Probes connect the box into the blue and brown wires on the back of the power switch.

A quick test, printer is working, and the engineer leaves the building. At the same time, back in the van, the AP's LINK light starts flashing indicating a successful connection (Despite being detuned to WiFi channel –2, against FCC rules) … this AP will later be connected to a small VAGI or parabolic and not only will Joe&Co be sniffing printer documents, but they will also have a node on the sensitive LAN – ready for the next cheap workstation exploit (or even an old one), without having to negotiate the perimeter.

Considerations

‘D’ – Means you don’t have to park-up near the connection point. It does mean that the redirect number will appear in an itemised phone bill. The redirect number should therefore be disposable, like crossing wires at a connection point to temporarily steal a payphone number.

Of course, you'll still need someone with a mobile phone staying in view of the connection point for the duration of the attack, if only in case you have the worst of luck and a telco engineer turns up and starts headscratching and making phonecalls.

‘I’ – Means there’s no trail at all, either within the device or in the itemised billing. But you will have to park-up somewhere. This isn’t such a hassle if you’re planning a site-intrusion anyway. Besides, you need someone in view of the connection point in case you need to call the 'technician' away on... umm... urgent business.

indeed a very good and detailed explained article , which though is partialy related to Social Engineering...
Social Engineering is all about human psychology and has nothing to do with phones , which are part of Phreaking section.
This of course is of no matter , considering the importance and the well done job for this article...

Social Engineering is all about human psychology and has nothing to do with phones , which are part of Phreaking section.

The relation here is that by manipulating the phone, the social engineer is capable of gaining a massive amount of credibility. The technology described here is a very important tool for the social engineer, as it aids tremendously in the job. For one thing, with this sort of technology, you instantly defeat callback verification mechanisms - and can even stage an attack where the victim itself is the one taking the initiative (e.g. posing as a service you know the victim will call to, etc).

The article doesn't say SE is all about technology, it is just presenting a very useful set of techniques which can be a tremendous aid for the SE.

Social Engineering is all about human psychology and has nothing to do with phones , which are part of Phreaking section.

The relation here is that by manipulating the phone, the social engineer is capable of gaining a massive amount of credibility.

Indeed. And, playing upon human psychology is not without its 'props' ... For example, in theraputic psychology the soft tones of furnishings, the clothing and even the choice between contact lenses and glasses must be considered.

In manipulative psychology the same is true... I am not a convincing electrician without a toolbelt and a particular manner of speaking... I don't work for a building company unless I have a hardhat... etc.

Props ARE important. Some are visible and others are audible such as a soundboard. When pretending to be calling from another office I usually have telephones ringing in the background for example. Things like this are common sense.

Then there are your interractives. Things like telephones and 2-way radios do more than just ice the cake. They position you in a complex fabricated reality created just for the listener. They extend your story from a 1-on-1 narrative to an interractive reality, and that is powerful stuff. This is where you move from opportunistic 'narrow' social engineering to a more robust form as is required when performing work to order.

In any event, the overriding concerns to the social engineer are plausibility and maintainability. Which is a more plausible manner of entry to a companies premises? Some story about how the photocopier needs its annual service -or- having them call me and request my presence. The former is open to doubt and discredit regardless of how well I act the part... whereas the latter establishes my credibility from the outset. Thats kinda important, particularly if you plan on doing a walk-in or black-bagging the place.

Yes, one could argue that this is a phreaking device but nothing in InfoSec is easily compartmentalised anymore.

indeed a very good and detailed explained article , which though is partialy related to Social Engineering...
Social Engineering is all about human psychology and has nothing to do with phones , which are part of Phreaking section.
This of course is of no matter , considering the importance and the well done job for this article...

Well done

Gandalf

Yes, i agree. Last parts was from Prehaking (hacking phones) and not from social engineering. SE is about psychlogy and human hacking (of course usually hacking by phone). I agree the SE must have some background: telephone number looks knowing number, mabye bypass telephone too. But SE is NOT only about bypassing phones.
It is about psychology...-> i think moust SE was in War2 as
spy agents.

security does not stop or start with the technology alone. The simple reality of the world in which we live is that it is/will be us humans who will be more or less be using, control, operate, regulate, maintain, modify, repair or add the functionalities of the technology base and capabilities.