From: Brass, Phil (ISS Atlanta) (PBrass@iss.net)
Date: Sat Jun 29 2002 - 16:08:53 EDT
OK, I hate to talk about things I don't know much about, but here goes.
First of all, my understanding of information theory is that if you want to
do reasonable, unaliased sampling, you should sample at twice the maximum
frequency of the source signal. While the whole notion of "frequency" is
probably not quite right for 56k modems with all their weird tricks, I would
still hesitate to believe that you could sample a 56k audio stream with a
44k capture device. Of course, the question is, what is the actual
frequency of the 56k stream? 56k = 56 kilobits per second, whereas 44k = 44
kilohertz sampling rate, so they are not quite the same. In fact, if I'm
not mistaken, the sound card can sample 44khz 8bits per sample 2 channels,
typically, so it actually does roughly 700kbits per second sampling.
However, all these extra bits won't help you reconstruct the stream if the
carrier frequency or whatever of the data stream is faster than 44khz. Even
if the information content is less, if you are sampling too slowly, no
matter how precisely, you will not be able to reconstruct the stream.
Secondly, the FBI has got "data tap" (modem-deciphering) devices, starting
in 1995: http://www.nctp.org/docs/nwsltr9912/9912p02.html.
Perhaps you could get in touch with agent Michael Morris and find out how
his equipment works, or whom he bought it from?
Phil
> -----Original Message-----
> From: Evrim ULU [mailto:evrim@envy.com.tr]
> Sent: Saturday, June 29, 2002 3:27 AM
> To: Greg; pen-test
> Subject: Re: blind demodulation - sound card - lucent winmodem
>
>
> Greg wrote:
> > Well an older FSK 300 baud job, no problem at all. Do it
> with just a sound
> > card and a poor gain tap. But modern 56k QAM with all the
> jiggery-pokerey,
> > no doubt possible but not very practical for those without
> unaccountable
> > public funding.
> >
> Heh:-) I obviously do not have funding like $70K. The machine
> that does this job
> was $70K or something.
>
> > Now demodulating the RFI from the serial
> cable/controller/modem interface,
> > if you're close enough would be a lot easier.
> >
> > sorry
>
> The limit on a normal phone line is 64K. But when there is
> noise on the line
> (this is the usual case in fact) one bit is dropped and
> result is simply 56K
> (53.3K says modem-howto of linux).
>
> But i'm insisting on this.heh:-)
>
> PCM says that there are 256(8 bits) different signals at a
> sampling rate of 8000
> per second. 56K Modems uses amplitude modulation. Although
> modems do lots of
> tricks like crc checking/data compression, there must be a
> way to demodulate the
> traffic since it's a simple analog one. One can setup a test
> line & two test
> modems which are not doing any compression for simple
> analysis. I'm not very
> experienced with ADC's (only used adc0832/04/08 etc. before)
> but using an opamp
> or so, max 48Volts can be scaled to 5V range and using a fast
> adc, one can
> distinguish these signals. Then using the software and cpu
> power, i don't think
> it will be a hard job to demodulate the traffic. In fact, i
> can employ a cluster
> system for this since here i've lots of dual linux machines
> waiting to run mpich.
>
> In addition to these, adc's of sound cards can be used since
> their sampling rate
> is enough. (44khz or so) (btw, i don't know if a 64 bit sound
> blaster really
> have a 64bit adc, somebody said they work differently than
> normal adc's)
>
> My final thought about these theories and assumptions: Why
> one uses adc or
> external devices? I know that there are soft modems that do
> not know anything
> about crcs/compression. They are just adc circuits made
> specially for this
> purpose. I think one may alter the kernel driver of lucent
> modem to gather
> digital data of the analog line , then decrunch it to a
> certain level. Finally
> of course, this data must be fed to pppd (modified) then dump
> the traffic using
> tcpdump or so:-)
>
>
> Ehe,warning: this message was full dreaming:-) But i'm going
> to continue to look
> for alternative solutions. Any suggestions?
>
> Thnx.
> --
> Evrim ULU
> evrim@envy.com.tr / evrim@core.gen.tr
> sysadm
> http://www.core.gen.tr
>
>
> --------------------------------------------------------------
> --------------
> This list is provided by the SecurityFocus Security
> Intelligence Alert (SIA)
> Service. For more information on SecurityFocus' SIA service which
> automatically alerts you to the latest security
> vulnerabilities please see:
> https://alerts.securityfocus.com/
>
----------------------------------------------------------------------------
This list is provided by the SecurityFocus Security Intelligence Alert (SIA)
Service. For more information on SecurityFocus' SIA service which
automatically alerts you to the latest security vulnerabilities please see:
https://alerts.securityfocus.com/
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:53:22 EDT