Как защитить какой то текст в скриптовом языке программирования?

Question

[Luamad]

Здравствуйте! Очень слаб в теме хранения данных безопасно. Суть такова что нужна скрыть пару десятков строк текста от игрока. Что бы он заранее не мог узнать ответа.
И не очень хочется из-за этого делать элементы подключения к веб серверу. Тем более и это особо не спасет.
Проблема в том что использоваться это будет скриптовым языком. В Python или Lua (Love2d).
Вариант сделать какой то бинарник? На компилируемом языке. Не уверен что это спасет, так же как не понимаю как из скриптового языка безопасно получать строку в компилируемом.

Есть идеи по этому поводу? Заранее спасибо.

Answer 1

[Rsa97]

Храните хэш правильного ответа и сравнивайте с хэшем от введённого значения.

Comments

[Luamad]

Никто не вводит ничего. Лишь выбирает из вариантов. Но генерировать хеши. Это довольно интересно. Не плохое предложение.

[PrAw]

Luamad, если делаете тест, который будет выполняться в контролируемом окружении и под присмотром, то скорей всего этого хватит.
Иначе - можно будет отреверсить алгоритм получения хэшей и просто сравнивать - "если этот ответ захэшируем, он будет правильным?"
Так что клиент-сервер в каком бы то ни было виде, чтобы сервер не был в руках хацкера

Answer 2

[Сергей Соколов]

Самое простое – base64 кодирование/декодирование – уже не будет текст читаемым в коде:

import base64

xoxoxo = b'0J/RgNC40LLQtdGCLCDQotC+0YHRgtC10YAh'

decoded = base64.b64decode(xoxoxo).decode('utf-8')
# Привет, Тостер!

Как «шифровать»

>>> source = 'Привет, Тостер!'
>>> bytes = source.encode('utf-8')
>>> xoxoxo = base64.b64encode(bytes)

Answer 3

[Александр]

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

>>> text = "encoded message"
>>> E = " ,.?!@#$%^&*()"+"".join([chr(x)for x in list(range(ord('A'),ord('Z')+1))+list(range(ord('a'),ord('z')+1))])
>>> E
' ,.?!@#$%^&*()ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz'
>>> encoded_text = "+".join(["E[%d]"%E.index(t) for t in text])
>>> encoded_text
'E[44]+E[53]+E[42]+E[54]+E[43]+E[44]+E[43]+E[0]+E[52]+E[44]+E[58]+E[58]+E[40]+E[46]+E[44]'
>>> eval(encoded_text)
'encoded message'
>>>

тоесть в коде вы пишите:

E = ' ,.?!@#$%^&*()ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz'
text1=E[44]+E[53]+E[42]+E[54]+E[43]+E[44]+E[43]+E[0]+E[52]+E[44]+E[58]+E[58]+E[40]+E[46]+E[44]
text2=E[23]+E[60]+E[58]+E[59]+E[0]+E[45]+E[54]+E[57]+E[0]+E[33]+E[18]+E[32]+E[33]+E[0]+E[64]+E[54]+E[60]+E[0]+E[52]+E[48]+E[53]+E[43]+E[4]

Практика достаточно распространенная когда хранятся пароли и прочее в коде.
А еще в качестве словаря можно использовать произвольный текст.

Comments

[Andrey Dugin]

Практика достаточно распространенная когда хранятся пароли и прочее в коде.

Вы сейчас серьёзно?

[Александр]

нет конечно, просто встречал минимум 2...3 раза такое в коде.

Answer 4

[sim3x]

Луа компилируется в бинарник
https://stackoverflow.com/questions/194520/creatin...

Питон - компилируется в свой набор комманд

Comments

[Luamad]

Луа декомпилируется так же. + Love2d тогда теряет кросс платформенность. Я уже честно думал об этом.

[sim3x]

Luamad, шашечки или ехать?

Код на сях тоже придется собирать под каждую платформу отдельно

[Luamad]

sim3x, Я думал о Golang. Вопрос встал в общении сокеты или exec. Это то в чем я хоть как то понимаю. Но не уверен что это адекватно. В теории мне подходит вариант отдать запрос, что бы получить запрос и так шаг за шагом. Но повторюсь в этой теме совсем не шарю.

[sim3x]

Luamad,
Я повторю мысль - любой ЯП придется собирать под каждую платформу отдельно

Нет, пошаговую инструкцию я писать не буду

[Luamad]

sim3x, Собирать да. Но с Lua нет кросс компиляции это раз два она так же декомпилируется. Го можно собрать под разные платформы из под окон например. Я спрашиваю способы , а не инструкции. У кого на что смекалки хватает.

[sim3x]

Luamad,
Си также декомпилируется
Кросс-компиляцию поддерживает большая часть тулкитов для ЯП

Answer 5

[Евгений Иванович]

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