Мы с коллегой работали так: завели ветку dev - в нее мержили те feature, что запланированы на следующий релиз. В случае конфликтов мы садились у одного монитора и разрешали конфликты локальным merge, а после коммитили.
Проектировщики самолетов прячут рычаг катапультирования в кабине пилота так, чтобы пилот случайно его не зацепил. Флаг --force - тот же рычаг катапультирования - дергать без нужды не стоит :)
Команды на удаление или перезапись - всегда риск. Удаленный репозиторий у вас один, берегите его.
Цель создания программы - чтобы она работала - в этом вы правы. Заказчика не волнует, как написан код - хоть иероглифами. Заказчик решает свои проблемы - торгует обувью, разводит рыб, управляет гостиницей.
Программисты сопровождают написанный код. Каждый программист хочет легко понять код, даже если он его не писал, поэтому тимлид объявляет ряд правил для проекта - code style guide.
Люди понимают друг друга, когда говорят на одном языке. Программисты понимают друг друга, когда пишут на одном языке и в одном стиле. Музыканты собирают оркестр и играют симфонию, программисты собирают команду и работают над кодом.
Война стилей вредит проекту. Одна из целей код-ревью - следить, чтобы соглашения проекта соблюдали. Заказчик платит деньги не за споры в курилке.
Не можете договориться - наймите тимлида, а по стенам офиса расклейте басню Крылова "Лебедь, щука и рак".
Хотя, судя по написанному, тут уже ничем не поможешь.
Прекрасно понимаю автора статьи - рекомендаций, наставлений много, а в чем польза? 20 лет проб и ошибок, столько стилей опробовано, а толку? Книга А, книга Б, статьи, конференции, видеокурсы... Надоело.
Никогда не поздно учиться. Автор задает вопросы, делает выводы, ищет решение проблемы, делится опытом. Отчаиваться не стоит :)
Поддерживаю - в настройках проекта нужно запрещать коммиты в master.
За push --force в origin предлагаю расстреливать на месте :) Пушим в репозиторий только когда все локально причесали и на 200% уверены.
А внутри своей feature ветки, разработчик вполне имеет право делать хоть десять коммитов с непонятным сообщением
Только до тех пор, пока это его локальная ветка. Репозиторий - не винегрет, а код единого проекта. Дисциплина должна быть как в стиле кода, так и в истории изменений.
Код пишут, чтобы читать. Историю Git пишут, чтобы читать. Через год в вашу фичу полезет другой и проклянет вашу лень.
Отличная идея - добавлять номер задачи в начало сообщения: облегчает чтение, когда веток много. prepare-commit-msg hook автоматически достанет номер задачи из имени ветки и добавит к сообщению, а commit-msg hook умеет бить по рукам за плохие сообщения.
Обратите внимание, где я завершил мысль и о чем говорю. Я пояснил разницу между материальной вещью - машиной - и интеллектуальным произведением - программой.
Вы продали машину - у вас ее больше нет. Вы продали одну копию программы - у вас еще бесконечное число ее копий.
Выпустили одну машину - осчастливили одного потребителя. Написали программу - осчастливили нескольких.
издержки на неудачные проекты
Не это ли называется венчурные инвестиции?;)
Инвестиции в собственное развитие?
А насколько велики ваши потребности? Они адекватны способностям покупателей? Это ведь предприниматель планирует, сколько он хочет заработать и в какие сроки. Что вами движет - личные амбиции, жажда сесть в 911 GTS3 или вам по кайфу оттого, что вы смогли решить сложную задачу и решить проблему других людей, которые вам за это даже заплатили?
наш маленький коммунистический друг
Авторитетом давите?:) Если у вас есть успешные программные проекты, это здорово - я ваш опыт не оспариваю. Между нами нет спора: мир не идеален и у бизнеса масса проблем.
Каково ваше личное мнение - где грань между прибылью и сверхприбылью?:)
Да, если это важно для результата, напишу и операционку. Защита программы - ответственность самого разработчика.
Предположу, что защиту для игр пишут многие человеко-месяцы множество профессионалов по защите. И игры взламывают практически в день публикации.
Давайте на конкретных примерах - какие именно игры, на каких платформах, от какой студии и реально ли у них потеют над защитой. Не потому ли, что люди полагаются на защиту из коробки - protect.dll или steam_api.dll?
Так вы же опытный реверсер, вам ли не знать о недостатках коробочных защит.
Вы потратили ресурсы на сборку одной машины. Вы продаете одну машину. Сборка второй машины требует столько же ресурсов.
Вы потратили деньги и время - написали программу. Вы не несете затрат на копирование программы.
Жадность - когда вы хотите бесконечно тиражировать копии программы и каждую продавать. Жадность - когда вы запрещаете создавать аналоги своей программы, прикрываясь патентами. Людям нужна программа, но правообладатель задирает цену. Что мешает ему раздавать программу за скромную цену или бесплатно, продавая услуги по технической поддержке?
Машину, компьютер, телевизор, клавиатуру, мышку, ботинки, часы, трусы и всё остальное - тоже сам?
Не перегибайте :)
Машины собирают на заводе, код пишут, сидя на стуле пятой точкой.
Выбор за вами. Знаете, как устроена машина, мышка, телевизор - не купите хлам, вас не обманет наклейка "Трусы успеха!". Знаете, как устроена защита - не отдадите деньги за кота в мешке.
Вы спросили, почему не готовые защиты и не open-source, я ответил. Убеждать - не моя работа :)
Если вам интересно, погрузитесь в тему, попробуйте что-то сломать или защитить, почитайте книги по ассемблеру, реверсу, C/C++, компиляторам, статьи на WASM. А, может, вам интересней право - возьмите курс на законодательство в IT. А, может, вам интересны мотивы людей - добро пожаловать в психологию и психопатологию :) Вокруг столько всего интересного. Успехов вам во всех начинаниях :)
Капиталисты видят счетчик загрузок своей программы на торрентах, умножают число загрузок на цену программы и театрально хватаются за сердце, мол, ах, мы недополучили прибыль. Торрент-трекеры расстрелять без права на помилование.
Лоуренс Лессиг в книге «Свободная Культура» поясняет, что качают люди все подряд, потому что могут, потому что любопытно. Закроют торрент - человек найдет другое занятие, а капиталист так и не дождется ни копейки.
Мотив взлома - необязательно прибыль: хакер может проучить жадных капиталистов, у которых нет бесплатной, учебной или дешевой персональной версии программы. Владельцу ПО стоит задуматься.
программа уникальная и дорогая
Корпорации скупают патенты на алгоритмы, душат конкуренцию и творчество - оттого их программы "уникальны".
Мой порог трудоемкости - "столько, сколько потребуется" :) Чем тщательней защищаю секреты, тем крепче сплю. Хочешь сделать хорошо - делай сам.
Можно купить иллюзию безопасности. Когда ломают свежую версию условного AutoMegaSuperProtect 3.5, ломают и ПО, которое им защитили. Для навесных протекторов выходит AutoMegaSuperProtectUnpack 3.5 или руководство по распаковке, для аппаратных защит - эмулятор. Разработчик защиты пустит ваши деньги на разработку AutoMegaSuperProtect 3.6, продаст вам ее снова и... новую версию ждет та же судьба.
Open-source - открытое и бесплатное ПО. Например, UPX - упаковщик, но его задача - не защита ПО, а сжатие файла.
Хорошая защита вплетена в функции программы и неотделима от них. Если хакер пропустит хотя бы одно, сломанная программа будет работать нестабильно или откажет вовсе. Каждую следующую версию программы придется ломать снова.
Программа защищена, когда ломать защиту дороже, чем купить программу.
Статья озаглавлена "Исследуем защиту программ на практике" и задача поставлена "Исследую защитные алгоритмы на практике". Статья решила маленькую часть большой проблемы. Предстоит еще много работы.
Байт-код виртуальной машины - не сложнее x86 ассемблера. ВМ шагает по строке байтов, интерпретирует команды из одного или нескольких байтов и выполняет действия.
string program = "...";
for (char code: program) {
switch (code) {
case 0x1: f1(); break;
case 0x2: f2(); break;
/* ... */
default: /* invalid opcode */
}
}
Изучаем систему команд ВМ и дальше изучаем алгоритм защиты.
I downloaded a crackme but it's password-protected.
The password for the files is "crackmes.one". If it does not work, this is probably because the crackme has been imported from crackmes.de, so use the password "crackmes.de" instead.
Да, но это как повезет :) Можно и в отладчике найти "Invalid password", но, не зная пароля, трудно его заметить. А вдруг пароль - это сообщение "1337ReverseEngineer's crackme, read readme for more information." или его часть?
Строку "Correct key!" не найти, она расшифровывается только перед печатью и зашифровывается снова. То же можно сделать и с паролем, и с "Invalid password".
Авторы языка Си проделали много работы, чтобы избавить программисты не писали на ассемблере :) Многие задачи проще решаются на C++, Python. Даже прошивки микроконтроллеров пишут на Си.
Ассемблер пригодится разработчику трансляторов, драйверов, вирусному аналитику, взломщику и спецу по информационной безопасности. Знание языка ничего не дает, если знание не применяется на практике.
Задача определяет требования: появится цель, под нее найдутся инструменты и знания.
Вы прочли текст, сразу поняли идею, задались вопросами, остались силы написать подробный комментарий :)
Интерес помогает решать сложные задачи. Беда в том, что интерес легко отбить заумными текстами, что с первых страниц сыплют подробностями.
Знатокам скучно читать подробное описание "очевидных" шагов, а непосвященным быстро наскучит продираться сквозь детали. Те и другие бросят чтение после второго абзаца :)
Ассемблер учат и по ходу дизассемблирования: загрузил готовую программу в отладчик и изучай. Учебник по ассемблеру и Intel Software Developers Manual лежат под рукой как справочники.
Мы с коллегой работали так: завели ветку dev - в нее мержили те feature, что запланированы на следующий релиз. В случае конфликтов мы садились у одного монитора и разрешали конфликты локальным merge, а после коммитили.
Проектировщики самолетов прячут рычаг катапультирования в кабине пилота так, чтобы пилот случайно его не зацепил. Флаг --force - тот же рычаг катапультирования - дергать без нужды не стоит :)
Команды на удаление или перезапись - всегда риск. Удаленный репозиторий у вас один, берегите его.
Тема большая и сложная - давайте разбираться :)
Цель создания программы - чтобы она работала - в этом вы правы. Заказчика не волнует, как написан код - хоть иероглифами. Заказчик решает свои проблемы - торгует обувью, разводит рыб, управляет гостиницей.
Программисты сопровождают написанный код. Каждый программист хочет легко понять код, даже если он его не писал, поэтому тимлид объявляет ряд правил для проекта - code style guide.
Люди понимают друг друга, когда говорят на одном языке. Программисты понимают друг друга, когда пишут на одном языке и в одном стиле. Музыканты собирают оркестр и играют симфонию, программисты собирают команду и работают над кодом.
Война стилей вредит проекту. Одна из целей код-ревью - следить, чтобы соглашения проекта соблюдали. Заказчик платит деньги не за споры в курилке.
Не можете договориться - наймите тимлида, а по стенам офиса расклейте басню Крылова "Лебедь, щука и рак".
Прекрасно понимаю автора статьи - рекомендаций, наставлений много, а в чем польза? 20 лет проб и ошибок, столько стилей опробовано, а толку? Книга А, книга Б, статьи, конференции, видеокурсы... Надоело.
Никогда не поздно учиться. Автор задает вопросы, делает выводы, ищет решение проблемы, делится опытом. Отчаиваться не стоит :)
Спасибо за полезную статью.
Поддерживаю - в настройках проекта нужно запрещать коммиты в master.
За push --force в origin предлагаю расстреливать на месте :) Пушим в репозиторий только когда все локально причесали и на 200% уверены.
Только до тех пор, пока это его локальная ветка. Репозиторий - не винегрет, а код единого проекта. Дисциплина должна быть как в стиле кода, так и в истории изменений.
Код пишут, чтобы читать. Историю Git пишут, чтобы читать. Через год в вашу фичу полезет другой и проклянет вашу лень.
Читайте ссылки по запросу git commit message best practices и чистой вам Git-истории :)
8 правил, которые пригодятся при описании Git-коммитов
Отличная идея - добавлять номер задачи в начало сообщения: облегчает чтение, когда веток много. prepare-commit-msg hook автоматически достанет номер задачи из имени ветки и добавит к сообщению, а commit-msg hook умеет бить по рукам за плохие сообщения.
Отрабатываем Git hooks на автоматизации commit message
Так не поручайте защиту программы Unity-программисту - конечно, он будет год и 11 месяцев учиться ;)
Обратите внимание, где я завершил мысль и о чем говорю. Я пояснил разницу между материальной вещью - машиной - и интеллектуальным произведением - программой.
Вы продали машину - у вас ее больше нет. Вы продали одну копию программы - у вас еще бесконечное число ее копий.
Выпустили одну машину - осчастливили одного потребителя. Написали программу - осчастливили нескольких.
Не это ли называется венчурные инвестиции?;)
А насколько велики ваши потребности? Они адекватны способностям покупателей? Это ведь предприниматель планирует, сколько он хочет заработать и в какие сроки. Что вами движет - личные амбиции, жажда сесть в 911 GTS3 или вам по кайфу оттого, что вы смогли решить сложную задачу и решить проблему других людей, которые вам за это даже заплатили?
Авторитетом давите?:) Если у вас есть успешные программные проекты, это здорово - я ваш опыт не оспариваю. Между нами нет спора: мир не идеален и у бизнеса масса проблем.
Каково ваше личное мнение - где грань между прибылью и сверхприбылью?:)
Да, если это важно для результата, напишу и операционку. Защита программы - ответственность самого разработчика.
Давайте на конкретных примерах - какие именно игры, на каких платформах, от какой студии и реально ли у них потеют над защитой. Не потому ли, что люди полагаются на защиту из коробки - protect.dll или steam_api.dll?
Так вы же опытный реверсер, вам ли не знать о недостатках коробочных защит.
Напишу и 2C и 3C, если потребуется :)
Любопытство - это здорово, осваивайте тему :)
Вы подменяете понятия: машина - не программа.
Вы потратили ресурсы на сборку одной машины. Вы продаете одну машину. Сборка второй машины требует столько же ресурсов.
Вы потратили деньги и время - написали программу. Вы не несете затрат на копирование программы.
Жадность - когда вы хотите бесконечно тиражировать копии программы и каждую продавать. Жадность - когда вы запрещаете создавать аналоги своей программы, прикрываясь патентами. Людям нужна программа, но правообладатель задирает цену. Что мешает ему раздавать программу за скромную цену или бесплатно, продавая услуги по технической поддержке?
Не перегибайте :)
Машины собирают на заводе, код пишут, сидя на стуле пятой точкой.
Выбор за вами. Знаете, как устроена машина, мышка, телевизор - не купите хлам, вас не обманет наклейка "Трусы успеха!". Знаете, как устроена защита - не отдадите деньги за кота в мешке.
Вы спросили, почему не готовые защиты и не open-source, я ответил. Убеждать - не моя работа :)
Если вам интересно, погрузитесь в тему, попробуйте что-то сломать или защитить, почитайте книги по ассемблеру, реверсу, C/C++, компиляторам, статьи на WASM. А, может, вам интересней право - возьмите курс на законодательство в IT. А, может, вам интересны мотивы людей - добро пожаловать в психологию и психопатологию :) Вокруг столько всего интересного. Успехов вам во всех начинаниях :)
Борьбе капиталистов с пиратами вечна :)
Капиталисты видят счетчик загрузок своей программы на торрентах, умножают число загрузок на цену программы и театрально хватаются за сердце, мол, ах, мы недополучили прибыль. Торрент-трекеры расстрелять без права на помилование.
Лоуренс Лессиг в книге «Свободная Культура» поясняет, что качают люди все подряд, потому что могут, потому что любопытно. Закроют торрент - человек найдет другое занятие, а капиталист так и не дождется ни копейки.
Мотив взлома - необязательно прибыль: хакер может проучить жадных капиталистов, у которых нет бесплатной, учебной или дешевой персональной версии программы. Владельцу ПО стоит задуматься.
Корпорации скупают патенты на алгоритмы, душат конкуренцию и творчество - оттого их программы "уникальны".
А вот это уже интересней :)
Нашел решение crackme c France Cybersecurity Challenge 2021: ВМ в 5 слоев виртуализации.
https://mrt4ntr4.github.io/FCSC21-CTF-VMV/
Жаль, не нашел сам бинарник.
Еще по теме: Tuts 4 You - Learn to devirtualize x86 code
Мой порог трудоемкости - "столько, сколько потребуется" :) Чем тщательней защищаю секреты, тем крепче сплю. Хочешь сделать хорошо - делай сам.
Можно купить иллюзию безопасности. Когда ломают свежую версию условного AutoMegaSuperProtect 3.5, ломают и ПО, которое им защитили. Для навесных протекторов выходит AutoMegaSuperProtectUnpack 3.5 или руководство по распаковке, для аппаратных защит - эмулятор. Разработчик защиты пустит ваши деньги на разработку AutoMegaSuperProtect 3.6, продаст вам ее снова и... новую версию ждет та же судьба.
Open-source - открытое и бесплатное ПО. Например, UPX - упаковщик, но его задача - не защита ПО, а сжатие файла.
Хорошая защита вплетена в функции программы и неотделима от них. Если хакер пропустит хотя бы одно, сломанная программа будет работать нестабильно или откажет вовсе. Каждую следующую версию программы придется ломать снова.
Программа защищена, когда ломать защиту дороже, чем купить программу.
Статья озаглавлена "Исследуем защиту программ на практике" и задача поставлена "Исследую защитные алгоритмы на практике". Статья решила маленькую часть большой проблемы. Предстоит еще много работы.
Да, вот пример такого crackme на основе виртуальной машины https://habr.com/ru/articles/712290/ .
Байт-код виртуальной машины - не сложнее x86 ассемблера. ВМ шагает по строке байтов, интерпретирует команды из одного или нескольких байтов и выполняет действия.
Изучаем систему команд ВМ и дальше изучаем алгоритм защиты.
(здесь был лишний комментарий)
Да, но это как повезет :) Можно и в отладчике найти "Invalid password", но, не зная пароля, трудно его заметить. А вдруг пароль - это сообщение "1337ReverseEngineer's crackme, read readme for more information." или его часть?
Строку "Correct key!" не найти, она расшифровывается только перед печатью и зашифровывается снова. То же можно сделать и с паролем, и с "Invalid password".
Запросы к поисковику: freeware hex editor, open source hex editor ;) Например, HxD, XVI32.
Авторы языка Си проделали много работы, чтобы избавить программисты не писали на ассемблере :) Многие задачи проще решаются на C++, Python. Даже прошивки микроконтроллеров пишут на Си.
Ассемблер пригодится разработчику трансляторов, драйверов, вирусному аналитику, взломщику и спецу по информационной безопасности. Знание языка ничего не дает, если знание не применяется на практике.
Задача определяет требования: появится цель, под нее найдутся инструменты и знания.
Спасибо за отзыв :) Здорово, что заинтриговало.
Вы прочли текст, сразу поняли идею, задались вопросами, остались силы написать подробный комментарий :)
Интерес помогает решать сложные задачи. Беда в том, что интерес легко отбить заумными текстами, что с первых страниц сыплют подробностями.
Знатокам скучно читать подробное описание "очевидных" шагов, а непосвященным быстро наскучит продираться сквозь детали. Те и другие бросят чтение после второго абзаца :)
Ассемблер учат и по ходу дизассемблирования: загрузил готовую программу в отладчик и изучай. Учебник по ассемблеру и Intel Software Developers Manual лежат под рукой как справочники.
Инструменты: IDA Pro, OllyDbg, ImmDbg, x64dbg.
Не стоит делать этого от имени администратора, мало ли чего в ходе сборки выполняется :)
Есть простой способ подключить googletest к любому проекту:
git submodule add https://github.com/google/googletest.gitа в CMakeLists.txt пишем:
enable_testing()add_subdirectory(googletest)
add_executable(test_app test_main.cpp)
target_link_libraries(test_app gtest_main)
так и собираем всегда свежую версию googletest, и проблем с линковкой не возникнет из-за разных флагов сборки проекта и библиотеки.