Developing.ru

Передо мной стоит задача разработать продукт. Основное предназначение - многопоточный сбор данных с определенного вебресурса.

Сейчас мы работаем на C# и он нас частично устраивает. Есть одна проблема - отсутствие защиты приложения на C# от анализа и взлома.

В продукте планируется следующий принцип защиты. Система будет при каждом запуске продукта запрашивать настройки, необходимые для работы, с сервера по SSL соединению. Это, конечно, усложняет взлом. Однако, догадываюсь, что приложение C# несложно дампировать в рантайме и получить переданные с сервера настройки, чтобы в будущем сделать подложку (которая вместо обращения к серверу сама инициализирует приложение нужными настройками).

Таким образом, решили посмотреть в сторону разработки на C++ . На данный момент мы предъявляем следующие требования к среде разработки:

• Возможность затруднить анализ исходного кода и сделать проблематичным взлом системы лицензирования. При этом, не исключается возможность использования каких либо сторонних платных протекторов. В случае с C# это вряд ли поможет, а вот в случае с C++, скорее всего, сможет значительно усложнить взлом и анализ.
• Трудоемкость реализации не должна быть намного большей, чем в рамках C#.
• Возможность создать код, работающий с оптимальной скоростью (в частности в рамках многопотока). В С# мы реализуем многопоточность с помощью механизма тасков. Альтернативное решение должно работать как минимум не медленнее.
• Возможность работы с большими объемами данных (на ресурсе для парсинга более 10 млн страниц).
• Сделать качественный визуальный интерфейс. При этом скорость создания и корректировки должна не сильно уступать тому, как это делается на DevExpress под C#.
• Программный комлекс должен быть портативным, в частности, работать на диапазоне актуальных версий Windows, начиная с XP, Win7 и так далее (в том числе серверный системы) , а также в рамках 32 и 64-х битной разрядности. В идеале - сделать возможность хотя бы части программного комплекса быть универсальной для работы на любых популярных ОС, как минимум Windows и Mac.

Как вариант, вижу возможность создания программного комплекса из двух приложений. При этом первое будет создано на C# и будет включать в себя интерфейс. Второе будет включать в себя основной движок и систему защиты. Оно может быть создано на C++ в чем-то вроде mono.

Что посоветуете вы? Какую платформу для разработки выбрать? Как лучше скомбинировать части моего программного комплекса, чтобы добиться полного или почти полного соответствия предъявляемым требованиям.

Ну, что то вы, в основном, в сторону защиты смотрите. Люди, которые могут сделать реверс-инжениринг исполняемого .NET кода (С#) с такой же легкостью сделают реверс любого другого приложения. Разве что набор инструкций будет другой и их количество.
Защитить смогут какие нибудь пакеры/энкодеры exe-файлов, обфускаторы, причем желательно дешифрующие код "на-лету" и желательно небольшими порциями. Тогда да, трудоемкость взлома повысится и, возможно, кому то станет влом этим заниматься. Просто имейте ввиду, что взламывается все что угодно - это лишь вопрос того, насколько влом будет этим заниматься хакеру/программисту/реверс-инженеру. Вам лишь достаточно обеспечить защиту от ламеров, то есть людей, чьих знаний хватит максимум на бинарный патч файла.

Возможность создать код, работающий с оптимальной скоростью (в частности в рамках многопотока). В С# мы реализуем многопоточность с помощью механизма тасков. Альтернативное решение должно работать как минимум не медленнее.

Господа, на любой платформе и языке программирования можно создать код, работающий с оптимальной скоростью. Даже на C# можно видеокодек написать, который будет FullHD видео на лету кодировать. Скорость работы приложения, как фактор, на 90% зависит от программиста. Если вас не устраивает скорость работы каких либо узлов - меняйте программиста, а не платформу. Не, ну если ваши парни не отличают передачу параметров по ссылке от прямого копирования, например... какой код они вам напишут?

Возможность работы с большими объемами данных (на ресурсе для парсинга более 10 млн страниц)

Априори, получение пакета данных с сервера в 99% случаях более затратная по времени операция, чем парсинг. Так что эти требования скорее к обеспечению качества интернет-соединения, нежели к платформе.
Советую не парится и писать дальше на C#, потому как вашим требованиям он соответствует. Лучше потом отдельно стражника (guard-процесс) создадите. Он будет висеть в службах (или будет частью драйвера) и перехватывать системные вызовы ZwOpenProcess и им подобных, смотреть к какому процессу и кто ломится. Если трогают наш процесс, то вызывающий процесс надо убить. Ну или просто не дать дескриптор нашего процесса - это отсеет большинство "ломающих"

Сам движок поискового робота лучше вообще разместить на удалённом веб-сервере, чем держать его на локальной машине. Тогда и доступ к нему для посторонних будет существенно ограничен. Если веб-сервер работает на платформе Linux или Unix, то для реализации поискового робота лучше использовать Java, PHP, Python и другие языки программирования. Отдельные модули можно и на С++ написать. Ну а для создания консоли управления сервисом можно использовать и веб-интерфейс, т.е. HTML + JavaScript. Можно конечно и на С# сделать визуальную часть.

Сам движок поискового робота лучше вообще разместить на удалённом веб-сервере, чем держать его на локальной машине.

В требованиях заявлено, что "Программный комлекс должен быть портативным..." - лично я понимаю это заявление, как возможность запустить несколько экземпляров откуда угодно и сколько угодно. Недостаток веб-сервера в том, что он всего один. Какой бы мощный он не был, всегда быстрее будет запустить штук 8 клиентов на разных машинах и складировать результаты скана в общедоступную БД. Особенно хорошо это будет работать, если такая фильтрация данных избирательна. То есть объем данных на выходе много меньше данных на входе. Использование общей БД дает также возможность распараллелить нагрузку между станциями, чтобы каждая из них сканировала свой участок требуемого ресурса.
Получается такой маленький бот-нет. Тут главное канал "атакуемого" ресурса не просадить)