Решил протестировать совместную работу Compositor RTOS 9.0.2 a13 и SNMPc Enterprise от Castle Rock Computing. В программный пакет SNMPc помимо программы сетевого мониторинга входит и сервер, который запускается сразу после загрузки рабочей станции. Так как в моей программной среде функции сервера выполняет Compositor RAD96, то сразу возникает конфликт интересов. После Compositor RAD96 идет загрузка Compositor RTOS 9.0.2, и тут начинается самое интересное. Сконфигурировав интерфейс Compositor RTOS, я могу отправить порядка 700 пакетов, после чего основной интерфейс Compositor AV Extended 2.0 начинает пилотироваться неустановленным сервером. До установки сервера SNMPc такого поведения машина CP-6137-960FX не показывала. Я предпринял попытки перехватить управление интерфейсом Compositor RTOS: включил интерфейс в пассивном режиме, а также активировал скрабберы для ухода с частоты, но пилот SNMPc “присосался” сильно.
После деинсталляции ПО SNMPc Enterprise, я вновь запустил машину в Compositor RTOS со стартапа, но на этот раз раздавал маршрут по умолчанию в TCP протокол из EIGRP протокола. По всей видимости пилот SNMPc был все еще нацелен на мою машину, но ошибся. Он взял вместо интерфейса маршрут RIPng протокола (который раздавал default route в первую совместную сессию с SNMPc сервером) и попытался пилотировать его. Что из этого вышло Вы можете услышать из записи ниже, но следует отметить, что дженериковый протокол RT-z64, который служит RIPng протоколу взял верх.
Как можно судить из записи выше Compositor RTOS 9.0.2 a13 является вполне самодостаточной программой, которая может решать уязвимости самого высокого уровня. А возможность дженерикового протокола RIPng внутри ОСРВ “Композитор” строить маршруты даже во время внешнего пилотирования является отличительной особенностью его строения как закрытой петли 2-го порядка. Это означает, что он может совершать стохастические манипуляции над любыми производными, происходящими в лупе.
