[guardian-dev] The sound of an encrypted audio stream

Tim Prepscius timprepscius at gmail.com
Wed Jul 24 18:11:33 EDT 2013


Shouldn't this be impossible?

I was under the impression that there is usually a pre-requisite
header packet and then the codecs do different magics to compress the
audio.  Some codecs, I believe, allow the compression scheme to change
depending on the audio properties they encounter.  Which I would
assume would also take some header information.

If the stream is encrypted this meta-data would be lost?
It would be like taking an encrypted gzip file and trying to gunzip it?



If it were a pure wav file, you could figure out sample rate, and dump
the data into an audio stream..


Are you dealing with the packets of a encrypted compressed audio stream?

It might be interesting to determine the "randomness" of data?
I would think, that if it is not random, there is a problem... ???



-tim


On 7/24/13, Lee Azzarello <lee at guardianproject.info> wrote:
> Hello,
>
> As a follow up, I made a bunch of audio and video calls between Jitsi
> on OS X and the same build of Linphone Android while running Wireshark
> on the OS X side. I have a few minutes of encrypted audio packets,
> which are marked as UDP packets and have ASCII headers at the
> beginning of the sequence indicating a ZRTP dialog. What follows looks
> like noise.
>
> While Wireshark has a plethora of tools for VoIP analysis and wiretap
> playback, none of them apply to encrypted packets of any kind.
> Following the endpoints of the ZRTP/SRTP streams is possible but
> here's the catch. The encrypted audio is transported with an unknown
> codec. Since calls through ostel.co have encrypted SIP packets and the
> client's codec agreement is passed during the SIP stage of a call,
> there is no way to determine the codec for the call by searching the
> SIP packets for keywords. The set of possible codec combinations is
> large, though I can see a brute force process to push bits into some
> function testing for truth on all known codecs. Expensive but
> possible.
>
> So, I want to try and reconstruct an encrypted audio stream from a
> packet capture and save that as a valid sound file. I can control the
> codecs and extract the raw packet data, but the reconstruction is
> something that I believe would require a custom utility. I don't know
> where to go from there. Halp?
>
> Thanks,
> Lee
>
> On Tue, Jul 23, 2013 at 11:01 PM, Travis Biehn <tbiehn at gmail.com> wrote:
>> Seriously cool Lee, I always wondered about this myself :) Thanks for
>> taking
>> the time to post this.
>>
>>
>> On Tue, Jul 23, 2013 at 5:36 PM, Lee Azzarello <lee at guardianproject.info>
>> wrote:
>>>
>>> I recorded the sound with a microphone. It was coming out of my
>>> Android device running a debug build of Linphone. I can describe the
>>> process to reproduce it.
>>>
>>> But now...for the TWIST!
>>>
>>> There was no human speech happening when I made this recording. No
>>> vowels, no consonants, no phrases. The only sound in the room was a
>>> fan...producing noise (though from the angle of my desk, unlikely
>>> white noise).
>>>
>>> There's a chance the sound was not what I thought. Perhaps it was a
>>> codec error, though it didn't sound like a looping buffer. I kept it
>>> on for over a minute. Wireshark has a bunch of VoIP protocol
>>> analyzers, including a utility that will try and recover an audio file
>>> from captured RTP packets. That'll be an interesting comparison.
>>>
>>> -lee
>>>
>>> On Tue, Jul 23, 2013 at 5:20 PM, Hans-Christoph Steiner
>>> <hans at guardianproject.info> wrote:
>>> >
>>> > I could also see adaptive audio filters that fill in the vowel sounds
>>> > based on
>>> > the same kind of algorithm as auto-complete typing.  It could use the
>>> > timing
>>> > and spectrum of the audio events as one source of information for
>>> > filling in
>>> > the rest.  A decent DSP math person spending a few months on that
>>> > problem
>>> > could make some noticeable improvements.  That bar is not very high.
>>> >
>>> > Lee, where is that sound file from?  Its pretty awesome.
>>> >
>>> > .hc
>>> >
>>> > On 07/23/2013 04:57 PM, Josh Steiner wrote:
>>> >> Whoa, that is way too recognizably human for comfort.  i could
>>> >> totally
>>> >> see
>>> >> with some training being able to understand that.
>>> >>
>>> >> -j
>>> >>
>>> >>
>>> >> On Tue, Jul 23, 2013 at 1:47 PM, Lee Azzarello
>>> >> <lee at guardianproject.info>wrote:
>>> >>
>>> >>> Hello all,
>>> >>>
>>> >>> There have been some conversations recently on IRC and on the web
>>> >>> about VBR audio codecs and plaintext recovery.
>>> >>>
>>> >>> It's an interesting conversation and one which will change a lot in
>>> >>> our times. While I was testing some video call clients, I saw a bug
>>> >>> between a custom build of Linphone on Android and a nightly of Jitsi
>>> >>> on OS X where Linphone tried to play back the encrypted audio
>>> >>> through
>>> >>> the speaker without first decrypting it.
>>> >>>
>>> >>> This is what a SRTP audio stream sounds like to a wiretap. The codec
>>> >>> is speex at 16 kHZ, I believe it is VBR but I'm not certain.
>>> >>>
>>> >>> http://ge.tt/9FG7Tem/v/0?c
>>> >>>
>>> >>> -lee
>>> >>> _______________________________________________
>>> >>> Guardian-dev mailing list
>>> >>>
>>> >>> Post: Guardian-dev at lists.mayfirst.org
>>> >>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>> >>>
>>> >>> To Unsubscribe
>>> >>>         Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>>> >>>         Or visit:
>>> >>>
>>> >>> https://lists.mayfirst.org/mailman/options/guardian-dev/josh%40vitriolix.com
>>> >>>
>>> >>> You are subscribed as: josh at vitriolix.com
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> Guardian-dev mailing list
>>> >>
>>> >> Post: Guardian-dev at lists.mayfirst.org
>>> >> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>> >>
>>> >> To Unsubscribe
>>> >>         Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>>> >>         Or visit:
>>> >> https://lists.mayfirst.org/mailman/options/guardian-dev/hans%40guardianproject.info
>>> >>
>>> >> You are subscribed as: hans at guardianproject.info
>>> >>
>>> >
>>> > --
>>> > PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81
>>> > _______________________________________________
>>> > Guardian-dev mailing list
>>> >
>>> > Post: Guardian-dev at lists.mayfirst.org
>>> > List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>> >
>>> > To Unsubscribe
>>> >         Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>>> >         Or visit:
>>> > https://lists.mayfirst.org/mailman/options/guardian-dev/lee%40guardianproject.info
>>> >
>>> > You are subscribed as: lee at guardianproject.info
>>> _______________________________________________
>>> Guardian-dev mailing list
>>>
>>> Post: Guardian-dev at lists.mayfirst.org
>>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>>
>>> To Unsubscribe
>>>         Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>>>         Or visit:
>>> https://lists.mayfirst.org/mailman/options/guardian-dev/tbiehn%40gmail.com
>>>
>>> You are subscribed as: tbiehn at gmail.com
>>
>>
>>
>>
>> --
>> Twitter | LinkedIn | GitHub | TravisBiehn.com
> _______________________________________________
> Guardian-dev mailing list
>
> Post: Guardian-dev at lists.mayfirst.org
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>
> To Unsubscribe
>         Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>         Or visit:
> https://lists.mayfirst.org/mailman/options/guardian-dev/timprepscius%40gmail.com
>
> You are subscribed as: timprepscius at gmail.com
>


More information about the Guardian-dev mailing list