Comments 78
Никто не в курсе, они API уже открыли? Я лично видел целую систему IVR одного банка, но так и не нашел как это сделали (неужели такими же методами как в статье?)
Нет, не открыли. И не собираются, насколько я могу судить.
Скорее всего использовали готовую библиотеку, либо обратились к специалистам.
Скорее всего использовали готовую библиотеку, либо обратились к специалистам.
Да как раз обьявили что-то такое- blog.whatsapp.com/10000633/Building-for-People-and-Now-Businesses
Оно конечно может слегка не по теме, но может кто нибудь понимает — почему в web.whatsapp (и помоему десктопной) нельзя просто так взять и добавить человека в список контактов?
Кому вообще это может быть удобно — даже для того чтобы 1 раз отправить сообщение человеку, нужно взять телефон и ручками забить номер в телефонный список контактов.
Тут какие то архитектурные ограничения или жирный пробел юзабилити?
Кому вообще это может быть удобно — даже для того чтобы 1 раз отправить сообщение человеку, нужно взять телефон и ручками забить номер в телефонный список контактов.
Тут какие то архитектурные ограничения или жирный пробел юзабилити?
Пробел в юзабилити. Техническая возможность отправки сообщения пользователю не в контактах — есть. Возможно они так борятся с рассылками.
А может подскажете лайфхак как отправлять пользователю не-в-контактах? Меня просто вымораживает что для того чтобы перекинуться фразой с человеком на ПК нужно обязательно лезть в телефон. А телеграмм многие не умеют
Если прям очень надо, и у вас имеется синхронизация контактов с гугло-аккаунтом, то заходите на google.com/contacts — и там добавляете контакт. Через какое-то время он появляется в телефоне, об этом узнаёт Whatsapp и вот он уже есть у вас в списке контактов.
Я говорю про техническую возможность — протокол поддерживает, если вы программно отправите — всё сработает.
Там есть отдельный запрос на обмен ключами сквозного шифрования и, соответственно, следующим запросом вы уже можете отправить ему сообщение. Т.е. без запроса синхронизации контактов.
Я не знаю как это сделать в рамках интерфейса.
Там есть отдельный запрос на обмен ключами сквозного шифрования и, соответственно, следующим запросом вы уже можете отправить ему сообщение. Т.е. без запроса синхронизации контактов.
Я не знаю как это сделать в рамках интерфейса.
Можно открыть чат с любым номером по ссылке
faq.whatsapp.com/en/android/26000030/?category=5245251
faq.whatsapp.com/en/android/26000030/?category=5245251
Так вотсап — один большой пробел в юзабилити. А заодно в энергосбережении.
Не понимаю почему вас заминусовали.
Не удобно ни файлы пересылать, ни общаться.
Файлы каждый раз пересылаются, тратя трафик.
На несколько устройств не поставить.
Клиентов под операционки нет.
Продолжать не хочется перечислять минусы этого недомессенджера.
Не удобно ни файлы пересылать, ни общаться.
Файлы каждый раз пересылаются, тратя трафик.
На несколько устройств не поставить.
Клиентов под операционки нет.
Продолжать не хочется перечислять минусы этого недомессенджера.
К сожалению в текущих реалиях мало шансов, что у нас будет альтернатива.
Под телеграмм уже греют воду в котле, вотсап крайне популярен, вайбер имеет те же недостатки + просто огромное количество спама! Просто помойка. Других популярных альтернатив нет
Под телеграмм уже греют воду в котле, вотсап крайне популярен, вайбер имеет те же недостатки + просто огромное количество спама! Просто помойка. Других популярных альтернатив нет
> Клиентов под операционки нет.
Под осх и винду нативные клиенты есть. Правда, они требуют телефон «в поле зрения», как и веб-клиент.
Под осх и винду нативные клиенты есть. Правда, они требуют телефон «в поле зрения», как и веб-клиент.
Я вам такой «нативный» клиент за две минуты сделаю из любого сайта с помощью FireWork.
С точки зрения протокола при отправке мультимедиа — файл загружается на сервер и передаётся только ссылка. Причём протокол не запрещает переиспользовать ссылку и это даже корректно работает.
Вопрос пересылки файлов — исключительно интерфейсный, — они могут в любой момент начать пересылать ссылку, стоит только захотеть.
Чем обусловлено такое решение, — действительно не очень понятно.
Вопрос пересылки файлов — исключительно интерфейсный, — они могут в любой момент начать пересылать ссылку, стоит только захотеть.
Чем обусловлено такое решение, — действительно не очень понятно.
В интернете встречал статьи, где такая возможность описана. Ну то есть в каких-то старых версиях она была, потом выпилили. Думаю намеренно, чтобы вынудить дать права ко всей телефонной книге.
Да вообще в плане браузерной и десктопной версии мессенджер чрезвычайно убогий. Ладно регистрация с привязкой к телефону, чтоб ботов не наплодить, но блин какого-то хрена нельзя просто брать и пользоваться мессенджером без телефона, ну бред же.
Потому что сообщения хранятся только в телефоне, и, так как несколько активных клиентов не поддерживается, подозреваю, что отправка тоже происходит через телефон. Веб-версия — это просто морда к настоящему клиенту в телефоне (а десктопная — та же самая веб с node.js в комплекте).
UFO just landed and posted this here
История по-умолчанию на Google Drive же складывается, разве нет? Это вам не LINE, где о такой возможности узнаёшь уже когда всё потеряно…
По умолчанию сложно было бы сложить — нужно явное разрешение доступа к Google Drive.
Там сделано по-другому, всплывает незакрываемое окно "выберите куда бэкапить сообщения". И там есть очень неочевидный прикол, на который я и мои друзья попадались: если выбрать "бэкапь на карту памяти" он успешно будет бэкапить, но восстановить можно будет только на этом же телефоне, при смене девайса ключи расшифровки теряются. И можно говорить пока истории.
Причина в умолчальном end-to-end шифровании, возможно. В телеграмме, например, этот функционал задействуется через «секретный чат». И на декстопной версии этой возможности нет. Есть в неофициальном клиенте под линукс telegram-cli. Но при этом это две разных переписки с одним и тем же контактом.
привет, Viber, — получаю спам не реже раза в месяц
Мне спам уже давно не приходит, только "официальный".
А про telegram / viber есть планы написать подобную статью?
У Telegram открытое API вроде? — Проблемы у него будут те же самые, — вся беда от централизации.
В случае Viber всё намного сложнее, — там вся логика зашита в нативный код, так что процесс реверсинга там намного сложнее.
В случае Viber всё намного сложнее, — там вся логика зашита в нативный код, так что процесс реверсинга там намного сложнее.
Есть желание препарировать Discord?
Возможно через год вернёмся к этому вопросу. Пока он нам не интересен.
А почему вам вотсап интересен? Это связано с проф.деятельностью (расскажите подробнее) или увлечение?
Вроде у Telegram приватные чаты децентрализованы?
Поделитесь ссылочкой?
Пробежался через строчку, — не нашел ничего про децентрализацию. Ключи генерируются по DH, хранятся только на клиенте, а работает всё через сервер.
Если сервер скомпрометирован — переписка не будет в безопасности.
Если сервер скомпрометирован — переписка не будет в безопасности.
Т.е. ключи генерируются сервером?
Я просто не понимаю, почему при компрометации сервера будет небезопасно (извините, я не из ИБ)… С DH поверхностно знаком, я не могу понять, что именно тут. Если закрытый ключ все-таки клиентский… Открытый ключ может быть подменен? Спасибо.
В чистом виде алгоритм Диффи-Хеллмана уязвим для модификации данных в канале связи, в том числе для атаки «Человек посередине», поэтому схемы с его использованием применяют дополнительные методы односторонней или двусторонней аутентификации.Википедия.
Для обмена сообщениями в Телеграме вам не нужно дополнительно по независимому каналу передавать какую-либо информацию, т.е. дополнительная аутентификация не используется. Т.е. уязвимо уже по определению.
Соответственно в случае скомпрометированного сервера вы выполните обмен ключами не с пользователем, с которым хотите установить общение, а с сервером, а тот, в свою очередь, выполнит обмен ключами с конечным пользователем. Таким образом вы будете отправлять сообщение, сервер его расшифровывать, читать (умиляться от картинок с котиками), шифровать для конечного пользователя и передавать.
Именно таким образом, кстати, устроен MITM в примере из статьи.
Подобный сценарий возможен как при содействии администрации сервера, так и в следствие хакерской атаки (предположительно очень сложной атаки).
Спасибо! Видимо, примерно это я и представлял под «подменой открытого ключа».
Просто, вроде как, открытый ключ в мессенджерах мы получаем единожды (допустим, до компрометации сервера). И, если мы будем сверять открытый ключ с изначальным, то все описанное Вами остается?
А в статье патчили клиентское ПО, все-таки…
Просто, вроде как, открытый ключ в мессенджерах мы получаем единожды (допустим, до компрометации сервера). И, если мы будем сверять открытый ключ с изначальным, то все описанное Вами остается?
А в статье патчили клиентское ПО, все-таки…
Да, потому что у меня нет закрытого ключа сервера — поэтому необходим был патч. А если скомпрометирован сервер — патчить ничего не нужно…
Ключ мы действительно получаем единожды, но ключ может меняться. Например, если абонент переустановил полностью приложение — ему будет просто неоткуда взять новый ключ.
Соответственно механизм обновления ключа обязательно есть в протоколе. И да, можно отображать время последнего обновления ключа, например. Но широкому пользователю это не будет интересно.
Ключ мы действительно получаем единожды, но ключ может меняться. Например, если абонент переустановил полностью приложение — ему будет просто неоткуда взять новый ключ.
Соответственно механизм обновления ключа обязательно есть в протоколе. И да, можно отображать время последнего обновления ключа, например. Но широкому пользователю это не будет интересно.
В Телеграм нет смены ключа у закрытого чата.
Новый ключ можно получить только явно начав новый чат с тем же абонентом -> Оба абонента будут явно предупреждены о том, что это новый чат с новым ключом и ключ нужно снова сверять…
Т.е. если кто-то получил контроль над сервером уже после начала секретного чата между абонентами, единственный его вариант провести MITM — «убить» секретный чат. В этом случае абоненты попытаются (сознательно) снова установить соединение. Если они при этом не проведут верификацию ключей через сторонний канал — то они попадутся со своими котиками.
Но форсировать незаметную для пользователей перегенрацию ключей нельзя.
Если клиентские части приложения не патчить, конечно.
Новый ключ можно получить только явно начав новый чат с тем же абонентом -> Оба абонента будут явно предупреждены о том, что это новый чат с новым ключом и ключ нужно снова сверять…
Т.е. если кто-то получил контроль над сервером уже после начала секретного чата между абонентами, единственный его вариант провести MITM — «убить» секретный чат. В этом случае абоненты попытаются (сознательно) снова установить соединение. Если они при этом не проведут верификацию ключей через сторонний канал — то они попадутся со своими котиками.
Но форсировать незаметную для пользователей перегенрацию ключей нельзя.
Если клиентские части приложения не патчить, конечно.
Вы путаете end2end с p2p.
Спасибо за статью.
Есть чуток вопросов:
1) Можно поподробнее про момент с certificate pinning, это все же их недосмотр или нет? Другими словами, что бы им следовало «по уму» сделать, чтобы улучшить безопасность?
2) Показалось, что XMPP чем-то не устроил, так ли это, и если да, то почему? :)
3) Почему дискорд не интересен, мало людей или низкая безопасность в целом (нечего ломать типа)?
Есть чуток вопросов:
1) Можно поподробнее про момент с certificate pinning, это все же их недосмотр или нет? Другими словами, что бы им следовало «по уму» сделать, чтобы улучшить безопасность?
2) Показалось, что XMPP чем-то не устроил, так ли это, и если да, то почему? :)
3) Почему дискорд не интересен, мало людей или низкая безопасность в целом (нечего ломать типа)?
1. Нет, закрытие исходников в принципе не повышает безопасность (есть много статей на тему неэффективности security though obscurity). Использование certificate pinning нужно для защиты от прослушки организациями уровня гос. структур.
2. В чистом виде — он кушает много места. В виде FunXMPP он кушает много ресурсов.
3. Мало людей, про безопасность пока ничего сказать не можем.
2. В чистом виде — он кушает много места. В виде FunXMPP он кушает много ресурсов.
3. Мало людей, про безопасность пока ничего сказать не можем.
ИМХО дискорд не мессенджер а скорее конференции, так что людей там то много, но они локализировались по своим конференциям и не пересекаются. Личный пример — дискорд используется вместо окончательно скурвившегося скайпа как конференция-бродкаст (держать толпу друзей, шарить ссылки, собирать желающих по сетке набежать во что-то).
Угу, там даже нельзя тупо добавить незнакомого человека в свой лист. :) Только через конфу.
А Ventrilo чем людей устраивать перестала?.. — Десять лет её пользовался, никаких проблем…
Да как бы та же фигня, что и с остальными — сервер нужен. Причем там еще и лицензия свыше 8 человек, проприетарь, ну его такое. :) Мамбл еще куда ни шло.
А дискач привлек народ агрессивной ХАЛЯВОЙ.
Но не надо думать, что я его защищаю, мне в дискаче нравится только одно — качество звука, чем и завлекли. :) Ну и куча народу там интересного тусуется теперь, переползли коллективами с ирки и жабира.
А дискач привлек народ агрессивной ХАЛЯВОЙ.
Но не надо думать, что я его защищаю, мне в дискаче нравится только одно — качество звука, чем и завлекли. :) Ну и куча народу там интересного тусуется теперь, переползли коллективами с ирки и жабира.
Вентрила — войс, конфа — в первую текстовая. У вентрилы — ограничение 8 человек, необходимость самому сервер хостить. В дискорде же все современные полезности для текстовой конфы — превью линков, катринок, ютуба, возможность линковать картинки из дискорда наружу, форматирование, эмоджи (бессмысленная фигня, но поставить "баклажан" особенно упоротому сообщению — бесценно), можественные войс и чат каналы в пределах одной "конфы", права пользователей.
Кроме конфы для друзей в дискорде рядом живет рейд-конфа вова (20+ человек в войсе), и дискорд позволяет поддерживать полную инфраструктуру для рейда — права пользователей, раздельные чат каналы (для тактик, для анонсов, для рендомного трепа), принудительные пуш-ту-ток каналы.
В общем у дискорда только два больших минуса — отсутствие адаптивного кодека для войса (если проблемы со связью — голос рвет а не падает качеством) и "современная разработка" — со всеми вытекающими последствиями: электрон, упоротые интерфейсы, ресурсожручесть.
Кстати, насчет электрона — есть оплаченная в том году каким-то фанатом разработка плагина под Миранду. :) С зимы его не трогал, но текст уже как-то работал, нет ли подобного опыта, но посвежее?
Про 8 человек никто никогда сильно не заморачивался вроде, — пара байтиков и пользуйтесь… По крайней мере так было раньше.
В остальном, — получается сделали просто удобнее. Молодцы. Принудительный PTT — вообще прекрасно.
В остальном, — получается сделали просто удобнее. Молодцы. Принудительный PTT — вообще прекрасно.
Опять же те-же проблемы современной разработки — в плане интерфейса ПТТ реализован… никак. Тебе выдается мини-предупреждение что с войс активацией этот канал не работает и отключает микрофон — надо самому лезть в настройки и включать ПТТ, а потом — переключать обратно на другом канале. Но судя по их реквесту фич — рано или поздно до ума доведут.
А в Signal тоже самое?
Я правильно понял?
1) Все ключи выдаются сервером вацапа
2) Все сообщения и прочее ходит через сервера вацапа в зашифрованном виде
Если всё это хранить и совмещать, то легко можно расшифровывать переписку или нет?
1) Все ключи выдаются сервером вацапа
2) Все сообщения и прочее ходит через сервера вацапа в зашифрованном виде
Если всё это хранить и совмещать, то легко можно расшифровывать переписку или нет?
Вы про сквозное шифрование, верно? — Нет, неправильно поняли.
Ключи генерируются на устройстве и передаётся через сервер приложения только публичный ключ. Так что в чистом виде администраторы сервера не могут прочитать вашу переписку. Однако у них есть техническая возможность передать вместо ключа собеседника — свой ключ, и таким образом организовать активный MITM.
Т.е. у каждого пользователя, если сильно упростить, есть два ключа: приватный и публичный. Публичный он через сервера приложения передаёт всем своим собеседникам. Когда ему кто-то хочет написать — он шифрует сообщение публичным ключом получателя. Расшифровать публичным ключом невозможно, — расшифровать может только приватный ключ.
Ключи генерируются на устройстве и передаётся через сервер приложения только публичный ключ. Так что в чистом виде администраторы сервера не могут прочитать вашу переписку. Однако у них есть техническая возможность передать вместо ключа собеседника — свой ключ, и таким образом организовать активный MITM.
Т.е. у каждого пользователя, если сильно упростить, есть два ключа: приватный и публичный. Публичный он через сервера приложения передаёт всем своим собеседникам. Когда ему кто-то хочет написать — он шифрует сообщение публичным ключом получателя. Расшифровать публичным ключом невозможно, — расшифровать может только приватный ключ.
Было бы интересно узнать, например, более подробно про авторизацию. Как был среверсен алгоритм генерации ключей (файл keystream.class.php) хотя бы.
У меня нет такого файла. Спросите поточнее, что вы хотите узнать?
Так вот в статье вы ссылаетесь на исходники на github, я полез изучать вызовы, которые делает Login.php, и увидел много магии :)
Вы не в те исходники полезли. Я на два гитхаба ссылаюсь, один Chat-API — ко мне имеет пространное отношение, просто там хорошо описано, а я не стал копипастить (хотя, наверное, стоило?). Второй, — mitm-research, — там всё моё и совсем никакой магии.
К вопросу в целом, как реверсится алгоритм генерации ключей, — там HKDF — он довольно стандартный.
В простом случае открыв приложение в декомпиляторе и найдя нужный фрагмент кода, — увидишь сразу вызов метода «HKDF» с нужными параметрами и реверсить ничего не нужно.
В сложном случае, если библиотека вкомпилена в приложение, а имена обфусцированы, — увидишь вызов непонятной функции. Будешь переименовать переменные, выставлять структуры данных до тех пор пока не поймёшь назначение кода. Поняв что делает код — либо скопируешь его как есть, либо подключишь соответствующую библиотеку.
К вопросу в целом, как реверсится алгоритм генерации ключей, — там HKDF — он довольно стандартный.
В простом случае открыв приложение в декомпиляторе и найдя нужный фрагмент кода, — увидишь сразу вызов метода «HKDF» с нужными параметрами и реверсить ничего не нужно.
В сложном случае, если библиотека вкомпилена в приложение, а имена обфусцированы, — увидишь вызов непонятной функции. Будешь переименовать переменные, выставлять структуры данных до тех пор пока не поймёшь назначение кода. Поняв что делает код — либо скопируешь его как есть, либо подключишь соответствующую библиотеку.
А за 2 года в их протоколе что-нибудь менялось? Миранда свой плагин прекратила поддерживать как раз в конце 2017…
Только незначительные изменения — там всё визуально понятно, протокол текстовый. В статье достаточно информации, чтобы сделать свежий протокол.
Миранда скорее всего отключила плагин из-за принудительного перехода на новое шифрование. Внутри шифрования всё осталось примерно тоже самое. Одновременно с этим многие репозитории закрылись на github, хотя у них всё более/менее было. Возможно их очень попросили.
Миранда скорее всего отключила плагин из-за принудительного перехода на новое шифрование. Внутри шифрования всё осталось примерно тоже самое. Одновременно с этим многие репозитории закрылись на github, хотя у них всё более/менее было. Возможно их очень попросили.
Sign up to leave a comment.
WhatsApp, что внутри?