Popular Content

Showing content with the highest reputation since 01/15/2019 in all areas

  1. 3 points
    I've worked on this project for quite a while, and have discussed it on the conference, but have never officially posted recordings on here. There is a large presence of analog and electromechanical switches still in service in the former Soviet countries. The following are 3 recordings of me successfully boxing some of these switches: East Ukraine, ATSK Crossbar Using SF (in-band 2600 dial pulse) Signaling -- seizing and SFing another number: http://technotite.com/SF-exampUKR1.wav West Russia, Crossbar Using SF (in-band 2600 dial pulse) Signaling -- seizing and SFing another number: http://technotite.com/SF-exampRUS1.wav East Ukraine, Crossbar Using R1.5 (weird bi-directional MF protocol using R1 tones, used in CIS countries) - seizing and MFing another number: http://technotite.com/R1.5-examp1.wav
  2. 1 point
    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.