Sign in to follow this  
Followers 0
docx

handscanners assistant.

13 posts in this topic

at various points in my life i've written little handscanner assistant utilities.. yes, i know there are some already out there - whatever.. i like to code.

 

i've been working on a new project called cons0le (and cons0le-web). i restarted this project because i recently obtained a dialogic diva card and wanted to play with some of the features of the card. at this point i am reaching out to see what realistic features any of you might want to see added to such an app... It is a windows based app written in vb.net and also a javascript counterpart web based app. 

 

current working or to be worked on items are:

 

- random/sequential dialing of multiple npa/pre/suff

- extreme scheduling/timing of scan jobs 

- dtmf detection

- dtmf send either via dial string or live during call via mouse clicks

- outgoing .wav either on outgoing calls or incoming calls

- tone detection in general

- definable call documentation as well as presets (vmb, ringout, etc..)

- sync with a master web app which will provide a "phone book" type interface 

- master web app will also be able to generate npa/pre/suff and log calls via presets/user definable buttons

- f2f syncing of results files. (encryption type is still up in the air on this..)

 

All of the above is already set in stone.. I would love to hear any suggestions for other features though.. 

 

doc

2

Share this post


Link to post
Share on other sites

Posted (edited)

Heh, now that's sort of a weird coincidence. I was working on a Linux Diva dialer earlier today! This is in C, but given the similarities of the API calls, feel free to use any of this if you find it useful; it's just a modified version of demo code and the default tone detection rules. If it interests anyone enough, I'll get off my ass and make it multi-channel/a little more script friendly. That being said, imho, there's a much more practical use of telephony boards like these though. Granted, this is written for a CG6565E (also modified demo code. I do write actual things; the CG cards are sort of an annoyance to develop for though, so I'm keeping away from it for now), but take a listen: nmsscan.wav        .

 

The star key is returning the last four digits of the number being dialed. 6 is being used to move that number up by one, and five is being used to play back what happened on that particular number. Other than that, all signal processing is manual. Sorry about the noisy/low volume to the distant end; there's a reason for that. But more to the point, notice we blew through nine numbers (with a lot of ringouts) in the span of two minutes. If anybody wants the prefix of this though, it's 720-746.

 

A compromise of these two ideas would be amazing; something that, for example, let you review scans, but skip over common things like vacant numbers, or perhaps more importantly, numbers that just ring and go nowhere. As the recording demonstrates, that's easily the most time consuming part of a scan. Though it can also be rewarding long term if you're looking to learn how to compare the sound of ringback from one switch type to the next.

 

>

/*-----------------------------------------------------------------------------
 *
 * Copyright 2001-2014    Dialogic(R) Corporation
 *
 * All Rights Reserved.
 *
 * This software is the property of Dialogic Corporation and/or its
 * subsidiaries ("Dialogic"). This copyright notice may not be removed,
 * modified or obliterated without the prior written permission of
 * Dialogic.
 *
 * No right, title, ownership or other interest in the software is hereby
 * granted or transferred. The information contained herein is subject
 * to change without notice and should not be construed as a commitment of
 * Dialogic.
 *
 * This application code is not part of any standard Dialogic product and is
 * provided to you solely for the purpose of assisting you in the development
 * of your applications with Dialogic Diva SDK. The code is provided "AS IS",
 * without warranty of any kind. Dialogic shall not be liable for any
 * damages arising out of your use of this application, even if it has been
 * advised of the possibility of such damages.
 *
 *-----------------------------------------------------------------------------
 * Sample for an outgoing call including streaming a file.
 *
 * The sample shows how to connect a single call, to stream a message and to
 * disconnect. The sample is started from the command prompt. The phone number
 * to dial and the file to stream must be specified as parameter.
 *
 * Note that this sample is designed to show very simple how to process a
 * single call and to stream audio. Therefore the sample does not do any
 * error handling.
 *----------------------------------------------------------------------------*/

#include <stdio.h>
#ifdef WIN32
    #include <conio.h>
#endif
#include <string.h>
#include "dssdk.h"

 

/*
 * Some globals
 */
DivaAppHandle   hApp = NULL;
DivaCallHandle  hSdkCall = NULL;
AppCallHandle   hMyCall = NULL;

void CallbackHandler ( DivaAppHandle hApp, DivaEvent Event, PVOID Param1, PVOID Param2 )
{
    switch (Event)
    {
    case DivaEventEarlyDataChannelConnected: // Geez, what a mouthful...
        if ( DivaReportTones( hSdkCall, TRUE) != DivaSuccess ) {
            printf( "Failed to initialize tone reporting. Disconnecting...\n" );
            DivaDisconnect ( hSdkCall );
        }
        // Instruct the board to create a timer that expires after 30 seconds
        if ( DivaStartCallTimer( hSdkCall, 30000 ) != DivaSuccess ) {
            printf( "Fuck, something is really wrong; we can't create a timer event.\n" );
            DivaDisconnect ( hSdkCall );
        }
        else
            printf ( "Call progress received! Listening for network events...\n" );
        break;
        
    case DivaEventCallConnected:
        printf( "Call suped!\n" );
        break;
        
        
    case DivaEventCallTimer:
        printf( "Call analysis timed out. Disconnecting...\n" );
        DivaDisconnect ( hSdkCall );
        break;
        
    case DivaEventToneDetected:
            if ( Param2 == 201 ) printf( "Human speech detected\n" );
            if ( Param2 == 138 ) {
                printf( "SIT tone received! Disconnecting...\n" );
                DivaDisconnect ( hSdkCall );
            }
            if ( Param2 == 160 ) printf( "SIT 0 received.\n" );
            if ( Param2 == 161 ) printf( "SIT 1 received.\n" );
            if ( Param2 == 162 ) printf( "SIT 2 received.\n" );
            if ( Param2 == 163 ) printf( "SIT 3 received.\n" );
            if ( Param2 == 164 ) printf( "Operator intercept SIT received.\n" );
            if ( Param2 == 165 ) printf( "Vacant circuit SIT received.\n" );
            if ( Param2 == 166 ) printf( "SIT for recording received? What?\n");
            if ( Param2 == 167 ) printf( "SIT for no circuit found received.\n" );
            if ( Param2 == 134 ) printf( "Call is ringing...\n" );
            if ( Param2 == 135 ) printf( "Call is ringing back. Specially...\n" );
            
            if ( ( Param2 == 194 ) || ( Param2 == 195 ) ) {
            printf( "Modem or fax answer tone received.\n" );
            DivaDisconnect(hSdkCall);
            }
            if ( Param2 == 198 ) {

            // This is probably not useful; 2200 hertz modem tones are in practice grabbed by the above rule.
            printf( "Oldschool modem answer tone detected.\n" );
            DivaDisconnect(hSdkCall);
            }
            
            if ( Param2 == 136 ) {
            printf( "Call is busy. Disconnecting...\n" );
            DivaDisconnect(hSdkCall);
            }
            
            if ( Param2 == 137 ) {
            printf( "Reorder tone came back. Disconnecting...\n" );
            DivaDisconnect(hSdkCall);
            }
            
            if ( Param2 == 130 ) {
            printf( "Holy shit, we got a dialtone! Quick, go phr34kz0r it! NAO!!\n" );
            DivaDisconnect(hSdkCall);
            }
            
            if ( Param2 == 131 ) {
            printf( "PBX dialtone received.\n");
            DivaDisconnect(hSdkCall);
            }
            
            if ( Param2 == 132 ) {
            printf( "'Special' dialtone received. Don't you feel special?\n" );
            DivaDisconnect(hSdkCall);
            }
            
            if ( Param2 == 133 ) {
            printf( "Stutter dialtone received!\n" );
            DivaDisconnect(hSdkCall);
            }
            
            if ( Param2 == 202 ) {
            printf( "Answering machine tone (theoretically; 390 hertz) heard\n");
            DivaDisconnect(hSdkCall);
            }
            
        break;

    case DivaEventSendVoiceEnded:
        DivaDisconnect ( hSdkCall );
        break;

    case DivaEventCallDisconnected:
        hSdkCall = 0;
        DivaCloseCall ( Param2 );
        printf ( "Disconnected\n" );
        DivaUnregister ( hApp );
        DivaTerminate ();
        break;

    default:
        break;
    }
}

 


int main(int argc, char* argv[])
{
    char    DialString[100];
    int     c;

    if ( argc != 2 )
    {
        printf ( "USAGE: numidentify <phone number>\n\n" );
        return -1;
    }

    strcpy ( DialString, argv[1] );
    // heh, strcpy. Don't look at me, it's not my code! You, uh, you might want to change this.

    printf("Version: %d.%d\n", (DivaGetVersion() >> 16) & 0xffff , DivaGetVersion() & 0xffff );

    if (DivaInitialize() != DivaSuccess)
        return -1;

    hMyCall = (void *) 0x11223344;

    if ( DivaRegister ( &hApp, DivaEventModeCallback, (void *) CallbackHandler, 0, 1, 7, 2048 ) != DivaSuccess )
    {
        return -1;
    }

    if ( DivaConnectVoice ( hApp, hMyCall, &hSdkCall, DialString, LINEDEV_ALL, "", "0", DivaVoiceOptionEarlyDataChannel ) != DivaSuccess )
    {
        return -1;
    }

    printf ( "Number identifier running, press <ENTER> to terminate\n" );

    while ( 1 )
    {
#ifdef WIN32
        c = _getch ( );
#else
        c = getc (stdin);
#endif
        if ( c == 'q' )
            break;
    }
    printf ( "Number identifier stopped\n" );

    DivaUnregister ( hApp );
    DivaTerminate ();

    return ( 0 );
};

Edited by ThoughtPhreaker
0

Share this post


Link to post
Share on other sites

Something I didn't mention is that the handscanner assistant (cons0le) will not just be for the Diva, it will also be able to be used with voice modems - and with a much dumbed down feature set - regular modems with no voice features at all.

 

to one of your thoughts - and this would be far down the line as my level of coding is not quite to this point yet - but i like the idea of tone pattern matching to identify and eliminate.. i also like the idea of doing CNAM pulls on numbers dialed to eliminate certain types of destination numbers from even being dialed. 

 

I'm getting quite far in my wardialers.org project and it will be at a point of resting and promoting soon, at which point i will continue and accelerate work on cons0le.. i will definitely seek input and testers here if anyone thinks they might be interested..

0

Share this post


Link to post
Share on other sites

Posted (edited)

I've been doing development on and off of things of this nature for the Diva and JCT/DM3 cards with a friend - and hopefully more platforms soon. If I can get results I'm happy with relative to handscanning, I'll post some more about it. For the interim though, here's a partial wardial of a DMS-500, and what results I get from calling the numbers normally: https://pastebin.com/jra4HUB0

 

PAMD means Positive Answering Machine Detection, PVD is Positive Voice Detection (these are the stupid Dialogic marketing terms that come back from the call progress detector. I should really change that), CB is cadence break (for example, something answered in the middle of a ring cycle, and no other tones were detected). The code has since been updated to differentiate between modems and faxes. One thing I'd like to do next is voicemail tone recognition to differentiate between unique systems. I'll post the frequencies here if you'd like to do the same. There's some things though, like distinguishing between different ringback tones, that I doubt the DSP will ever be able to do. While it sounds annoying to have to pull together, other software on the host computer could very well do it. One more frustrating thing about the JCT cards is their ability (by default anyway) to tell the difference between different SITs is limited, so they're not of much help in finding interesting error recordings.

 

Honestly, I have really mixed feelings about this. I don't want to get lazy and stop looking at ranges by hand, but this has proven really useful for finding test ranges on obscure switches like this one. The DSPs are fast, flexible and ruthlessly efficient.

 

Back to voice modems though, don't some of them have tone recognition features? I'd assume at least with the Diva, you can adjust what tones it comes back with from the AT interface. With the code I pasted - and presumably other things since it uses the default tone definitions, if you happen to have the misfortune of hitting a Definity over a trunk with something horrible like g.729, it'll sometimes mistake the warble/intercept tone (the thing that goes back and forth between 620 and 440 hertz) for a dialtone.

Edited by ThoughtPhreaker
0

Share this post


Link to post
Share on other sites

I remember scanning out then 206-694 and -696 on a metal-geared WE 500 rotary fone in the early 90s, looking for carrier tones (this was during the heyday of BBSes and the emerging commercial ISP industry and I was sort of into BBSing back then). I also remember my right index finger getting quite sore after about 75 numbers or so. What I would have given to have had an operator's dialing tool back then. I think I only did about 200 numbers or so on either, but gave up when I found that some phreak in GTE land (probably Camas) had already done the work for me and posted a full scan of VANCWA01CG0 to a local BBS. To this day I have no idea if they did it manually or by computer and I wish I had thought to ask. I think I may still have that half a ream of tractor-fed printout somewhere even though I probably haven't looked at it in 25 years.

Hmmm, I still have that fone and 360-694/6 haven't gone anywhere. There are no more dialup BBSes around here that I'm aware of but I know there are a bunch of test lines and recordings on there...

Of course back then we didn't have fancy things like electricity or indoor plumbing, the train brought us our mail once every two weeks and we walked 5 miles every day in waist-deep snow to get to school.

0

Share this post


Link to post
Share on other sites
21 hours ago, ThoughtPhreaker said:

Back to voice modems though, don't some of them have tone recognition features? I'd assume at least with the Diva, you can adjust what tones it comes back with from the AT interface. With the code I pasted - and presumably other things since it uses the default tone definitions, if you happen to have the misfortune of hitting a Definity over a trunk with something horrible like g.729, it'll sometimes mistake the warble/intercept tone (the thing that goes back and forth between 620 and 440 hertz) for a dialtone.

Most do, yes.   But it's touch and go in detection.  Hardware works better than software of course but software like Warvox has tone detection at the core of it's detection logic.

0

Share this post


Link to post
Share on other sites
18 hours ago, scratchytcarrier said:

There are no more dialup BBSes around here that I'm aware of but I know there are a bunch of test lines and recordings on there...

 

What's the fax line count?  Don't forget there is SCADA systems out there using modems along with alarm systems and other dialup infrastructure.  Just because the BBS is gone, doesn't mean that it's not worth scanning.  I guess the key phrase is to be `selective`.

0

Share this post


Link to post
Share on other sites

Posted (edited)

So I just finished up doing a basic run-through of beep tones for various voicemail and answering machines. Keep in mind if you're implementing this on something like Dialogic hardware and actually want to measure the time of the tone (you're awesome for going the extra mile if you do), you'll have to account for how long the voicemail system will listen for silence before waffling on with menu options or hanging up or whatever; it's not considered the end of a cadenced tone until it hears something else. Since this is user definable, I'd suggest testing with a nice average, like 9 seconds of silence after the tone with five second deviation (so 4 through 14 seconds of silence before it hears something else). Bear in mind too that if you're going to use any sort of IP trunking, packet loss is going to hamper performance quite a bit; if there's packet loss in the tone, it'll be considered two short tones instead of one long one. If there's packet loss concealment, it's going to stretch the samples out to an inconsistent length. Anyway, I'll probably update this with more stuff in time.

 

Octel - 385 hertz, 250 milliseconds
non-Dialogic Audix - 850 hertz, 480 milliseconds
Anypath - 850 hertz, 400 milliseconds
Dialogic DM3/HMP,JCT - 1000 hertz, 400 milliseconds (JCT is quieter, has non-sine waveform. There are a number of voicemail systems that're based on these cards and simply use the beep tones baked into the firmware)
Avaya Aura - 1000 hertz, 380 milliseconds
Newer NEC Univerge systems - 1000 hertz, 550 milliseconds
Verizon Wireless VMS (Comverse?) - 1000 hertz, 200 milliseconds (this one is weird; it's composed of four studders that're each ~45 milliseconds long with 5 millisecond spaces. Whoever made this is stupid. Have your detector ready to account for this)
Qwest/AT&T UM - 440 hertz, 140 milliseconds (sometimes it studders too, but this shouldn't hurt detection)
APMax, AP? - 440 hertz, 280 milliseconds
Comcast - 1650 hertz, 140 milliseconds
Nortel Callpilot, key systems - 500 hertz, 550 milliseconds
Ringcentral - 620 hertz, 300 milliseconds
Google Voice - 585 hertz, 360 milliseconds
Cisco Unity - 425 hertz, 500 milliseconds
Metaswitch - 440 hertz, 150 milliseconds
Newer Toshiba Strata - 790 hertz, ~480 milliseconds (this one fades out, so you may have to give whatever detector you're using some grace period; it probably won't hear the whole thing)
Cox - 1400 hertz, 480 milliseconds
Middle-aged Panasonic answering machines - 1040 hertz, 800 milliseconds
Rolm Phonemail - 950 hertz, 125 milliseconds
GTE (custom Glenyare?) - 1330 hertz, 400 milliseconds
Stock Glenayre - 1400 hertz, 240 milliseconds
Shoretel - 2000 hertz, 200 milliseconds
ESI - 620 hertz, 395 milliseconds
Newer Panasonic answering machines - 1000 hertz, 420 milliseconds
Older (late nineties to mid 2000s) Panasonic answering machines - 1000 hertz, 1000 milliseconds
Older Intertel - 650 hertz, 220 milliseconds
Newer Mitel Express Messenger/Nupoint systems - 795 hertz, 380 milliseconds (like the newer Stratas, this one fades down)
Middle-aged Toshiba Strata - 440 hertz, 490 milliseconds (this one fades *in* for...reasons)
Older Centigram/Mitel Nupoint systems (same thing) - 1000 hertz, 200 milliseconds
Some Comdial systems (mid-nineties or so) - 650 hertz, 500 milliseconds (this one fades down)
Some Avst systems - 1000 hertz, 450 milliseconds
T-Mobile - 1000 hertz, 200 milliseconds

Edited by ThoughtPhreaker
1

Share this post


Link to post
Share on other sites

What's the fax line count? Don't forget there is SCADA systems out there using modems along with alarm systems and other dialup infrastructure. Just because the BBS is gone, doesn't mean that it's not worth scanning. I guess the key phrase is to be "selective".



It's definitely worth scanning, once I find some time to get going on it. In fact I started doing one 4-5 years ago or so (think it was 696-9xxx) but stopped after a couple dozen lines for some unknown reason. I did post a few from that scan in one of the "some numbers" threads. My main focus back in the day was on BBSes just because that's what I was into at the time, I don't think I was really aware of infrastructure and SCADA on the open PSTN then.

Fax machines, don't know about today but as I remember they were all over the place a couple decades ago. Probably aren't nearly as many as there were but there's guaranteed to be a bunch -- VANCWA01DS0 services the downtown area where several law firms, insurance offices and a hospital are based (as well as the Clark County courthouse and all the area's administrative services), and a fax of a document is still legally considered admissible in court. It would really be a trip to find a working telautograph in the wild and on the network, assuming there are still any of those left.

0

Share this post


Link to post
Share on other sites

So a bit of an update; I've got the aforementioned detection code running on analog JCT boards, and have been experimenting with implementing this as an ISDN thing on JCT T1 and DM3 boards. It's gone good so far (aside from a couple nasty bugs), and at the end of the day, is something I'm quite proud of. Namely because I had to do my own implementation of (most of) a Q.931 stack. For that reason, it's attached to the general Dialogic IVR/ISDN router/voicemail/whatever code I already have.

 

One of these days, I'd like to make this a little more flexible in terms of configuration, add a few additional features (a couple projects in progress are conferencing and doing realtime processing/playback of streams from the internet, though I'd like to add a basic GR-303 phone switch to it in good time), make everything a little more presentable, and throw the source up for anyone to use. Especially since when you look at the software that's currently out there for these cards, it's one of the few things that takes real advantage of what they can do, and quite frankly, doesn't suck.To give you some context on this, I'll leave you with the like, one piece of software that actually, just barely, supports DM3 stuff, and only for basic functions: https://voiceguide.com/ . Kinda makes a huge buzzkill out of $30 quad T1/E1 cards with their own, functionally independent OS/DSP/timeslot interchange/etc, doesn't it? Doubly so seeing as you have to run it in Windows.

 

Anyway, I don't mean to derail the thread or anything. Are there any other tones that should be added to a wardialer? It's been a very, very long time coming to make wardialers useful for finding things that aren't modems. and whatever you're choosing to do it with, I think this is the thread for it. For that matter, can this detection be added to things like, say, Cisco routers (they can do a reasonable amount of IVR stuff with TCL scripts) or voice modems?

Edited by ThoughtPhreaker
0

Share this post


Link to post
Share on other sites

old school as you can get... lots of work to do but the basics are coming together... being written for the dialogic diva but will eventually also have voice modem support (under windows 7 of course - no TAPI in windows 10...)

 

 

Untitled4.png

0

Share this post


Link to post
Share on other sites

dang TP -  I guess I didnt remember you sharing the code/tones with me... Thats excellent shared work that will save me an assload of time...

 

I've been seriously considering adding a "save call audio" feature which could then be post-parsed for hits on tones .... not sure whether I should do that or just try to keep it all inside the app live time..

 

also adding a "rec0n" feature right now that will allow the user to hit various search facilities to gather data about the number. 

 

there is also a "cons0le.web" side to this where an individual can handscan from the same databases they are scanning at home, see scanned results, make edits, etc... it is not near as mature as this is and with me being just one guy I figure I'm going to get this piece at least doing rudimentary math, dialing, and detection before giving that web side any more love...

 

funny enough "Darkthrone Scan Director" for the c64 is one of my biggest memories of back in the day that is making me want to get this running.. :)

0

Share this post


Link to post
Share on other sites

Thought Phreaker - based on your code I am assuming you are relying on the diva's detection abilities for all of your results - i.e. no soundcard support for your dialer?

 

I got the soundcard support thing figured out in VB... Only thing is - it appears that it will not pass the call off to the sound card until ringing is over... I want to hear the ring... With that said I'm likely going to build voice modem support into my dialer as well. but at least I've gotten this far..

 

Adding the random/timing elements to the scanner now so at least its functional ... 

 

we should collab on this.. it could be a revival of people interested in scanning maybe? Good for everyone..... Me and a buddy were thinking maybe you would be cool to collaborate with in general as well............

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0