We continue to watch Moscow's public video surveillance cameras

    It was evening, there was nothing. The reason was the activity of the user  leider , who gave a link to a public resource in the comment : video.dit.mos.ru/window

    image

    What is remarkable about this resource is that it provides public access to video surveillance cameras through the built-in player .

    image

    In this article there will be no “salt”, no sugar, only healthyfoodlinks directly from the stove.

    The list of links that the player uses on that resource:

    http://videoproxy2.echd.ru:41025/rtsplive/10.200.21.21:2033/rtsp___10.208.1.18_axis_media_media.amp/live
    http://videoproxy2.echd.ru:41025/rtsplive/10.200.21.22:2033/rtsp___10.208.1.186_axis_media_media.amp/live
    http://videoproxy2.echd.ru:41025/rtsplive/10.200.21.22:2033/rtsp___10.208.0.50_axis_media_media.amp/live
    http://videoproxy2.echd.ru:41025/rtsplive/10.200.21.22:2033/rtsp___10.208.41.134_axis_media_media.amp/live
    http://videoproxy2.echd.ru:41025/rtsplive/10.200.21.23:2033/rtsp___10.194.23.9_axis_media_media.amp/live
    http://videoproxy2.echd.ru:41025/rtsplive/10.200.30.24:2033/rtsp___10.208.14.78_axis_media_media.amp_camera_4/live
    http://videoproxy2.echd.ru:41025/rtsplive/10.200.30.33:2033/rtsp___10.208.14.117_axis_media_media.amp_camera_2/live
    http://videoproxy2.echd.ru:41025/rtsplive/10.200.26.150:2033/rtsp___10.232.0.121_live_h264/live
    http://videoproxy2.echd.ru:41025/rtsplive/10.200.26.150:2033/rtsp___10.232.0.1_live_h264/live
    http://videoproxy2.echd.ru:41025/rtsplive/10.200.26.153:2033/rtsp___10.232.0.113_live_h264/live
    

    Turn on the logic of the programmer " looser! ":
    • videoproxy2.echd.ru:41025/rtsplive Is a proxy
    • 10.200.30.33:2033 Is a caching server
    • rtsp___10.208.14.117_axis_media_media.amp_camera_2/live - This is a link to the stream from the camera on the server.


    Working links:
    • videoproxy2.echd.ru:41025/rtsplive/10.200.21.21:2033/rtsp___10.208.1.18_axis_media_media.amp/live
    • videoproxy2.echd.ru:41025/rtsplive/10.200.21.21:2033/rtsp___10.208.1.18_axis_media_media.amp

    Broken links:
    • videoproxy2.echd.ru:41025/rtsplive/10.200.21.21:2033/rtsp___10.208.1.18
    • videoproxy2.echd.ru:41025/rtsplive/10.208.1.18:80
    • videoproxy2.echd.ru:41025/rtsplive/10.208.1.18:81
    • videoproxy2.echd.ru:41025/rtsplive/10.208.1.18:8080
    • videoproxy2.echd.ru:41025/rtsplive/10.208.1.18:8081
    • videoproxy2.echd.ru:41025/rtsplive/10.208.1.18:[пачка_rtsp_портов из wiki, так же 7020 и 27020]


    Search Automation


    Theory:
    • only one proxy ( videoproxy2.echd.ru:41025/rtsplive/ )
    • port of caching servers is unchanged ( : 2033 )
    • ponytail  _axis_media_media.amp / live
    • ponytail  _live_h264 / live

    Next, _camera_4, etc. is not taken into account, since there is "10.200.30.24:2033/rtsp___10.208.14.7 8 _axis_media_media.amp_camera _4 / live" and there is no "10.200.30.24:2033/rtsp___10.208.14.7 7 _axis_media_media.amp_camera _3 / live", but following the logic, there must be "_axis_media_media.amp / live" - ​​this is what we are going to look for.

    IP List for Caching Servers :
    • 10.200.21.21
    • 10.200.21.22
    • 10.200.21.23
    • 10.200.30.24
    • 10.200.30.33
    • 10.200.26.150
    • 10.200.26.153

    Ideally, as a range, you would select  10.200.21.1--10.200.30.254 .

    List of IP addresses for cameras:
    • 10.194.1.7
    • 10.194.23.9
    • 10.208.0.50
    • 10.208.1.186
    • 10.208.14.117
    • 10.208.41.134
    • 10.232.0.113
    • 10.232.0.121

    As a range (again perfect), we take the addresses  10.194.0.1--10.232.255.254 with the exception of  10.200. *. *  , Since by my logic (as I would have done) these are caching servers.

    As a result, here is a template for queries:
    • videoproxy2.echd.ru:41025/rtsplive/10.200.ip13 . ip14 : 2033 / rtsp ___ 10. ip22 . ip23 . ip24 _axis_media_media.amp / live
    • videoproxy2.echd.ru:41025/rtsplive/10.200.ip13 . ip14 : 2033 / rtsp ___ 10. ip22 . ip23 . ip24 _live_h264 / live

     
    • ip13 - 21..30
    • ip14 - 0..254
    • ip22 - 194..232
    • ip23 - 0..255
    • ip24 - 1..254

    We get:  5 billion  addresses and requests ... In reality, there are many fewer requests and we can also save  903k  requests in 10-15 seconds of script downtime ... (more on that below).

    Success:
    • If successful, the server returns us to Content-type  x-flv  or the inverse condition is NOT text ;
    • If successful, the server is responsible for 1-3 seconds.

    Failure:
    • The server is responsible for 200-400ms with text in the  Content-type ;
    • The server thinks for a long time if it sends a request to a "nonexistent" cache server, in this case it is necessary to stop parsing on this server and jump to IP "higher".

    To minimize parsing time, we set the connection timeout equal to 10000 ms, then before the request and after the request (when the server answered or the timeout worked on our client) we save the time value. Then we subtract the first from the second and if 9500ms or more has passed, it goes 1 IP higher (for the caching server), which gives us the above savings of 903,224  requests or 104 days of waiting for 10 seconds!

    You also need to understand that camera links run in circles, and as noted in a previous article, there are about 140,000 cameras . The server calmly sends 10 requests per second, so if we have already found 140,000 cameras, then in the future we do not need to search them again.

    But parsing so many addresses will take forever, and we are not in the matrix yet!

     

    Practice


    Reduce your search:
    • 10.200.21.21-24, cameras 10. [194, 208, 232] .0-255.1-254
    • 10.200.30.21-34, chambers 10. [194, 208, 232] .0-255.1-254
    • 10.200.26.150-153, cameras 10.232.0-255.1-254

    Their proxy quietly processes ~ 10 requests per thread, we try ... 8 threads, 16 threads ... 16 is enough. Total ~ 160 links per second and a stream at the level of 2-3 megabits, which does not load the network.

    The response from the server:

    video / x-flv - this is if we received a stream from the camera through their server, text / html - if an error message. In the program, it is necessary to make a condition not of finding x-flv, but of the absence of  text. Because if the camera is lying, then the server is just stupid and we get nothing, but there is a camera.

    As a result, 608  cameras were found :
    IP.21.23.21.22.21.21.26.150.26.151.30.21.26.152.30.24.26.153.30.23.30.25.21.24.30.22
    number193176171311074433321

    • 540 cameras  _axis_media_media.amp / live
    • 68 cameras  _live_h264 / live

     

    Notifications:
    • On January 27, at noon, a letter was sent to dit @, an hour later, the leider PM to see the mail. The letter described what and how it works.
    • January 28, also at noon - a new letter to dit-video @, where he mentioned that he had already written on dit @ and that there was no answer (each letter indicated that I was waiting for news)

    "News":
    • The camera link given in the example was closed on the 27th ... quietly and silently.

    I hope that after this publication they will introduce a check on  videoproxy2 so that it only gives out cameras from the “window” project. For other cameras / all cameras, you can raise blablaproxy2 , which will not shine anywhere and which will work via https .

    Related links:

    Page with players || dump in mysql format  (description of fields in comments).

    Also popular now: