All Activity

This stream auto-updates   

  1. Past hour
  2. Yesterday
  3. Last week
  4. Earlier
  5. Guys, you need to start posting conf number changes in here since there's no more IRC...
  6. If the current issue is to be believed, looks like there were some real shenanigans going on. That's all I'm going to say because beyond that it's apparently political.
  7. Still interested in collaborating with folks from my area... Dallas.
  8. this is hot.
  9. I haven't been able to find it again - but I know it was there... At the top of the page it simply said HACKERNET and then below it said "are you into computers, breaking into them, security, blah blah blah" and then went on to say that a group was being put together for like minded individuals --- send your info and we will make you part of our mailing list... For all I know it was an FBI sting or something.. I was young enough I sent my info (and then got busted in operation sundevil - but I dont think the two were related) but never heard another thing. I like collecting stuff like this... If anyone remembers the ad I would love to hear from you and maybe what mag it was from.. I *WANT* to say it was from "Computer Gamer" and likely around 1986...
  10. 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............
  11. 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..
  12. 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...)
  13. Due to the political crisis in the area you are calling, your call could not be completed at this time. Please wait until the regime has had sufficient time to consolidate its power and try your call again. 095T

  14. The contents of the "Rules, Guidelines and Announcenents" section are required reading for all new users before signing up.

  15. Announcement: As of last week, the unofficial binrev IRC server has been decommissioned. I know that a few people still liked to hang out there, but honestly it just became too much to maintain. As of now, if you see the name "BinRev" or any other reference to the Binary Revolution, StankDawg, the Digital DawgPound, or any other similar reference anywhere out there, be aware that it is not endorsed or approved by us. The simple reason why is because there were a lot of accusations being made about people in our IRC channels. Since no one is actively managing and monitoring that channel, frankly we did not know what is or is not going on on that server. Rumors started, fingers were pointed, things were said that cannot be unsaid. For that reason, I decided that it was best to just shut it down to save everyone's reputation, even if i have no evidence of wrongdoing. I just don't have time for such nonsense. If people just behave better, then I wouldn't have to do this. Look, IRC is the wild west and people get pissed at each other and launch attacks and accusations at each other and that is what ruins reputations. Such is the nature of IRC. I do not want my reputation or the BinRev reputation to be tarnished by false accusations. I do not know who pissed who off or whether someone did or did not do anything. I do not know what is true or what is not true. I do not judge without evidence. All that I know is that bad accusations were made about some IRC users and I don't want any part of it. If people can't play nicely without fighting and accusing people of doing things, then I am tearing down the playground. So whatever rumors are out there about BinRev or me personally (or anyone else for that matter) take that with a grain of salt. Anyone who has been here for any length of time knows the integrity standards that we uphold here and I continue to be disappointed in this community an how badly we attack each other. DON'T BELIEVE EVERYTHING YOU HEAR! Some people just live to start drama. The continued attacks on my integrity, and some of our users integrity, should be something that you should be ashamed of. If people have evidence against INDIVIDUALS and want to present that evidence, then address them individually. But do not assume that we at BinRev approve or are related to any of it. Just because someone hangs out in our forums or our IRC servers or anything for that matter, that they are somehow endorsed or approved by us. We do our best to moderate our systems and we don't always catch everything, especially as shorthanded as we are. So for that reason, the IRC server is going down since we cannot moderate it properly. It is only a matter of time before this site and the forums go down next. Sad but true. My shift is over unless someone picks up the reigns. Will the last person to exit, please turn off the lights.
  16. 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.
  17. 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?
  18. Never reply to spammers. Moderators are highly effective at capturation and bannination of spammers. The most effective thing you as a user can do is select "Report post" next to the time/date stamp in the post header. 99% of spam posts are generated by automated means anyways so replying to them accomplishes nothing.

  19. Hello Everyone, I was active years ago on this thread as t3st.s3t but have long lost my credentials. Here's an Ameritech coin deposit recording I found recently while scanning: 906-226-0000
  20. Still, this is a very interesting idea. I didn't realize strcmp worked that way.
  21. New member, enjoying your forum, thanks!
  22. give second dial tone with 2222
  23. 0051 give second dial tone with 1111
  24. 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.
  25. 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.
  26. 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
  27. Adding another from NANPA - the toll-free (800/877/etc) carrier list and which carriers claims what. 800855_Assignments.pdf
  28. 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`.
  29. 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.
  1. Load more activity