Как я могу удостовериться, что кто-то не отправляет поддельные данные?

Мы использовали аппаратное решение для обеспечения этой необходимой функциональности.

Я работал с продуктом под названием IronKey, это аппаратное устройство, способное генерировать цифровые подписи. Когда мы выпускаем устройство, мы храним открытый ключ на нашем сервере. когда наше клиентское приложение отправляет данные, мы генерируем подпись с использованием закрытого ключа, как только мы получаем данные, мы можем проверить, что они были отправлены от правильного клиента с использованием открытого ключа.

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

На практике обфускация будет мешать атакующим до определенного момента. Этот момент определяется качеством обфускации и мотивацией атакующего. Таким образом, ответ на второй вопрос зависит от того, кто является атакующим, насколько он способен и какие ресурсы он может применить для решения этой проблемы. Обфускация, которая для немотивированного непрофессионала является "адской/близкой к невозможности", может быть тривиальной для эксперта или того, кто может нанять эксперта.

Вот список некоторых обфускаторов C#.

1.Другой подход: Предполагая, что вы не часто меняете свой исполняемый файл. сделайте DigSig образа исполняемого файла вашего клиента (HASH+Encrypt) и отправьте его вместе с, что позволит аутентифицировать вашего клиента как настоящего клиента, а не модифицированную версию.

Но это не может предотвратить отправку данных совершенно другим клиентом, который может получить Digsig вашего исполняемого образа.

Как однажды выразился Раф Костер , описывая битву с хакерами в онлайн-играх клиент-сервер,

Никогда не доверяйте клиенту. Никогда ничего не кладите на клиента. Клиент находится в руках врага. Никогда не забывай об этом.

К сожалению, практически для любого реального приложения, которое требует использования вычислительной мощности клиента, что-то должно быть помещено на клиент, и, следовательно, доступно злоумышленнику. Вопрос, который необходимо задать - как и в случае любой меры безопасности - заключается в том, сколько времени и денег вы готовы потратить на снижение этого риска?

Некоторые люди любят указывать людям, спрашивающим о механизмах запутывания или лицензирования на стороне клиента: «нет смысла, рано или поздно он сломается». Но здесь упускается из виду главное: цель таких мер - подтолкнуть это «в конечном итоге» еще дальше в будущее до такой степени, что для недостаточно решительного злоумышленника это будет «никогда».

Например: если ваше приложение отправляет свои данные по электронной почте в виде обычного текста, это поможет победить примерно ноль злоумышленников. Отправив его по электронной почте rot13, можно победить, возможно, 5% злоумышленников. Отправка его в зашифрованном виде с использованием имени пользователя в качестве ключа приведет к поражению большего. Обфускация кода отправки с помощью бесплатного обфускатора победит больше. Обфускация с помощью обфускатора коммерческого уровня победит больше. Требование, чтобы у каждого клиента был аппаратный ключ, победило бы «всех, кроме самых решительных» злоумышленников, как люди любят говорить, но это, вероятно, будет недопустимой ценой.

Из «Я студент университета», полагаю, это не самый деликатный проект. Используйте бесплатный обфускатор и зашифруйте отправленные данные, используя в качестве ключа некоторую пользовательскую информацию. Скорее всего, подойдет.

Это кажется довольно безнадежным. Ваш трекер, вероятно, полагается на Windows для предоставления метрик, например, путем вызова GetUserName () / GetTickCount () / CollectPerformanceData () / и т. Д. Итак, плохой парень просто должен перехватить ваш код (независимо от того, насколько он запутан и не беспокоясь о декомпиляции) в любой интересующей точке входа Windows, подставить поддельные данные и позволить вашему коду продолжать свой веселый путь.

Жизнь слишком коротка, чтобы биться головой о такие кирпичные стены.

Будет ли пользователь клиента иметь права администратора компьютера? Это похоже на приложение, которое будет установлено администратором, но используется пользователями, не являющиеся администраторами. Если это так, возможно, вы могли бы сохранить свой ключ или хэш защищенным от обычных пользователей и запустить приложение в контексте пользователя администратора. Я не очень знаком с хранилищем ключей, но я ожидаю, что все версии Windows (по крайней мере, XP +) будут иметь эту функциональность. Если не хранилище ключей, то, возможно, файл, расположенный в зашифрованном каталоге, принадлежащем пользователю admin.

Если ваш целевой пользователь имеет права локального администратора, то я действительно не вижу, как вы можете их остановить.