По поводу прото схем, я более чем согласен, получив расшифрованные байты/пейлоад уже можно многое узнать.
Что у меня вызывает вопросы - как сделать реверс инжениринг для мобильного приложения например (где скорее всего более лайтовые требования к телеметрии и сложнее увидеть подмену)
Мне очень приятно, что есть небезразличные люди, которые готовы вкладываться чтобы наставить на правильный путь :) Советы дельные и могли бы спасти мир, есть еще вводная, которая на дает мне это сделать.
Авторы фреймворка вообще никак не связаны со мной и с моим заказчиком, их философия плюс минус заключается в "дамп не покидает рабочую станцию". Есть другие люди, те, кто использует этим фреймворком для написание софта и они пиклят свое состояние (тут уже появляются и дампятся их собственные сущности). С этими людьми у меня нет возможности контактировать и тем более настроить некий обмен версиями.
Зато есть те, кто пользуется софтом и вот уже их проблемы мне нужно решать (они тоже по факту готовы делиться лишь дампом, но никак не купленым софтом)
Да, хороший комент и нет, проблемы не решены. Про сам фреймоворк это чисто мое оценочное суждение, но сам фреймворк выглядит безопасным с точки зрения, если условные дампы не покидают машину на которой запущены и никто не догадается начать переносить состояние или обмениваться им. Но время идет, требования меняются и теперь эти дампы могут попадать на другие машины и переносить "как есть" уже не устраивает (начиная от необходимости отмодицифровать внутренее состояние и заканчивая неким аудитом содержимого). Плюс условных машин с состояниями многое множество и не всегда есть доступ к исходникам, чтобы полностью загрузить дамп и "честно" распиклить содержимое.
Спасибо за мини-экскурс в пикл, это уже успел раскурить. Обновил вопрос и отпишу тут - моей целью не является "создать формат", уже существует фреймворк который это делает и мне по факту нужно работать с тем, что имею. Пример опять же из обновлений вопрос - `renpy` (или может есть еще, но этот нагуглил первым)
Однако чем больше комитов, тем порой сложнее ребейзить. Иногда выгоднее сделать несколько комитов и чуть позже разбить или объединить их логически. Так и история симпатичнее и откатывать проще :)
Хм, хорошо. Значит чтобы избежать ручного добавления, нужно обращаться к различным сервисам-регистратором, которые будут выступать промежуточным звеном в цепочке root -> <регистратор> -> наш сертификат?
Достаточно будет ли просто добавить у себя на серверах полученные от регистратора сертификаты/ключи, добавить их в конфигурации (например NGINX) или потребуются ещё какие-то действия?
Над нечто похожим думал с пол часа назад, набросал прототипчик (ногами не пинать!)
Думаю процент не так уж и важен, ведь у меня есть цель(сколько нужно) и текущее значение, посчитать не сложно)
Вот только 1 момент мне не очень нравится, если мы завели три ачивки на победы, а после добавили следующую стадию, (для примера было 1, 20 и 50 победа, мы добавили 100) то нужно прогресс последней ачивки как-то выставить на освновании текущих максимальных значений дочерних ачивок.
з.ы вот за пол часа написанный самопальный прототип.
pastebin.com/gLz1t8Qn
Правильно ли я Вас понял, Отдельно хранить инстанс ачивки для каждого пользователя?
Тогда сразу вопрос, как мы будем следить за шкалой какого-то прогресса, например в собирании мурлоков?
Что у меня вызывает вопросы - как сделать реверс инжениринг для мобильного приложения например (где скорее всего более лайтовые требования к телеметрии и сложнее увидеть подмену)