From: David Honig <honig@otc.net>
Date: Thu, 29 Jan 1998 03:21:33 +0800
To: Ray Arachelian <cypherpunks@toad.com
Subject: Re: Spyking snips: Police MDT's + cia/russian spying
In-Reply-To: <Pine.SUN.3.96.980128130055.27062A-100000@beast.brainlink.com>
Message-ID: <3.0.5.32.19980128110542.007f5a70@206.40.207.40>
MIME-Version: 1.0
Content-Type: text/plain



At 01:03 PM 1/28/98 -0500, Ray Arachelian wrote:
>2)From: "Brandon Robinson" <brobinson@navicom.com>
>Subject: Re: Monitoring MDT's 
>
>>14)From: "self destruct" <<slfdstrct@email.msn.com>
>>Subject: Monitoring MDT's
>>hi all,....i am wondering if there is a way to monitor police MDT's
>>(mobile display terminals)
>>i have the frq. that they use but i dont know how to hook up a scanner to
>>p/c. any thoughts would be appreciated thank you
>
>Since no one else seemed to respond to this, I guess I will...first off
>M.D.T. stands for (Mobile Data Terminals), I got this posting off some
>group I can't really remeber where from, but it is informative, and was
>the
>subject of a Feb, '97 "911Dispatcher Magazine" story. It should answer all
>of your questions, I also have a list of some places where you can buy the
>unit pre-made, or a kit to make your own. I have left the Source code out
>on purpose as it is rather lengthy, if you want it I can send it to you. 
>
>-BBR
>----------------------- Begin quoted article ----------------------
>
>>From lord@heaven.com Mon Dec 23 23:11:43 EST 1996
>Article: 44420 of alt.radio.scanner
>Subject: MDT stuff
>
>Greetings one and all,
>
>Have you ever lusted to decode Mobile Data Terminal (MDT)
>tranmissions? Have you ever wanted to see the same NCIC and motor
>vehicle information that law enforcement officers see? Have you ever
>wanted to see what officers send to each other over "private" channels?
>And all this with an interface you can build with only a few dollars
>worth of parts from your local radio shack?
>
>If so this posting might be your rendevous with destiny. The tail
>end of this posting includes the source code of a program that decodes
>and displays MDT messages. It stores roughly 30k of messages in a buffer
>and then writes the whole buffer to a file called "data.dat" before
>terminating. The program may be interrupted at any time by pressing any
>key (don't use control-c) at which point it writes the partially filled
>buffer to "data.dat". This program only works for systems built by
>Motorola using the MDC4800 tranmission protocol. This accounts for a
>large fraction of public service MDT systems as well other private
>systems.
>
>The existence of this program is ample evidence that Motorola has
>misrepresented its MDT systems when it marketed them as a secure means
>of communcications. The interested reader will soon discover that these
>systems do not use any form of encryption. Security concerns instead
>have been dealt with by using a code. "And what might this code be
>called?" asks the reader. The code turns out to be plain ASCII. What
>follows is a brief description of how the program and the MDC4800
>protocol work. If you don't understand something go to your local
>library and check out a telecommunications theory book.
>
>1. The raw transmission rate is 4800 baud. The program's interrupt
>service routine simply keeps track of the time between transitions. If
>you're receiving a perfect signal this will be some multiple of 1/4800
>seconds which would then give you how many bits were high or low. Since
>this is not the best of all possible worlds the program instead does the
>following: transitions are used to synchronize a bit clock. One only
>samples whenever this clock is in the middle of the bit to produce the
>raw data stream. This greatly reduces jitter effects.
>
>2. Whenever a tranmitter keys up the MDC4800 protocol calls for bit
>synchronization (a sequence of 1010101010101010....). In the program
>this will result in receive bit clock synchronization. There is no need
>to specifically look for the bit sync.
>
>3. Look for frame synchronization in raw bit stream so that data
>frames can be broken apart. Frame synchronization consists of a 40 bit
>sequence : 0000011100001001001010100100010001101111. If this sequence is
>detected (or 35 out of 40 bits match up in the program) the system is
>idling and the next 112 bit data block is ignored by the program. If the
>inverted frame sync is detected one immediately knows that 112 bit data
>blocks will follow.
>
>4. Receive the 112 bit data block and undo the bit interleave. This
>means that one must reorder the bits in the following sequence : {0,16,
>32,48,64,80,96,1,17,33,49,65,81,97,2,18,34,...} if the orignal sequence
>were received as {0,1,2,3,4,5,6,7,8,...}.
>
>5. Check the convolutional error correcting code and count the
>number of errors. The error correcting code is rate 1/2 which means we
>will be left with 56 data bytes. The encoder is constructed so that the
>output consists of the original data bits interspersed with error
>correcting code. The generating polynomial used is :
>1 + X^-1 + X^-5 + X^-6
>Whenever an error is detected a counter is incremented. An attempt is
>made to correct some errors by finding the syndrome and looking for the
>bogus bit.
>
>6. Keep receiving 112 bit data blocks until either a new frame sync
>is found or two consecutive data blocks have an unacceptably large
>number of errors.
>
>7. Each data block consists of six data bytes; the last 8 bits are
>status bits that are simply ignored. The program shows the data in two
>columns - hexadecimal and ASCII. This data is kept in a buffer and is
>written to the file "data.dat" when the program terminates.
>
>8. What the program doesn't do: As a further check on the data
>there can be CRC checks. This varies from protocol to protocol so this
>program does not implement the CRC checks. Nonetheless, it is a
>relatively trivial matter to find the generating polynomial. The
>addresses, block counts, and message ID numbers are also quite easy to
>deduce.
>
>As you can see, there is no encryption. The bit interleave and the error
>correcting coding are there solely to insure the integrity of the ASCII
>data. Since any moron could have figured this stuff out from scratch one
>could argue that MDTs do not use "...modulation parameters intentionally
>witheld from the public". Therefore the Electronic Communications
>Privacy Act may not prohibit receiving MDT tranmissions. However,
>consult your attorney to make sure.
>
>The total disregard for security will no doubt annoy countless
>Motorola customers who were assured that their MDT systems were secure.
>Since Federal law states that NCIC information must be encrypted your
>local law enforcement agency might be forced to spend millions of
>dollars to upgrade to a secure MDT system - much to the delight of
>Motorola and its stockholders. Cynics might conclude that the release of
>a program like this is timed to coincide with the market saturation of
>existing MDT systems.
>
>Also, this program is completely free and it had better stay that
>way. What's to prevent you from adapting this into a kit and selling it
>>from classified ads in the back of Nuts and Volts? Nothing. But take a
>look at Motorola's patents sometime. You'll notice that this program
>does things that are covered by a shitload of patents. So any attempt to
>take financial advantage of this situtation will result in utter misery.
>
>Please keep the following in mind: this program only works with the
>first serial port (COM1). If your mouse or modem is there too bad. If
>you don't like this rewrite the program.
>
>------------------------------------------------------------------------
>What equipment do I need?
>
>RADIO SCANNER:
>
>A scanner that can receive 850-869 MHz. For those of you who don't
>know, this is the band where most business and public service trunked
>radio systems can be found along with the mobile data terminal
>transmissions. Chances are excellent that if your local authorities have
>a motorola trunked radio system and mobile data terminals that this is
>the frequency band in use. Very rarely will one find mobile data
>terminals in other frequency bands.
>
>Now for the fun part - your scanner should probably be modified to
>allow you to tap off directly from the discriminator output. If you wait
>until the signal has gone through the radio's internal audio filtering
>the waveform will likely be too heavily distorted to be decoded. This is
>exactly the same problem that our friends who like to decode pager
>transmissions run into - some of them have claimed they can only decode
>512 baud pager messages using the earphone output of their scanner.
>These mobile data terminal messages are 4800 baud so I don't think you
>have a snowball's chance in hell without using the discriminator output.
>If you don't know where to begin modifying your scanner you might want
>to ask those who monitor pagers how to get the discriminator output for
>your particular radio.
>
>COMPUTER/SCANNER INTERFACE
>
>Those of you who have already built your interface for decoding
>pager messages should be able to use that interface without any further
>ado. For those starting from scratch - you might want to check out
>packages intended for pager decoding such as PD203 and the interfaces
>they describe. The following excerpt gives an example of a decoder that
>should work just fine (lifted out of the PD203 POCSAG pager decoder
>shareware documentation):
>
>>
>> 0.1 uF |\ +12v
>> ---||-----------------------|- \|
>> AF IN | |741 \
>> ---- | | /--------------------- Data Out
>> | \ ------|+ /| | CTS (pin 5/8)
>> | / 100K | |/-12v | or DSR (pin 6/6)
>> | \ | |
>> GND / ----/\/\/\---- GND ------ GND (pin 7/5)
>> | | 100K
>> | \ N.B. Pin Numbers for com port are
>> GND / given as x/y, where x is for a 25
>> \ 10K way, y for a 9 way.
>> /
>> |
>> GND
>>
>> The above circuit is a Schmitt Trigger, having thresholds of about +/-
>1v.
>> If such a large threshold is not required, eg for a discriminator
>output,
>> then the level of positive feedback may be reduced by either reducing
>the
>> value of the 10K resistor or by increasing the value of the 100K
>feedback
>> resistor.
>>
>> The +/- 12v for the op-amp can be derived from unused signals on the COM
>> port (gives more like +/- 10v but works fine !):-
>>
>>
>> TxD (2/3) --------------|<-------------------------------------- -12v
>> | |
>> RTS (4/7) --------------|<-------- GND - -
>> | | _ + 10uF
>> --------->|------- - - |
>> Diodes 1N4148 | - + 10uF GND
>> | |
>> DTR (20/4) ------------->|-------------------------------------- +12v
>>
>
>If I were building this circuit I would strongly suggest tying the
>non-inverting (+) input of the op-amp to ground since you are working
>directly with the discriminator output and don't need a Schmitt trigger.
>All these parts or equivalents are easily available (even at your local
>Radio Shack which stocks the finest collection of components that have
>failed the manufacturer's quality control checks and supported by a
>sales staff that's always got the wrong answers to your questions).
>
>Also: DO NOT use the RI (ring indicator) as an input to the computer.
>-------------------------------------------------------------------------
>
>How do I check things?
>
>As a first step, I would get a package such as PD203 and use it to
>decode a few pages. If you can get that working you know that that your
>interface circuit is functioning correctly.
>
>If you are in a reasonably sized town you might be part of the
>ardis network. The ardis network is a nationwide commercial mobile data
>terminal network where one can send/receive E-mail messages from one's
>portable computer. It has been exclusively assigned the frequency of
>855.8375 MHz. Therefore, if you can hear digital bursts on this
>frequency you are basically guarranteed that these are MDC4800 type
>messages. You should be able to get stuff popping up on your screen
>although a lot of the messages will not be plain english.
>
>If your interface works but you can't seem to get any messages on
>the screen for a channel you know is a Motorola MDT system then it might
>be possible that your scanner/interface is putting out data with the
>polarity reversed. To check for this run the program with a command line
>arguement. When it runs you should an initial "Polarity reversed"
>message and hopefully then things will work out for you.
>
>Other than that: if this program doesn't work pester someone else
>who has got it working. Don't bother pestering the author(s) of this
>posting; the shit(s) aka "she/he/it (s)" are afraid of a thousand
>lawyers from Motorola descending like fleas to infest their pubic hair
>and accordingly have decided to remain forever anonymous. No doubt
>someone on the usenet who sees this post will know what to do with this
>program and also hopefully rewrite into a more user friendly form. When
>you do please don't forget to release the source code.
>-------------------------------------------------------------------------
>Future projects/nightmares you might want to think about:
>
>Certain MDT systems embed formatting information in the text in the
>form of ESC plus [ plus a few more bytes. Someone might want to decode
>these on the fly and format the output so it looks exactly the same way
>as the user sees it.
>
>Make it so that this program works with com ports other than COM1.
>
>Make it user friendly?
>
>Enlarge the data buffer from the current 30k.
>
>Give the output data file an unique name each time the program is
>run instead of "data.dat".
>
>How about sorting through the past traffic so that you only see
>traffic to a specified user?
>
>The program does not cut data blocks off in the display but it
>might add an extra one or two (which will display as all zeroes).
>Someone might want to make all those zeroes be shown as blanks instead.
>
>Write some real instructions.
>
>Now the more ambitous stuff:
>
>Are you half-way competent with RF engineering? Then listen in to
>the tranmissions from the mobile units back to the base station. That
>way you get everyone's password and user IDs as they log on to the MDT
>system. By this point you will no doubt have been able to figure out all
>of the appropriate communications protocols so you should think about
>getting your own transmitter up and running along with the necessary
>program modifications so that you can transmit MDT messages. The
>required transmitter can be very simple - for example, those masocists
>who want to start from scratch might want to special order an
>appropriate crystal (pulling the frequency with the computer's tranmit
>signal), building a frequency multiplier chain, and adding a one watt RF
>amplifier to top it all off (see the appropriate ARRL publications for
>more information on radio techniques). Now you can log in and look at
>the criminal records and motor vehicle information on anybody you can
>think of. Find out what your neigbors are hiding. Find out who that
>asshole was that cut you off downtown. Find out where your former
>girl/boy friend is trying to hide from you. And on and on...
>Those with simpler tastes might want to simply transmit at the base
>station's frequency to any nearby MDT terminal - now you too can
>dispatch your local law enforcement agencies at the touch of your
>fingers!!! See your tax dollars at work tearing apart every seam of your
>neighbor's house. Or create strife and dissension in your local law
>enforcement agency as more and more officers come out of the closet
>using their MDTs trying to pick up fellow officers.
>
>There are municipalities that have put GPS receivers on all of
>their vehicles. Should it happen that the information is sent back over
>one of these networks you could have your computer give you a real-time
>map showing the position of every vehicle and how far away they are from
>you.
>
>Extend your knowledge to other data networks. Here you will want to
>look at the RAM mobile data network. It uses the MOBITEX protocol which
>is really easy to find information on. Since it is an 8 kilobaud GMSK
>signal there is a decent chance that you can use the interface described
>here. This transmission mode demmands much more from your equipment than
>MDT tranmissions. At the very least you must be much more careful to
>make sure you have adequate low frequency response. Despite this it is
>possible to receive and decode MOBITEX transmissions with a simple
>op-amp circuit! This just goes to show you what drivelling bullshit
>RAM's homepage is filled with - they explain in great detail how hackers
>will never be able to intercept user's radio tranmissions (incidentally
>explaining how to decode their tranmissions). The necessary program will
>be the proverbial exercise left for the reader. For better performance
>buy a dedicated MOBITEX modem chip and hook it up to your computer.
>
>----------------------------------------------------------------------
>
>A few words about the program:
>
>Remember - you must have your decoder hooked up to COM1. The RTS
>line will be positive and the DTR line negative but if you built the
>decoder with a bridge rectifier you really don't have to worry about
>their polarity. Stop the program by punching any key; don't use
>control-c or control-break!
>
>If you must reverse polarity run the program with any command line
>arguement (example: type in "mdt x" at the command line if your program
>is mdt.exe). You should then see the "Polarity Reversed." message pop up
>and hopefully things will then work.
>
>As far as compiling this - save the latter portion of this posting
>(the program listing) and feed it to a C compiler. Pretty much any C
>compiler from Borland should work. If you (Heaven Forbid) use a
>Microsoft C compiler you might need to rename some calls such as
>outport. Follow any special instructions for programs using their own
>interrupt service routines. This program is not object oriented. It also
>does not want anything whatsoever to do with Windows. Please don't even
>think about running this program under Windows. Finally, here it is:
>
>Good Luck and may God be with ya
>
>**************************************************************************
>
>Subject: More real spy stuff...
>
>Germany smuggled agent out of Russia
>
>Germany's Federal Intelligence Agency smuggled one of its Russian
>agents to safety while Russian President Boris Yeltsin and German
>Chancellor Helmut Kohl were meeting in Moscow last Nov., the weekly
>news magazine Focus said Monday. The BND had received a tip that a
>long-serving Russian agent was threatened and launched a cloak and
>dagger operation Nov. 29 to pull the agent out of Russia. The agent,
>a 32-year-old Army captain from the Russian town Samara with the code
>name "Coastal Fog," had given BND Russian military communications
>secrets for years. The rescue operation took place as Kohl and
>Yeltsin sat down for talks.
>
>Russian spies still fighting the Cold War in Britain
>
>Security sources say Moscow is as eager as ever to uncover
>defence secrets But now it is acting  more for economic than
>militaristic reasons. Security sources put Russian military
>espionage in Britain at the same level as it was in the 1980s.
>In a radio broadcast in December, President Yeltsin,
>speaking about Russia's intelligence aims, said:
>"Notwithstanding positive changes after the end of the
>Cold War, tough competition is still underway in the
>world. Competition for new technology and geo-political
>influence is increasing."
>
>Space Imagery Overhaul Aims at Better Data and Easier Access
>
>The shuttle flight is part of a massive modernization of the
>multibillion-dollar U.S. intelligence collection program. The goal
>is to compile a comprehensive view of the world from
>overhead -- using the shuttle, satellites, spy planes and missiles
>-- and to consolidate the data in a single computerized system
>accessible to civilian and military officials across the
>government.
>
>A CIA Target at Home in America
>By DANIEL C. TSANG
>Los Angeles Times January 18, 1998
>
>Because of me, the Central Intelligence Agency has had to concede it does 
>spy on Americans. Just last month, the agency had to remove a denial
>posted 
>on its Web site that it doesn't do this. For it kept a file on me
>throughout the 1980s and '90s--despite a law against political spying on
>Americans. 
>Just before Christmas, the CIA revised its Web site. The new version says 
>the CIA can keep files on Americans if they are suspected of espionage or
>international terrorism. But I am no spy or terrorist. The CIA conceded as 
>much by settling my lawsuit, paying my lawyers some $46,000 and promising
>to expunge my file and never spy on my political activities in the
>future.
>
>
>
>
------------------------------------------------------------
      David Honig                   Orbit Technology
     honig@otc.net                  Intaanetto Jigyoubu

``I'm going to the White House to get my presidential kneepads.''
ML Quote of the day      http://www.newsday.com/ap/rnmpwh0s.htm