Pull to refresh
-5
0
Ростовцев Александр @f1inx

User

Send message
При прослушке эфира, как раз ваши абоненты выделяются как белые вороны по вашему IMSI пулу.

В системе по голосовым и информационным сигнатурам на софтсвичах через, которые проходит весь трафик операторов. Есть проблема только в идентификации A или B, если они вне зоны локального контроля и еще не имеют сигнатур.

Но не в том чтобы поставить на контроль локальный трафик A и B. Несмотря на то что вы искажаете голос проходящий через ваши PSTN и возможно даже смещаете фазу для сбора сессий все равно можно сопоставить декодированные из аудио символьные сигнатуры и не только их.
Скорее противодействия MITM атак. И прослушки эфира устаревшим оборудованием.
Это был вопрос по поводу якобы сложной задачи: «Но как я уже писал, IMSI в нашем случае параметр динамичный, данный пулл выделен общей массой в несколько миллионов, вот и попробуйте выделить нужного или нужных вам абонентов, да ещё и привязать всю ротацию IMSI к одному конкретному абоненту.»
Нужный абонент выделяется посредством анализа локального перехваченного из эфира трафика на использование IMSI из вашего пула.
В случае если эфир недоступен локализуем на основе приближенной геолокации по данным VLR и особенностей поведения при выборе канала для исходящего соединения.
BTW уже давно технически осуществима идентификация абонента по голосу. И судя по тому, что у нас эти решения покупались еще 5-7лет назад это активно используется.
Не получится ли, что все симки генерирующие IMSI из вашего пула автоматом попадают в список целевых абонентов?
Также в теории по закону должна быть привязка IMSI к конкретному резиденту. Т.е. с вас могут затребовать ее законным путем.
Само по себе нарушение СР-симметрии доказано экспериментально в нескольких экспериментах.
Теории объясняющей эти эффекты согласующейся с опытами нету.
Поэтому согласен, что Это вполне возможно не единственная причина преобладания наблюдаемого вещества над антивеществом.
Вот минусующему популярно про сечение реакции и далее по ссылкам: http://elementy.ru/LHC/HEP/measures/cross-section
Вероятность события реакции поглощения фотона частицей зависит в первую очередь от их количества в единице объема, во вторую очередь от распределения энергий фотонов.
Спектральный состав излучения черного тела однозначно соответствует его температуре. Но применять это к периоду инфляции мягко говоря странно. А также считать что спектральный состав фотонов меняется без взаимодействия с веществом тоже мягко говоря странно.

Реликтового излучение возникло через 379 000 лет после Большого Взрыва при первичной рекомбинации уже в горячую эпоху большого взрыва. поэтому его спектр и соответствует излучению черного тела.
В настоящее время большинство физиков согласно с тем, что в результате нарушения СР‑симметрии во Вселенной в первые мгновения эволюции частиц образовалось несколько больше, чем античастиц – примерно одна частица на 10^9 пар частица-античастица. В итоге после аннигиляции осталось небольшое количество частиц.
«Лишняя антиматерия» скорее всего артефакт перевода.
Нет о плотности энергии (т.е. средней энергии на единицу объема).
Средняя энергия не учитывает «плотности упаковки фотонов» (по сути «расстояния» между ними)
Открытая система фотонов не может находиться в термодинамическом равновесии.
Термин «Температура фотонов» «слегка антифизичен» (особенно при отсутствии элементарных частиц с ненулевой массой покоя). Лучше говорить плотность энергии. А фраза температура фотонов уменьшилась вообще ставит меня в тупик.
Это утверждение я как раз и оспаривал.
Ошибки в данных для валидации там, а не в некоректной классификации белковыми системами на валидирующей выборке.
Нанятые индусы при классификации накосячили, или спустя рукова ее делали.

В среднем люди пока ошибаются на порядки реже. Особенно с зашумленными сигналами.

Однако не спорю, что в «некоторых специфических сферических условиях» машинное зрение работает сравнимо или лучше.
Это больше напоминает ошибку других белковых систем, которые делали классификацию для данных валидации, посмотрите сами:
sceneparsing.csail.mit.edu/browse.php/?dirname=validation
В общем причин для паники пока нету.
Сама по себе ошибка порядка 3-5% это ужасно. Это становится, понятно когда начинаешь понимать в чем разница между ложноположительными и ложноотрицательными…
Непонятно чем был обусловлен выбор платформы, неужели только поддержкой Microsoft Windows 10 IOT Core?
Интересно также:
Получилось ли оконечное устройство дешевле аналогичного по наличию соответствующих датчиков и периферии смартфона?
Какова потребляемая мощность?
А работа через кольцевой буфер PACKET SOCKET не требует никаких системных вызовов для получения данных и меток времени (recvmmsg/sendmsg, recv/send, read/write etc). Метки времени могут быть с микросекундной и наносекундной гранулярностью.
Дополнительно можно упоминуть еще два более «древних» механизма получения меток времени, годящиеся для любого протокола:
1. Через ioctl к сокету. struct timeval tv_rcv;

int res = ioctl(s, SIOCGSTAMP, &tv_rcv);

2. Через кольцевой буфер PACKET_SOCKET.
#include

typedef struct {
struct tpacket_hdr tp_h
__attribute__((aligned(TPACKET_ALIGNMENT)));
struct sockaddr_ll s_ll
__attribute__((aligned(TPACKET_ALIGNMENT)));
uint8_t data[0]
__attribute__((aligned(TPACKET_ALIGNMENT)));
} frame_map_hack_t;
/*
XXX volatile attr and invalidate cache ops may be needed in
many cases to access PACKET SOCKET ring buffers, also
keep in mind cache aliasing problems in some platforms
*/
typedef struct {
struct tpacket_hdr tp_h
__attribute__((aligned(TPACKET_ALIGNMENT)));
struct sockaddr_ll s_ll
__attribute__((aligned(TPACKET_ALIGNMENT)));

uint8_t data[CAP_SNAPLEN-sizeof(frame_map_hack_t)]
__attribute__((aligned(TPACKET_ALIGNMENT)));
} rx_ring_cell_t;


volatile rx_ring_cell_t *rc_cur = ps_rbuf;

tv_last.tv_sec = rc_cur->tp_h.tp_sec;
tv_last.tv_usec = rc_cur->tp_h.tp_usec;
В linux нету зарезервированных имен любая utf-8 строка заканчивающаяся терминирующим \0 будет валидным путем к файлу или каталогу.
В корневой fs важно наличие каталога /dev с минимальным набором устройств в противном случае это сильно осложнит работоспособность многих программ (конечно можно обойтись и без него вообще минимально для старта unix достаточно только выполняемого файла init).
BTW то что вы назвали томом в UNIX является блочным устройством.
Думаю что если изменить имя файла или каталога на "." или ".." доступом через блочное устройство и замонтировать fs пропустив проверку целостности то этот файл или каталог можно будет увидеть в списке файлов но никак нельзя будет к нему доступиться (точнее открыть). Соответственно после fsck он будет переименован и попадет в /lost+found каталог содержащей его fs.

В linux любую fs довольно легко сделать только для чтения, также возможно сделать гибридную fs это когда базовая только для чтения а все изменения записываются в другую fs. Также есть стандартные атрибуты монтирования запрещающие запускать любые файлы с fs или создавать файлы устройств, так что спектр защиты средствами fs вполне достаточен.

Тем не менее можно осложнить возможность удалить файлы и каталоги, если их имена сделать в неустановленной локально кодировке тогда многие штатные средства дадут сбой если не удастся сделать биективное отображение имен из fs в кодировку пользователя и обратно, но на уровне API никаких проблем нет. Еще можно создавать несколько миллионов пустых файлов и каталогов (если позволит установленный лимит при создании fs) тогда штатно удалить и найти только что-то с неизвестным именем среди этого будет сложно (правда удалить все достаточно просто).

Более кардинальный подход это создать свою искусственную fs в пространстве пользователя или ядра в которой будут свои нестандартные правила доступа но сначала как минимум потребуется получение прав root. Также можно подменить системные вызовы open,openat итп.
Также альтернативно может иметь место на прдыдущем hop уменьшение на 2 TTL в заголовке пакета и тихий локальный дроп его вследствии достижения 0. Хотя, конечно это много менее вероятный вариант.
Цена контекст свича, в которую входят как минимум следующие факторы: interrupt latency, аппаратная поддержка HT/SMP/NUMA, особенности MMU, доступность управления кэш памятью и ее архитектура, цена обработки исключений, реализации атомарных операций на разных архитектурах существенно отличаются.

OS конечно тоже накладывает дополнительные ограничения например может не использовать большие страницы изза чего больше поток мета информации для поддержки многозадачности и как следстви более долгое переключение между задачами или в случае худшей чем O(1) возможности масштабирования подсистем упираться в это на определенных задачах, неправильно управлять ресурсами, что ведет к низкой эффективности использования их ПО.
Как вы измеряете производительность на каких задачах?
На каких алгоритмах?
Сколько по вашему у X86 регистров?
А у RISC/MISC (ARM/PPC/MIPS/Z/68K/SPARC/ALPHA/PARISC) и на что это влияет?
С какими архитектурами из этих вы знакомы как эксперт? Чем SMP отличается от NUMA? Как на них устроены/реализованы ALU? Cache? MMU? Data reader Data Writer? Атомарные операции? Какие доступны возможности управления этим (cache, mmu, data reader/writer)? Какие операции могут быть условны? И как это влияет на производительность?
Сколько тактов выполняются операции LD/ST, сравнения, условных переходов? Какие возможности SIMD? Какие на них C/C++ ABI? Как ABI влияет на производительность?

Information

Rating
Does not participate
Location
Москва и Московская обл., Россия
Registered
Activity