Fre 0826j fr100 1 что это
Fre 0826j fr100 1 что это
Сообщить о поступлении товара
Мощный wifi роутер fr100 1 от Мегафон
Поддерживает технологию MIMO на wifi частотах 2,4 (802.11b/g/n) и 5 (802.11ac) ГГц. Четыре LAN и один WAN Ethernet порта для подключения по проводу на скорости 100 Мбит сек. Роутер fr100 1 работает со всеми провайдерами предоставляющими интернет по протоколам PPPoE, PPtP, L2TP, IPoE. USB 2.0 позволяет подключать внешний накопитель и подключаться к нему в домашней сети по DLNA и SAMBA. К fr100 1 можно подключить принтер по USB или LAN.
Настройка беспроводного маршрутизатора fr100 1
Прошивка на fr100 1 от Мегафон всего одна, альтернативных вариантов пока нет. Модель новая 2020 года, так что прошивки с расширенными возможностями могут еще появится. Следить и обсуждать возможности вай фай роутера fr100 1 можно на форуме 4pda. Настройки маршрутизатора осуществляются через веб интерфейс по ip 192.168.1.1, логин и пароль доступа написаны на стикере megafon fr100 1. Меню полностью русифицировано, что видно на картинке.
На главной странице есть настройки LAN подключения с выбором протоколов, настройки точек доступа wifi 2,4 и 5 ГГц, выделение LAN порта для подключения IPTV приставки для просмотра телевидения. Можно выбрать от одного до четырех портов Ethernet под IPTV, что позволит подключить четыре приставки одновременно. Это важная функция, на wi fi роутерах предлагаемых интернет провайдерами для IP телевидения выделен всего один порт. Настройки доступа к флешки или HDD выбираются так же на главной странице, есть возможность анонимного доступа. Очень простое меню, разберется даже новичек. Для сброса к заводским настройкам есть кнопка reset, восстанавливает значение по умолчанию.
Характеристики и инструкция на ротер fr100 1
Вывод: Основное достоинство — цена мегафон fr100 1, можно использовать как точку доступа. К недостаткам можно отнести малая скорость LAN/WAN портов и отсутствие альтернативных прошивок позволяющих подключить 4g USB модем.
Подробную инструкцию на мегафон fr100 1 можно скачать тут.
Как IPv6 помогает роутеры ломать
Предисловие
Проснулся я сегодня с мыслью, что огромное количество инструкций по настройке NAT советуют использовать строку вида:
Многие понимают проблемы этой конструкции, и советуют добавлять:
Но, зачастую, забывают задать таблице FORWARD действие DROP по умолчанию, или добавить правило REJECT в конец таблицы.
На первый взгляд, вроде бы, все кажется нормальным. Однако, это далеко не так. Дело в том, что если не запретить маршрутизировать трафик из WAN-порта в WAN-порт, кто-нибудь из вашей WAN-сети (предположим, что провайдер садит весь подъезд в одну /24) может маршрутизировать трафик через вас, просто прописав ваш IP в качестве шлюза. Все современные SOHO роутеры это учитывают, а вот неопытный администратор, который делает роутер под обычным linux, может не знать или забыть об этом. В подсети моего провайдера таких роутеров не оказалось, и мой план по захвату мира провалился. Однако, статья совсем не об этом.
Магические двоеточия
Но это нужно далеко не всегда, т.к. обычно удобно, что программа слушает один сокет, а получать соединения может по двум протоколам сразу. Практически во всех дистрибутивах, IPv6-сокеты ведут себя именно так, т.е. bindv6only=0.
fe80 и его друг ff02
Если вы не застряли в 90-х, вы гарантированно сталкивались с IPv6, сами того не зная. Абсолютно во всех современных операционных системах по умолчанию включена поддержка IPv6, а это значит, что на каждый (кроме редких исключений) интерфейс автоматически назначается IPv6 Link-Local адрес, который начинается с fe80::. Более того, в некоторых случаях этот адрес получается просто путем кодирования MAC-адреса.
Казалось бы, найти Link-Local адреса должно быть проблематично, они же все-таки длинные и страшные, но тут нам на помощь приходит мультикаст-диапазон ff02::.
Есть такой классный адрес: ff02::1. Если его попинговать (обязательно с указанием интерфейса, т.к. это Link Local адрес), то откликнутся все компьютеры в сети:
Как мы видим, откликнулось 11 устройств. Кстати, этот адрес очень удобно использовать, если у вас, например, сервер настроен на получение адреса через DHCP, а DHCP упал, или если вы напрямую подключились к порту сервера, а DHCP поднимать не хочется. Вам остается просто зайти по fe80-адресу по ssh.
Если попинговать адрес ff02::2, то откликнутся все IPv6-роутеры в сети. К сожалению, в моем случае таких не было.
Сканируем роутеры
По IPv4 все эти порты закрыты.
Как мы видим, у многих роутеров открыт Telnet, веб-интерфейс и DNS извне по IPv6.
Что же это значит? Все просто — разработчики прошивки роутера просто-напросто забыли про IPv6.
На многих из них были стандартные пароли admin/admin.
На большинстве этих роутеров ip6tables (iptables для IPv6) просто отсутствовал. Разработчики должны были либо вообще отключить поддержку IPv6 в ядре, либо убедиться, что http и telnet демоны слушают 0.0.0.0, а не :: но, по какой-то причине не стали этого делать.
А что, если…?
Если бы на роутере был каким-то образом настроен IPv6, и, соответственно, включена маршрутизация IPv6 пакетов (net.ipv6.conf.all.forwarding=1), а ip6tables либо вообще не настроен, либо настроен неправильно, то можно было бы точно так же, как в случае с IPv4, маршрутизировать пакеты через этот роутер.
Заключение
Некоторым компаниям я уже отправил письма об этих уязвимостях, а некоторым еще не успел. В любом случае, письма будут отправлены всем.
Используйте IPv6, не забывайте о нем.
Вытаскиваем ПО из запароленного микроконтроллера Renesas M16C
Есть у меня знакомый, который занимается ремонтом автомобильного железа. Он как-то принес мне микроконтроллер, выпаянный из блока управления автономного отопителя. Сказал, что его программатор это не берет, а ему хотелось бы иметь возможность переливать прошивки туда-сюда, т.к. блоков много, в железе они часто одинаковые, а вот агрегаты, которыми они управляют отличаются. И вроде и блок есть взамен неисправного, но ПО разное и заменить просто так нельзя. Так как задачка была интересной, решил покопаться. Если тема интересна и вам, прошу под кат.
Подопытным оказался M306N5FCTFP. Это микроконтроллер группы M16C/6N5. Ядро M16C/60 разработано Mitsubishi, а т.к. преемником этой компании по части МК с 2003 года является Renesas, то сейчас эти микроконтроллеры известны именно под этим брендом.
Немного о самом микроконтроллере
Камешек представляет собой 16-разрядный микроконтроллер в 100-выводном QFP корпусе. Ядро имеет 1 МБайт адресного пространства, тактовая частота 20МГц для автомобильного исполнения. Набор периферии так же весьма обширный: два 16-разрядных таймера и возможность генерации 3-фазного ШИМ для управления моторами, всякие UART, SPI, I2C естественно, 2 канала DMA, имеется встроенный CAN2.0B контроллер, а также PLL. На мой взгляд очень неплохо для старичка. Вот обзорная схемка из документации:
Так как моя задача выдрать ПО, то так же весьма интересует память. Данный МК выпускался в двух вариантах: масочном и Flash. Ко мне попал, как выше уже упоминалось, M306N5FCTFP. Про него в описании сказано следующее:
Как вытащить из устройства то, что разработчики втащили
Вполне естественно, что начинать попытки достать что-то из микроконтроллера нужно с изучения механизмов, которые встроены разработчиком чипа для задач программирования памяти. В мануале указано, что производитель любезно разместил в памяти загрузчик, для нужд внутрисхемного программирования устройства.
Как видно из картинки выше, память разбита на 2 части: пользовательская область, и область загрузчика. Во второй как раз с завода залит загрузчик по умолчанию, который умеет писать, читать, стирать пользовательскую память и общается через асинхронный, синхронный, либо CAN-интерфейс. Указано, что он может быть переписан на свой, а может быть и не переписан. В конце концов это легко проверяется попыткой постучаться к стандартному загрузчику хотя-бы через UART… Забегая вперед: производитель отопителя не стал заморачиваться своим загрузчиком, поэтом копать дальше можно в этом направлении. Сразу оговорюсь, что есть еще способ параллельного программирования, но т.к. программатора для этого у меня не было, я не рассматривал этот вариант.
Вход в режим работы загрузчика обеспечивается определенной комбинацией на входах CNVSS, P5_0, P5_5 во время аппаратного сброса. Дальше либо написать свою утилиту для копирования содержимого памяти, либо использовать готовую. Renesas предоставляет свою утилиту, которая называется «M16C Flash Starter», но функция чтения у нее урезана. Она не сохраняет прочитанное на диск, а сравнивает его с файлом с диска. Т.е. по сути это не чтение, а верификация. Однако есть немецкая свободная утилитка с названием M16C-Flasher, которая вычитывать прошивку умеет. В общем начальный инструментарий подобрался.
О защите от считывания
Все бы было совсем просто, если бы в загрузчике не была предусмотрена защита от несанкционированного доступа. Я просто приведу очень вольный перевод из мануала.
Функция проверки идентификатора
Используется в последовательном и CAN режимах обмена. Идентификатор, переданный программатором, сравнивается с идентификатором, записанным во flash памяти. Если идентификаторы не совпадают, команды, отправляемые программатором, не принимаются. Однако, если 4 байта вектора сброса равны FFFFFFFFh, идентификаторы не сравниваются, позволяя всем командам выполняться. Идентификатор — это 7 байт, сохраненных последовательно, начиная с первого байта, по адресам 0FFFDFh, 0FFFE3h, 0FFFEBh, 0FFFEFh, 0FFFF3h, 0FFFF7h, и 0FFFFBh.
Таким образом, чтобы получить доступ к программе, нужно знать заветные 7 байт. Опять же, забегая вперед, я подключился к МК, используя тот же «M16C Flash Starter» и убедился, что комбинации из нулей и FF не проходят и этот вопрос придется как то решать. Здесь сразу же всплыла мысль с атакой по сторонним каналам. Уже начал прикидывать в голове платку, позволяющую измерять ток в цепи питания, но решил, что интернет большой и большинство велосипедов уже изобретено. Вбив несколько поисковых запросов, довольно быстро нашел на hackaday.io проект Serge ‘q3k’ Bazanski, с названием «Reverse engineering Toshiba R100 BIOS». И в рамках этого проекта автор решал по сути точно такую же задачу: добыча встроенного ПО из МК M306K9FCLR. Более того — на тот момент задача им была уже успешно решена. С одной стороны я немного расстроился — интересная загадка разгадана не мной. С другой — задача превратилась из поиска уязвимости, в ее эксплуатацию, что обещало гораздо более скорое решение.
В двух словах, q3k точно по такой же логике начал изучение с анализа потребляемого тока, в этом плане он был в гораздо более выгодных условиях, т.к. у него был ChipWhisperer, этой штукой я до сих пор не обзавелся. Но т.к. его первый зонд для снятия тока потребления оказался неподходящим и вычленить из шумов что-то полезное у него не получилось, он решил попробовать простенькую атаку на время отклика. Дело в том, что загрузчик во время выполнения команды дергает вывод BUSY, чтобы проинформировать хост о том, занят он, или готов выполнять следующую команду. Вот, по предположению q3k, замер времени от передачи последнего бита идентификатора до снятия флага занятости мог послужить источником информации при переборе. При проверке этого предположения перебором первого байта ключа действительно было обнаружено отклонение по времени только в одном случае — когда первый байт был равен FFh. Для удобства измерения времени автор даже замедлил МК, отключив кварцевый резонатор и подав на тактовый вход меандр 666кГц, для упрощения процедуры измерений. После чего идентификатор был успешно подобран и ПО было извлечено.
Первый блин — граблями
Ха! Подумал я… Сейчас я быстренько наклепаю программку к имевшейся у меня STM32VLDiscovery c STM32F100 на борту, которая будет отправлять код и измерять время отклика, а в терминал выплевывать результаты измерений. Т.к. макетная плата с целевым контроллером до этого подключалась к ПК через переходник USB-UART, то, дабы ничего не менять на макетке, работать будем в асинхронном режиме.
Когда при старте загрузчика вход CLK1 притянут к земле, он понимает, что от него хотят асинхронного общения. Собственно потому я его и использовал — подтяжка была уже припаяна и я просто соединил проводами две платы: Discovery и макетку с целевым M306.
Заметка по согласованию уровней:
Т.к. M16 имеет TTL-уровни на выводах, а STM32 — LVTTL (упрощенно, в даташите подробнее), то необходимо согласование уровней. Т.к. это не устройство, которое, как известная батарейка, должно работать, работать и работать, а по сути подключается разок на столе, то с трансляторами уровней я не заморачивался: выходные уровни от STM32 пятивольтовый МК переварил, в смысле 3 вольта как «1» воспринимает, выходы от М16 подаем на 5V tolerant входы STM32 дабы ему не поплохело, а ногу, которая дергает RESET M16 не забываем перевести в режим выхода с открытым стоком. Я вот забыл, и это еще +2ч в копилку упущенного времени.
Этого минимума достаточно, чтобы железки друг друга поняли.
Логика атакующего ПО следующая:
В итоге, для всех значений результаты были идентичны. Полностью идентичны. Тактовая частота таймера у меня была 24Мгц, соответственно разрешение по времени — 41,6 нс. Ну ок, попробовал замедлить целевой МК. Ничего не поменялось. Здесь в голове родился вопрос: что я делаю не так, как это делал q3k? После сравнения разница нашлась: он использует синхронный интерфейс обмена (SPI), а я асинхронный (UART). И где-то вот здесь я обратил внимание на тот момент, который упустил вначале. Даже на схемах подключения для синхронного и асинхронного режимов загрузчика вывод готовности назван по-разному:
В синхронном это «BUSY», в асинхронном это «Monitor». Смотрим в таблицу «Функции выводов в режиме Standart Serial I/O»:
«Семён Семёныч…»
Упущенная вначале мелочь завела не туда. Собственно, если в синхронном режиме это именно флаг занятости загрузчика, то в асинхронном (тот, который serial I/O mode 2) — просто «мигалка» для индикации работы. Возможно вообще аппаратный сигнал готовности приемопередатчика, оттого и удивительная точность его поднятия.
В общем перепаиваем резистор на выводе SCLK с земли на VCC, припаиваем туда провод, цепляем все это к SPI и начинаем сначала…
Успех!
В синхронном режиме все почти так же, только не требуется никакой предварительной процедуры установки соединения, упрощается синхронизация и захват времени можно выполнить точнее. Если бы сразу выбрал этот режим сохранил бы время… Я снова не стал усложнять и измерять время именно от последнего бита, а запускал таймер перед началом передачи последнего байта ключа, т.е. включаем таймер и отправляем в передатчик KEY7 (на скриншоте выше, из логического анализатора, видно расстояние между курсорами. Это и есть отсчитываемый отрезок времени).
Этого оказалось более чем достаточно для успешной идентификации. Вот так выглядит перебор одного байта:
По оси абсцисс у нас количество дискрет счетчика, по оси ординат, соответственно, передаваемое значение ключа. Отношение сигнал/шум такое, что даже никаких фильтров не требуется, прямо как в школе на уроке информатики: находим максимум в массиве и переходим в подбору следующего байта. Первые 6 байт подбираются легко и быстро, чуть сложнее с последним: там просто наглый перебор не проходит, нужен сброс «жертвы» перед каждой попыткой. В итоге на каждую попытку уходит что-то около 400 мс, и перебор идет в худшем случае в районе полутора минут. Но это в худшем. После каждой попытки запрашиваем статус и, как только угадали, останавливаемся. Я вначале вообще просто быстренько ручками перебрал идентификатор, вставляя в excel вывод консоли и строя график, тем более, что это была разовая задача, но уже для статьи решил дописать автоматический перебор, ради красивой консольки…
Конечно, если бы разработчик затер загрузчик (заменил своим), так просто выкрутиться не получилось бы, но в автомобильной электронике частенько МК вообще не закрыты. В частности в блоке управления с другого отопителя, в котором был установлен V850 того же Renesas все решилось подпайкой пары проводов и копированием прошивки штатной утилитой. Это в мире ЭБУ двигателем целые криптовойны. Видимо не нравится производителям явление чип-тюнинга и других видов вмешательства… Хотя это как гонка брони и снаряда — железки круче, дороже, но победителя нет…
Троян использует «режим Бога» Windows, чтобы спрятаться в системе
Как известно, в операционной системе Windows Vista, 7, 8 и 10 есть своеобразная пасхалка — GodMode (режим Бога). Начиная с версии Vista можно создать папку со специфическим именем, которая перенаправляет на настройки Windows или служебные папки, такие как «Панель управления», «Компьютер», «Принтеры» и проч.
Например, если создать на рабочем столе папку с названием GodMode. (вместо GodMode можно указать любые символы), то внутри будут отображаться все настройки, в том числе и те, которые не включены в меню «Панели управления» или «Параметры»: скриншот.
Очень удобная фича для управления настройками в системе и для системного администрирования.
К сожалению, режим Бога используют не только сисадмины, но и авторы вирусов.
Специалисты из антивирусной компании McAfee Labs рассказывают о трояне Dynamer, который использует режим Бога, чтобы скрыться от обнаружения в системе.
Dynamer при установке записывает свои файлы в одну из таких папок внутри %AppData%. В реестре создаётся ключ, который сохраняется после перезагрузки, запуская каждый раз бинарник зловреда.
Таким образом, исполняемый файл нормально запускается по команде из реестра, но вручную зайти в эту папку нельзя: как указано в списке выше, папка <241D7C96-F8BF-4F85-B01F-E2B043341A4B>работает как ярлык на настройки «Подключение к компьютерам и программам на рабочем месте» (RemoteApp and Desktop Connections).
Вот содержимое папки, если открыть её в проводнике.
Более того, авторы трояна добавили к названию папки «com4.», так что Windows считает папку аппаратным устройством. Проводник Windows не может удалить папку с таким названием.
Аналогично, удаление невозможно из консоли.
Нормальные антивирусы обходят этот трюк вирусописателей. Чтобы удалить папку вручную, нужно запустить из консоли следующую команду.
Троян Dynamer впервые обнаружен несколько лет назад, но Microsoft до сих пор считает его «серьёзной угрозой» для пользователей Windows.
Список имён папок (GUID) в режиме Бога для быстрого доступа к отдельным настройкам Windows
Самые богатые биткоин кошельки
Новостной канал блога Telegram @vachevskijru. Подпишись, чтобы не пропустить ничего важного.
Есть сервисы, с помощью которых можно отследить баланс ТОП BTC бумажников. Решил сделать их полный анализ, кому они принадлежат, какая у них история, да и вообще будет полезно узнать, что сейчас делают крупные игроки. Анализ сделан 16 декабря 2019 года. Посмотреть ТОП 100 адресов в режиме реального времени можно здесь.
Этот бумажник принадлежит бирже Huobi. Биржа работает с 2013 года, имеет свой Huobi Token и является достаточно популярной в Китае. На этом кошельке находится 255 000 BTC. Если посмотреть график пополнения, то видно, что его капитализация за последний месяц увеличилась:
На бумажнике 111,858 BTC, кому он принадлежит, неизвестно. Но его пополнили 2019-10-14 как раз на 111 000 BTC и больше никто никаких операций не совершал.
Если посмотреть график биткоина, то видно, что уже через 10 дней цена увеличилась практически на 30%. Можно сделать вывод, что крупный игрок с помощью этой покупки искусственно повлиял на курс:
Оба бумажника принадлежат бирже Bitfinex, на счету у них 96,963 BTC и 76,893 BTC. Bitfinex также является крупной биржей с большим объемом торгов. Биржа предназначена для профессиональных трейдеров, в ней есть маржинальная торговля, много ордеров и свой токен LEO.
Еще один крупный бумажник, на его счету 94,506 BTC. Его пополнили 2019-09-06 на всю сумму и после этого никто никаких операций не совершал.
3M6UcBNGZAW1HRjiFDMRcY5aXFrQ4F9E1y (89,684BTC) 34xp4vRoCGJym3xR7yCVPFHoCNxv4Twseo (75,323BTC) 3E35SFZkfLMGo4qX5aVs1bBDSnAuGgBH33 (65,077 BTC)
Все три кошелька принадлежат бирже Binance. Крупнейшая биржа криптовалют, где есть маржинальная и фьючерсная торговля, можно зарабатывать на стейкинге и лендинге криптовалют, есть свой токен Binance Coin, а недавно еще и фиатные деньги подключили.
Баланс кошелька 85,947 BTC. Пополнили его 2018-07-01 и после этого никакие транзакции не совершали, хотя курс с того времени хорошо подрос.
На кошельке находиться 69,471 BTC, все монеты были куплены 2013-04-10. Но в 2015 году владелец продал 101 BTC и вернул свои вложенные средства. Остальные монеты продолжает хранить на кошельке, ждет еще большего роста курса.
На балансе 54,687 BTC, монеты были куплены 4 дня назад 2019-12-12, зашел крупный инвестор, наверное, надеется на рост курса в 2020 году.
На балансе 53,880 BTC, все монеты купили 2014-05-28, с того времени никакой активности, здесь, опять же, или доступ потеряли или ждут туземун.
Горе инвестор, который зашел на самом пике, купил монеты в начале 2018 года по 14 000$. На его балансе сейчас 51,830 BTC, с момента покупки прошло уже 2 года, а он ни одной монеты еще не продал. Хотя это и не странно, сейчас продавать себе в убыток.
Еще один крупный игрок зашел месяц назад (2019-11-24), купил 44,000 BTC.
Заключение
Несмотря на то, что сейчас многие говорят о том, что майнеры обрушат курс в 2020 году, что нас ждет дальнейшее снижение, крупные игроки продолжают закупаться, или если уже закупились, то не продают биткоин. Рано или поздно наступит туземун, важно дождаться того момента, не поддаваться панике и тогда только самые терпеливые люди станут богатыми.