• Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by ThoughtPhreaker

  1. This might be the last time I get to hear a US West TOPS switch hassling me for money, so I thought I might record it. I didn't have a pickup coil with me at the time - still don't actually, I should probably find my way to one. But anyway, sorry about the automatic gain control. Next time I do this, I'm going to use something a little cleaner. All I had at the time was my Dialogic box, though. In case you were wondering, this switch is indeed the sort of thing you can redbox, but it typically doesn't ask you for money retroactively. It's doing this (it actually never cut me off if you're wondering; I sat there for like twenty minutes. The tops_2.wav stuff is the last thing it said) because Qwest doesn't use TOPS for operator services anymore. It's not programmed to automatically cut you off and there's no person it can call to intervene, so, well, it just lets the call go on forever. And probably raised an alarm on the console. I've never heard it myself, but the TOPS manual says it can actually get pretty aggressive; it'll call you back to try and get you to pay if you let it. I was really disappointed when it didn't. If you listen to the way it says "past", you can hear this subtle looping sound on the end of the T syllable. This is a characteristic thing the Nortel EDRAM card does - the closest we'll get to proof here that the tandem is a DMS. Funny enough, we actually do have the original files the switch is playing back; it's some form of 32k ADPCM. It's all in some sort of strange container format that nobody could ever figure out, though. If you'd like to try your luck with it though, this is the archive with all the stock EDRAM stuff. eacts0ae.bin44 has all the ACTS stuff in it: . I'll post a manual for the card at some point. The .bin44 extension implies that it's binary as per usual, but the 44 after indicates the logical record length of the file is, well, 44 bytes. tops_1.wav tops_2.wav
  2. ...aka the Fuck Scribd thread. For some reason, people have uploaded a ton of hard to find documentation to this site, so I'm sticking it here where it belongs. I don't have a very permanent place for these documents at the moment, but you're more then welcome to do whatever you want with them. Here's an index of the documents: - Verizon Central Office Concepts: Introduction to Telephony Basics (2002) - CCITT7 in the 5ESS Switch - 5ESS Cable Guidelines Handbook - Switch-Basics-5ESS.doc (despite the name, it also talks a bit about the Alcatel E10/OCB-283 and EWSD) - BSNL-5-ESS.pdf (there's a few of these. Sorry, some of the Indian intro documents are a bit redundant) - Innovative Systems Applications Peripheral Administration Center software manual - 5ESS-2000 V5 Student Guide - Taqua/Tekelec/Genband/whoever the hell owns it now T7000 Command Line Interface Manual - 5ESS Switch Circuit Pack Compatibility Guide - DMS-300 International Gateway Feature Planning Guide 1998 - 5ESS Switch Input Messages: Volume 3: BKUP - END - 5ESS Switch Input Messages: Volume 8: STP:M - WRT - Alcatel 1000 S12 Functional Description - Cognitronics McIAS 1610 (aka Expanded Announcement System) manuals - EWSD Overview in One Day (Powerpoint with lots of annoying transition effects, but does a good job explaining the switch's architecture) - AT&T Ask Yourself Handbook, Issue 42, 11/15/11 - Lahore Telecom College Alcatel Exchange Book - 1 - Alcatel 1000 E10 MTNL Training Report - DMS Supernode XA Core Product Brief And if manuals aren't your thing, there's some logs! So for some reason, someone uploaded Mexican switch logs to the site with a lot of trunk group printouts. Not only does the guy log into several DMS-100s and CS-2000s, one time his password gets echoed back in plain text! Incidentally, if you look at some of the DMS-100 banners, you'll see that some of them have '88k' or 'XAC' next to the software version. These seem to be processor architectures; in the early life of the DMS-100, it was using what Nortel called the NT40 card. From what Wikipedia says, apparently it was composed mostly of discrete logic chips. Then the DMS Supernode Computing Module was based on a pair of Motorola 68k processors. By the early nineties, they were rolling out 88k processors. And by 2000, well, I have no idea. There's new CM cards Nortel made based on what they vaguely call "XA Core", or, well, Extended Architecture Core. Pretty specific, hm? Anyway, on some of these CS-2000 will have something labeled 'PPC3' in their place. Kinda makes you wonder. Did they start using PowerPC chips?
  3. There's been a conference that's consistently been going on every day at 10 PM Eastern. If you're bored, drop by . 631-788-0001, xt. BINREv
  4. So after some consideration, I thought here would be a good place to post some info on some US West integration lab switches. There's no real potential for fraud given the circumstances, and plenty for good fun. These are, as the name would suggest, isolated almost entirely from the PSTN. 303-707-9122 and 9123 are the access numbers. 9122 is a DMS-100, the latter a 5ESS. So, well, where to start with these things? As you probably expect, the dialplan is sort of make it up as you go along. There's some common ground between the two, but the differences are quite easy to rack up. So, well, listing this stuff seems like as good a way as any to present it. By the way, the 5ESS has a more digit-by-digit translation style, so it can be easier to find stuff through, but it's harder to tell where a call is going. The DMS-100 makes a soft tick on inter-office calls and sounds louder on intra-office stuff. DMS-100 things: 1-800-555-1212 goes to a cryptic IVR asking you for a destination number Some CACs go to a Sonus stock recording (no doubt a lab Sonus), others just go to reorder 720-993 (lab DMS-10; -1000 is remote call forward dialtone) is available Some CLASS features like *67, *82 available. *69 works occasionally. The first time I tried it, it told me 720-995-3037 called, the second it just turned it's nose up. 303-444-4444 gets wrbly live rep of some kind 5ESS things: Some CLASS features like *60, *63, etc available. 011-anything rings out to a Qwest UM VMB Generic, blanket numbers that ring out to the Qwest UM VMB do it via some other switch; the DMS-100 does it on it's own Generic, blanket numbers going to the Qwest UM VMB do not allow you to enter another account number, unlike the DMS 303-444-4444 gets ACB recording 602-379-9999 rings out via 5ESS to some other UM VMB, allows entering in whatever account you want. You'll notice quite quickly that it doesn't have any UM VMBs in public service. 406-958-xxxx goes to Sonus Other stuff: 303-994-00xx go to Qwest update center (*78) IVR with weird context 720 and 303-99x, 98x seem to be where the most interesting stuff is. 720-995: 0399 - NIS via lab 5ESS 1000 - lab DMS-100 ringout? Via lab 5ESS, gets NIS 1001 - NIS via lab 5ESS 2999 - lab DMS-100 ringout 3000 - Qwest busy line doohickey 3001 - Ringout to Reorder 3002 - Same as 3001 3003 - Same as 3001 3004-3006 - Reorder 3007 - Same as 3001 3008 - Reorder 3009 - Ringout 3010 - Ringout 3011 - Busy signal via ? 3012 - NIS via lab 5ESS 3013 - NIS via lab 5ESS 3014 - NIS via lab 5ESS 3015 - NIS via lab 5ESS 3016 - NIS via lab 5ESS 3017 - Ringout 3018 - Ringout 3019 - Ringout 3020 - Ringout to Embarq Meatwitch VMB 3021 - Ringout 3022 - Ringout 3023 - Ringout 3024 - Ringout 3025 - Ringout 3026 - Ringout 3027 - Ringout 3028 - Ringout 3029 - Ringout 3030 - NIS via lab 5ESS 3031 - NIS via lab 5ESS 3032 - NIS via lab 5ESS 3033 - Ringout 3034 - Ringout to UM VMB 3035 - Ringout to Meatwitch VMB 3036 - Ringout to Meatwitch VMB 3037 - Ringout to Meatwitch VMB w/greeting 3038 - Ringout to Meatwitch VMS, cannot send message 3039 - Ringout to UM VMB 3040 - Ringout to Meatwitch VMB, lab VMB for 720-995-3040, 303-396-9346 3041 - Ringout to 5ESS NIS rec 3042 - Ringout to Meatwitch VMS 3043 - NIS via lab 5ESS 3044 - NIS via lab 5ESS 3045 - NIS via lab 5ESS 3046 - Ringout to NIS via lab 5ESS 3047 - Ringout to NIS via lab 5ESS 3048 - Ringout to NIS via lab 5ESS 3049 - Reorder via DMS 3050 - Ringout 3051 - Ringout 3052 - Ringout 3053-3099 - NIS via lab 5ESS 3100 - NIS via lab 5ESS 3999 - NIS via lab 5ESS 4000 - Busy via ? 4100 - Ringout to Meatwitch VMS 5000 - NIS via lab 5ESS Other 5ESS fake toll prefixes: 206-358-? 541-245-? 928-xxx-xxxx? 612-374-? 575-606-? As for calling these things, there's a few things that you should probably know. If you want to make multiple calls on the same call, press ##. The phone patch will beep twice. Press ** in reasonably rapid succession and it'll get you a new dialtone. Sometimes when you press * normally, it'll do this annoying thing where it doesn't pass the DTMF to the switch, but briefly increases the volume level. If you want to pass a * when it does this, wait for the volume level to return to normal before pressing * again. On regular calls, *# can be used to flash. Much like any other, the 5ESS will consider a flash on any sort of local intercept or reorder a request for new dialtone. Have fun! Post if you find anything cool . Or for that matter, if you have any questions. Most of these notes were made without a big audience in mind, so some of the terms (UM, for example is Unified Messaging. The Centurylink platform in ex-US West areas is an AT&T Labs Unified Messaging thingie if I understand correctly) aren't especially obvious.
  5. 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.
  6. 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?
  7. 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.
  8. 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
  9. 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.
  10. 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.
  11. 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.
  12. 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
  13. 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.
  14. 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 ); };
  15. So earlier today, I happened to call a CVS Pharmacy, and out of sheer boredom, started hitting options that weren't listed on the IVR. As luck would have it, 8+xxx will transfer you to a three-digit extension in the store! The few constants I've noticed from a quick, cursory glance are 4xx go to IVR extensions, 500 prompts you to log in - presumably to voicemail, and the lower extensions seem to be for in-store stuff. 100 pretty consistently goes to a fax. If you happen to have a "friendly" neighborhood CVS near you, be sure to give them a "friendly" phreak welcome .
  16. 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.
  17. 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.
  18. 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
  19. MtnHell and I talked about this a while back. It appears the switch is sending a battery drop and putting him back on his own dialtone. I've only seen a 5ESS reset like that a few times before in...ever. Usually only with very specific circumstances, like someone releasing a coin trunk, or CAC-0-710+ call attempts.
  20. For whatever it's worth, when I worked in broadcasting, most radio stations I saw used Telos NX12 or Vx hybrids. I would try to familiarize yourself with those (sometimes they have promotional videos with a DJ inside the booth - that'd be a good place to look for either) and see if you can match the sounds up with them. For whatever it's worth, in addition to the echo cancellation as Jman mentioned, there's also an option for other processing on most modern hybrids, like multi-band compression and automatic gain control.
  21. A friend of mine brought back Scanaday:
  22. Sure enough, 101-9017-1-405-959-0000 from a switch in Oklahoma City gets you some sort of weird test number from the tandem switch. Other stuff probably isn't far behind.
  23. :I thought it'd be a good idea to keep a thread open for small, marginally interesting tricks that can be applied in the network. Especially since they can sometimes turn into larger things when they're explored. So, well, I'll start: In lots of ex-SBC areas, you can dial your home NPA + 700-4141 and get a recording from one of the local tandems (as in, a non-toll switch that handles calls between you and an exchange down the road or to a toll carrier) thanking you for choosing SBC as your intra-LATA toll carrier. Sometimes the switch blocks it or redirects it to your toll carrier, so you might have to use 101-0110 or 101-9017 to circumvent this. Also, HPNA-958/959-xxxx will try to complete from the operator IVR on these same switches, but seems to get a cause code or something back quite quickly. I dunno what this is supposed to reach or if some areas treat it differently than others, but usually you get a recording from the TOPS tandem when you hit something invalid.
  24. There's several numbers nearby, like 752-8055, that go to an ANAC.
  25. It's a very low hanging fruit in terms of exploits; any random script kiddie bot that happens upon it is going to have a hell of a good day. Given how frequently ISP modems are compromised now (for example, one of the Actiontecs where a remote administration interface is permanently stuck on 4567 or 7654 or whatever; I've seen people with these get free, grimly successful security audits) and how little of a say users are able to have in securing them, if you have a minimal, "the ISP just gave me this modem so I hook stuff up to it" configuration, I wouldn't put Audix anywhere near the internet. If you don't want to use a dial-up modem to administer it, you could always use a KVM or something; I'd recommend this more than an isolated ethernet network simply because Audix is designed to use an old version of Netscape to access the web UI from itself. The system runs very old SSL certificates, wants you to execute very old Java applications, and wants you to use a very outdated SSH session to administer it. Security aside, you're going to have trouble finding browsers that want to deal with that. And then you'll have to configure Java to actually execute the administration program it feeds you, unless you can figure out what it's supposed to be running. If I remember right, the Avaya Java SSH thing runs 'exec Fc' after it logs in to access the administration program. Given both the obscurity and how the C-LAN card runs a functionally independent OS (an old build of VxWorks) from the switch, the Definity shouldn't be any trouble so long as you're okay with telnet. I'd still recommend using a modern Linux system with SSH and running the system with minicom. Or a dial-up modem, just because I'm that sort of person. I've detailed in this thread how the VT220 mode can be used with an off the shelf terminal. There are however, undocumented TCP ports open on the card. I doubt your average automated Chinese script kiddie scanner is going to pose a threat to it, but use your own best judgement on that. You're in the wrong place if you think some horrendously bootleg mismatch of hardware running Audix is some sort of hallowed Avaya prayer ground. Or certainly if you don't want to get creative and dirty up your install. Encouraging anyone not to touch it goes completely against everything the hacking spirit stands for, and certainly the spirit of the effort on this thread to turn paperweights into powerful systems again. That being said, if you're going to stick your head in the sand to the tune of a 16-year old Linux kernel, proprietary or otherwise, any very cursory nmap scan will give a very good idea of it's age to someone else. Perhaps you weren't paying attention when it was shown that the license file on these cards is encrypted using DES. With keys that're clearly sitting in the header files that we have no less. Or that the system has absolutely no RAM protection, allows you to read and write to any address you please freely as a higher level user, that we have init access on these releases, and that we know the RAM addresses where the ASG keys sit on the switch. It's certainly an annoyance, I'll grant you. Nobody has approached me offering to help sstep the pam process on the Definity while the license file is being read, and for that reason, my motivation on more computer-oriented projects has been more to wrangle up Dialogic cards into doing sketchy things like scanning. Someday it'll make me really happy to unlock my release 11 Definity card, and certainly help everyone else do the same. For the moment though, most functionality on it works fine, and until I see more initiative to collaborate on this, I don't especially feel like trudging through pages of MIPS instructions. What sort of hardware architecture the system runs on is inconsequential to the licensing routine. You've been repeating lines like this without providing any source or supporting evidence other than friends at Avaya, who're imaginary for all we know. Either you're some sort of Definity troll, or don't know what you're talking about.