Обнаружение подделки Java JAR/кода

Я пишу часть программного обеспечения, которое распространяется в виде файла JAR. В настоящее время этот файл JAR можно подделать, чтобы получить и сохранить другой файл, который наш сервер передает через URLClassLoader, декомпилировать и найти в нашем коде различные вещи, которые должны оставаться закрытыми для безопасности клиентов, использующих его. По сути, я хочу реализовать способ проверки того, не подделан ли исходный JAR. Я знаю, что это парадоксально невозможно, реализуя проверку правильности SignedObject в исходном классе из-за того, что природа Java может быть декомпилирована, но есть ли какой-то другой способ, которым я могу определить, был ли код подделан в исходном файл? Эта проверка может выполняться через промежуточный класс, который загружается для проверки правильности, или любым другим способом, который гарантированно будет работать. Я сижу здесь весь день, пытаясь придумать решение этой проблемы. Любая помощь приветствуется.


person Clay Freeman    schedule 17.07.2013    source источник
comment
Единственное, что я могу придумать, это использовать какой-то хэш файла (MD5), который сообщит, был ли изменен файл Jar (т.е. добавлен, удален или изменен, но не если он начал открываться). Вы можете хранить эту информацию где-нибудь на сервере. Когда Jar должен быть загружен, вы можете проверить сервер, чтобы определить, соответствует ли MD5 (не запрашивайте его с сервера, отправьте его на сервер). Срок действия Jar также истекает, поэтому его нужно будет повторно загрузить через некоторое время...   -  person MadProgrammer    schedule 18.07.2013
comment
Я вижу в этом проблему. Исходный JAR можно изменить, чтобы сохранить загруженный JAR, посмотреть, как выполняются проверки, а затем перекомпилировать его, чтобы игнорировать проверки на достоверность, и мы снова в той же лодке.   -  person Clay Freeman    schedule 18.07.2013
comment
Когда ваше приложение загружает Jar, оно должно выполнять проверку. Да, на каком-то уровне его можно сломать, но это большая работа для нетехнических людей. Если Jar отвечает базе (т. е. запрашивает данные с сервера), он также может передать ключ, срок действия которого может истечь в будущем, что потребует загрузки нового Jar (с новым ключом). Если вы сами загружаете Jar, вы можете зашифровать Jar/классы   -  person MadProgrammer    schedule 18.07.2013
comment
Ключ может быть скомпрометирован и отправлен на сервер статически из модифицированного JAR-файла. Это должно быть невозможно обойти. Меня не волнует, что обычный деревенщина не сможет сломать валидацию.   -  person Clay Freeman    schedule 18.07.2013
comment
Да, все, что вы делаете, может быть скомпрометировано, так что вы собираетесь делать. Отключиться от интернета? Вы можете просто запустить приложение как веб-приложение, но есть способы взломать их. Как вы сказали, вы никогда не найдете абсолютного решения.   -  person MadProgrammer    schedule 18.07.2013


Ответы (1)


Это теоретически и практически невозможно. Проверка банок происходит на стороне клиента. Никакая криптография не представлена ​​вам в проверяемом виде, и вы верите, что клиент предлагает любую криптографию.

Даже если вы запросите произвольные байты из самого jar-файла для проверки, злонамеренный пользователь может настроить байты, которые будут взяты из хорошего jar-файла, но представлены плохим кодом.

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

Короче говоря, наличие правильных данных не означает их эксклюзивного присутствия.

person nanofarad    schedule 18.07.2013
comment
Я обнаружил то же самое. В итоге я использовал сокет для доставки JAR, когда запускаю его доставку вручную. Это не лучшее решение, но пока оно работает. - person Clay Freeman; 18.07.2013