• Content count

  • Joined

  • Last visited

  • Days Won


ThoughtPhreaker last won the day on February 3 2019

ThoughtPhreaker had the most liked content!

Community Reputation

173 Expert

About ThoughtPhreaker

  • Rank
    Dangerous free thinker
  • Birthday 11/02/1991

Profile Information

  • Gender

Contact Methods

  • Website URL

Recent Profile Visitors

41,552 profile views
  1. Hey! Long time no hear from you. Are you still around this board?

  2. Hi how do I logoff admin sign in screen on the Intuity Vm to get to root so I can reset sa password  


  3. If you like really obscure switches, you might want to give rural Alaska or Missouri a call. Despite the GX-5000 being ancient and end of lifed in like, 2001, I've been able to confirm that ACS of the Northland and the Choctaw Telephone company still use them. The ACS Northland GX-5000s, for whatever reason, ring a bunch of times and generate a reorder when you call a non-working number on them.
  4. 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: . 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?
  5. A friend of mine more into the computer side of things mentioned that there's some attacks based on strcmp (basically, a string compare function) and the amount of time it takes for the function to execute; basically, the function only executes until it finds a character that doesn't match. So for example, if you enter a password of 12345 but a computer is expecting 12335, strcmp will stop after the second three since no matter what, it's not going to match. So this got me thinking; in a TDM network, there's basically no varying latency once a connection is set up. A lot of IVR platforms like to return strings too, and strcmp is used very extensively for comparing them in exactly that circumstance. If you were to record the amount of time it took to compare passcodes, I'm willing to bet you'd see a tiny difference (as in, maybe a nanosecond or two) in how fast it responds with a recorder. So while if you have a nice network connection without any sort of packetization or anything this could be perfect, the flipside of this is there's a lot of IVR applications that are single threaded; basically, only one request executes at a time. So if someone else is using another channel on it, it might finish up their request before getting to yours. So this may be an attack that works significantly better late at night. EDIT: Heh, yeah,so it occurred to me that measuring nanoseconds over an 8000 samples/second medium might not be a good idea. Not that I'm still not going to see if there's any measurable difference in execution time.
  6. 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
  7. Just dialing 101-0288-0 from a phone line. I get around a lot. That being said, it seems like OSPS translations have been updated to make these routings a lot more common. If you checked it before and it failed, I'd encourage you to check it again. That being said, I've tried this from payphones I've confirmed use this routing pattern, and it doesn't seem to work. EDIT: If you want to use the old routing pattern, various AT&T/SBC CACs still use it.
  8. 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: 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.
  9. 206-204-6198 - Dialtone via ? 416-640-0468 - Dialtone via thingie. Likes to generate offhook tone for presumably invalid numbers. 206-576-7201 - Room monitor. At parking garage? Awesome reverb. 612-349-4045 - Definity conference bridge. On a hotel PBX. For...reasons. 612-349-4077 - rec, "Hello, this is your wakeup call. Today is Saturday, August 12th. Today's weather is partly cloudy with a high of 81 and a low of 59. Thank you so much for staying with us here at the Marriott City Center and have a wonderful day." 612-349-4017 - Modem 612-349-4031 - 300 baud modem 612-349-4072 - Modem 612-349-4073 - Modem 612-349-4096 - Modem 847-954-7205 - Modem 847-954-7095 - Room monitor. In switchroom? 847-954-7093 - Modem 847-954-7041 - Ringout bridge 847-954-7011 - Modem 847-954-7506 - Ringout bridge 847-954-7512 - Ringout bridge 847-954-7599 - Time and temperature announcement, has weird, dying old people ads 847-954-7731 - Modem 847-954-7799 - Ringout bridge 970-547-4098 - Modem 970-547-4096 - Modem 970-547-4092 - DISA on Definity PBX
  10. I've been working a little bit with the Definity today, and thought an update would be warranted: So through some quick trial and error and comparing to older releases, I was able to find the 2560 byte blob that is the license file in the translations, an identical copy stored in RAM by the fg_mapa process. Strangely enough, there seems to be some sort of redundant copy of this around somewhere; if you start manipulating the copy in fg_mapa and tell the switch to test the license, it'll very quickly change it back to what it should be. Thankfully, the switch comes with some very nice debugging utilities that should make figuring out where it's getting another copy to fix this (it isn't the translations card; I tried pulling that out. Though obviously, if you corrupt the copy on the translations card, it's going to have a much harder time getting another copy from RAM when you reboot. This helped verify a lot of this) a lot easier. There's going to be a few things to consider here, like how an actual license file differs from what the Definity stores (you're supposed to be able to paste it in using the ossi interface on the switch. The Definity won't accept the license you pull from RAM, however), but all in all, this should make the rest of the process a lot less painful.
  11. 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 ); };
  12. The ability to use OSPS seems to be on a switch-by-switch basis. I'm not quite sure what the pattern is, but if you want to scope this out, I encourage you to check every office you can locally.
  13. I've had a few people report that in some areas where this doesn't work yet you home off of a 5ESS toll tandem (and can dial 101-0288# and get a dialtone from it), sometimes dialing 101-0288# and then 0 at the dialtone will work. I'm beginning to think this has less to do with the office you're coming out of, and more to do with something in the SS7 initial address message. EDIT: I'll try to confirm, but this exception may not apply to payphones.
  14. There's always been little slip-ups in the way AT&T restricts 800 numbers from 101-0288-0, for anyone old enough to remember that. But more recently, they've been doing some sort of weird call distributing technique; for example, if you're in one of these affected areas, they'll distribute calls to different OSPS switches throughout the country. Something about the trunk group you come in on instructs the network to allow 800 calls out from OSPS again from these areas. If you're around any of these areas, I've confirmed with some friends that it'll work: Washington, DC San Francisco, California Ontario, California Fresno, California Muskegon, Michigan Oberlin, Ohio Cincinatti, Ohio Lincoln, Nebraska Orlando, Florida Tampa, Florida Manchester, New Hampshire Denver, Colorado Dickinson, Texas Des Moines, Iowa Springfield, Massacheusetts Chicago, Illinois Rolla, Missouri Kansas City, Missouri Fargo, North Dakota As always, toll-free calls through the Honolulu and San Juan OSPSes will go through like they always have. There's also a few interesting scenarios, like tiny LECs with direct trunks to OSPS, where toll-free traffic has always gone through.
  15. Great to see some new faces! Especially in this thread. 0051 is a DATU. 0037 is a 105-type test as I think it's officially called. I think the idea is they do trunk testing. In any case, press 2, #, etc to make it produce tones and noise. 0 commonly hangs up on those things. 407-238-6209,6238 - Elevators on hotel PBX (Nortel Meridian) 407-238-6214 - Modem on hotel PBX: CONNECT CentOS release 6.5 (Final) Kernel 2.6.32-431.29.2.el6.x86_64 on an x86_64 XetaCAS_22832_MarriottRoyalPalms login: 843-414-0052 - rec, "We're sorry, your telephone is temporarily out of order. There may be a receiver off the hook. Please check your main telephone and extensions. Charleston, South Carolina. 843-1. CHTN." 502-753-0021 - 17A announcement machine 502-753-0059 - IVR, "Please enter your home phone number" 504-648-0010 - 17A announcement machine