From lists at infosecurity.ch  Thu Jan  2 13:35:34 2020
From: lists at infosecurity.ch (Fabio Pietrosanti (naif))
Date: Thu, 2 Jan 2020 14:35:34 +0100
Subject: [bbs-revival] VoIP Modem and Wardialer for the 2020
Message-ID: <38566b33-3f36-6a78-e6e3-71732b37aaf8@infosecurity.ch>

Hello,

yesterday we (myself and Guido Flandero/KHS9NE) have released "A Voip 
Wardialer for the phreaking of 2020 
"https://github.com/x25today/voipwardialer .
<https://github.com/x25today/voipwardialer>

The main goal of the project is to have a fully working software-only 
VoIP-Modem that can be used for wardialing, dialing a favorite BBS 
running on Landline number and more.


The design is a bit "creative" but it's done a way to make the "Software 
DSP" issue pluggable and remote (now Asterisk-Softmodem connected to a 
local asterisk).


It's a Python PJSIP application that call the target phone number via a 
VoIP provider, then call the local asterisk with Asterisk-Softmodem is 
running, then provide a Terminal.


All this flow is working as MVP, would you enjoy playing with it with 
the many improvements needed 
https://github.com/x25today/voipwardialer/issues :)

-naif

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/bbs-revival/attachments/20200102/4ad9cac1/attachment.htm>

From laforge at gnumonks.org  Thu Jan  2 21:56:46 2020
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 2 Jan 2020 22:56:46 +0100
Subject: [bbs-revival] VoIP Modem and Wardialer for the 2020
In-Reply-To: <38566b33-3f36-6a78-e6e3-71732b37aaf8@infosecurity.ch>
References: <38566b33-3f36-6a78-e6e3-71732b37aaf8@infosecurity.ch>
Message-ID: <20200102215646.GT280516@nataraja>

Hi Fabio,

On Thu, Jan 02, 2020 at 02:35:34PM +0100, Fabio Pietrosanti (naif) wrote:
> yesterday we (myself and Guido Flandero/KHS9NE) have released "A Voip
> Wardialer for the phreaking of 2020
> "https://github.com/x25today/voipwardialer .
> <https://github.com/x25today/voipwardialer>

congratulations.

> The main goal of the project is to have a fully working software-only
> VoIP-Modem that can be used for wardialing, dialing a favorite BBS running
> on Landline number and more.

This is pretty much what I had in mind, too - although not specifically for
wardialing, but simply for any use case.

> The design is a bit "creative" but it's done a way to make the "Software
> DSP" issue pluggable and remote (now Asterisk-Softmodem connected to a local
> asterisk).

As you can see at http://osmocom.org/projects/linmodem/issues I had the plan
to do this based on the linmodem code from Fabrice Bellard (who needs no
introduction).  The code implements more different modems/standards than
the asterisk code, and it's not really tied to the winmodem hardware - it simply
consumes and produces 16bit samples, so all that's needed to attach it to RTP
is to do the aLaw/uLaw table lookup.

But hey, my approach is still vapourware and yours is implemented, so who
am I to make suggestions.

Happy hacking,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at gnumonks.org  Thu Jan  2 22:06:58 2020
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 2 Jan 2020 23:06:58 +0100
Subject: [bbs-revival] Sumamry of 36C3 activities / next steps
Message-ID: <20200102220658.GU280516@nataraja>

Dear all,

it was a lot of last-minute stress, but in the end I was able to present a very
well working dial-up setup at 36C3.  You can find more information about what
was presented at
 * Summary news post: https://osmocom.org/news/121
 * 36C3 wiki page: https://osmocom.org/projects/retro-bbs/wiki/36C3
 * https://osmocom.org/projects/retro-bbs/wiki/Dialup_Network_In_A_Box

Contrary to earlier plans, the main focus in this first installation was the
physical / telephony setup, and we didn't actualyl operate any BBSs on-site
but merely terminated Modem calls in the Portmaster and forwarded those via
telnet to remote (public and 36C3 specific) BBS installations.

But now as that is working, the setup will remain the same and I can try to
spend some more time on software / protocols.  I still want to run at least
one Synchronet and one Mystic BBS in Linux containers, as well as one Zerberus
instance in a qemu-kvm.  The related containers/VMs exist, but need to be
connected with the outside world and fully configured.  At future events I
then hope to be able to demo ZConnect and FTN style networks, with a QWK
reader and CrossPoint on the client/PC side.

As empty BBSs are of course quite boring, it would be good to get at
least one of them set up rather soon and then start to actually fill it
with messages.  One idea would be to gate the osmocom.org mailing lists,
but of course one can also join at least some of those FTN networks that
still exist today, which should at least fill some message areas over
time.

If anyone wants to help out, help is - as always - much appreciated.  I
can host some VMs/containers on public IP addresses, as needed.

The main two areas requiring help are, AFAICT:
* set-up of several BBSs, including connectivity to FTN networks
* set-up and test of QWK and point software
* improved qemu/telnet integration (https://osmocom.org/issues/4341)

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From lists at infosecurity.ch  Fri Jan  3 08:06:58 2020
From: lists at infosecurity.ch (Fabio Pietrosanti (naif))
Date: Fri, 3 Jan 2020 09:06:58 +0100
Subject: [bbs-revival] VoIP Modem and Wardialer for the 2020
In-Reply-To: <20200102215646.GT280516@nataraja>
References: <38566b33-3f36-6a78-e6e3-71732b37aaf8@infosecurity.ch>
 <20200102215646.GT280516@nataraja>
Message-ID: <1da38705-151c-38bd-d03a-6a8868f02faf@infosecurity.ch>


On 02/01/2020 22:56, Harald Welte wrote:
> This is pretty much what I had in mind, too - although not specifically for
> wardialing, but simply for any use case.

Yes, we also realized that focusing our current and past effort on 
trying to get a working "voip-modem" is much helpful than making a "voip 
wardialer" (because, for example, beave's iWas could work fine exposing 
a pty with basic AT emulation).


>> The design is a bit "creative" but it's done a way to make the "Software
>> DSP" issue pluggable and remote (now Asterisk-Softmodem connected to a local
>> asterisk).
> As you can see at http://osmocom.org/projects/linmodem/issues I had the plan
> to do this based on the linmodem code from Fabrice Bellard (who needs no
> introduction).  The code implements more different modems/standards than
> the asterisk code, and it's not really tied to the winmodem hardware - it simply
> consumes and produces 16bit samples, so all that's needed to attach it to RTP
> is to do the aLaw/uLaw table lookup.

I think that yours is "the right approach" from a technical standpoint 
of view.

What we tried to achieve is "something working" by gluing together all 
of the pieces, leaving for another pizza-hackaton improvements and 
stabilization.

It's *likely* that Asterisk-Softmodem doesn't provide the performance 
and stability we want (sometime is connect, sometime it does not 
connect, sometime it gives your garbage, anyhow still missing CONNECT 
and reporting of negotiated carrier speed).

So the world still miss the missing piece of a features voip-modem that 
also provide a pty.

I added osmcom linmodem to the "Software Modem" section 
https://github.com/x25today/voipwardialer#software-modem .

>
> But hey, my approach is still vapourware and yours is implemented, so who
> am I to make suggestions.

We're working to try to make this working with a commandline and 
extendit piece by piace, but really without the real 
telecommunication-grade effort-and-skills to fix the DSP problem 
properly, assuming that someone with that knowledge will help in hooking 
one of the cool and complete softmodem.

Linmodem is surely a way to go, we also spotted this nice soft-modem 
that by reading the specs seems very very interesting for it's 
integration opportunity (connecting pty and audio i/o) and the careful 
timing consideration https://github.com/randyrossi/fisher-modem .

Did you ever saw / considered this?

-naif


From laforge at gnumonks.org  Fri Jan  3 10:08:18 2020
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 3 Jan 2020 11:08:18 +0100
Subject: [bbs-revival] VoIP Modem and Wardialer for the 2020
In-Reply-To: <1da38705-151c-38bd-d03a-6a8868f02faf@infosecurity.ch>
References: <38566b33-3f36-6a78-e6e3-71732b37aaf8@infosecurity.ch>
 <20200102215646.GT280516@nataraja>
 <1da38705-151c-38bd-d03a-6a8868f02faf@infosecurity.ch>
Message-ID: <20200103100818.GD489967@nataraja>

Hi Fabio,

On Fri, Jan 03, 2020 at 09:06:58AM +0100, Fabio Pietrosanti (naif) wrote:
> I added osmcom linmodem to the "Software Modem" section
> https://github.com/x25today/voipwardialer#software-modem .

thanks.

> Linmodem is surely a way to go, we also spotted this nice soft-modem that by
> reading the specs seems very very interesting for it's integration
> opportunity (connecting pty and audio i/o) and the careful timing
> consideration https://github.com/randyrossi/fisher-modem .
>
> Did you ever saw / considered this?

Thanks.  I didn't know it, but it also seems to only implement slower
speeds and not [what I find more interesting] V.34 and/or V.90.  Also,
the fact that it's already multi-threading seems a bit odd to me.  In
the end, the modem is nothing but a process that consumes samples and
produces characters in the Rx side, and the inverse for the transmit
side.  Having a kind of library of C functions for this (like linmodem)
seems most natural to me.  But hey, that's a matter of personal
taste.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From lists at infosecurity.ch  Mon Jan  6 09:57:32 2020
From: lists at infosecurity.ch (Fabio Pietrosanti (naif))
Date: Mon, 6 Jan 2020 10:57:32 +0100
Subject: [bbs-revival] VoIP Modem and Wardialer for the 2020
In-Reply-To: <20200103100818.GD489967@nataraja>
References: <38566b33-3f36-6a78-e6e3-71732b37aaf8@infosecurity.ch>
 <20200102215646.GT280516@nataraja>
 <1da38705-151c-38bd-d03a-6a8868f02faf@infosecurity.ch>
 <20200103100818.GD489967@nataraja>
Message-ID: <29705bf7-daa3-06f6-689d-75adf537215c@infosecurity.ch>

Hi Harald,

while there are many testing that must yet be done, surely Linmodem 
and/or Fisher-Modem are much more complete DSP than Asterisk-Softmodem.

So, reaching the stage where one of the two get integrate directly, make 
much more sense.

I built both C softmodem and saw their command line, requiring as input 
a "dsp" .

Now i've opened this ticket:

Test integration of Linmodem & Fisher-Modem into the VoIP Wardialer 
trough PJSUA and Alsa hacking 
https://github.com/x25today/voipwardialer/issues/16

The idea is that we may try to use those Softmodem by playing with the 
Alsa Loopback interface having:

- 1 Audio virtual audio device for a normal VoIP Modem (being our pjsua 
or other stack or even a graphical client)

- 1 Audio virtual audio device for the Softmodem command line (for 
easier testing)

Those crossed trough Alsa Loopback interface, but formally each having 
it's own audio device.


Did you considered for testing something like this? As it could be a 
quick and dirty hacking approach, yet to be tested

-naif

On 03/01/2020 11:08, Harald Welte wrote:
> Thanks.  I didn't know it, but it also seems to only implement slower
> speeds and not [what I find more interesting] V.34 and/or V.90.  Also,
> the fact that it's already multi-threading seems a bit odd to me.  In
> the end, the modem is nothing but a process that consumes samples and
> produces characters in the Rx side, and the inverse for the transmit
> side.  Having a kind of library of C functions for this (like linmodem)
> seems most natural to me.  But hey, that's a matter of personal
> taste.
>
> Regards,
> 	Harald