Давайте в общих чертах рассмотрим вопросы взлома и защиты Android-приложений. 

В рамках статьи нас интересуют сами процессы взлома и защиты, а не конкретные методики работы с конкретными инструментами. Поэтому разберёмся с этими процессами и постараемся сделать выводы. Чтобы читать было интереснее, я решил попеременно ставить себя и на место нападающего, и на место защищающего приложение человека. Что-то вроде шахмат: сначала ход делает нападающий, а затем защищающийся. Пока кто-то не победит. Пройдём путь, постепенно наращивая сложность, от простого вроде HTTPS — к более сложному, вроде обфускации и деобфускации, изменению поведения. И под конец перейдём к C++ и просмотру его Assembler кода.

Как же мы иногда любим раздавать ценные советы, когда нас об этом просят и особенно — когда не просят! При этом сами почему-то с завидным постоянством принимаем неверные решения и попадаем в глупейшие ситуации.

Почему, например, даже образованные разумные люди нередко поддаются на классические схемы очередных мошенников, верят заманчивым рекламным обещаниям, участвуют в сомнительных конкурсах или, скажем, выкатывают непротестированную сборку прямо в прод?

Раз уж мы так любим раздавать ценные советы другим, почему бы этим не воспользоваться? Попробуем представить, что проблема, которую нам нужно решить, не наша собственная, а чья-то ещё.

Давным-давно, в далекой-далекой галактике, жил да был старший разработчик, который считал себя незаменимым. А работал он в одной и той же компании со дня ее основания. Он разработал архитектуру главного веб-приложения и с нуля создал всю корпоративную инфраструктуру. При нём сменилось пять CTO, компания мигрировала с AWS на Azure и обратно. Он исправил бесчисленное количество багов и привел в компанию порядка 10 новых разработчиков. Работал он днями и ночами, чтобы система, не дай Бог, не вышла из строя. А еще он никогда не уходил в отпуск.

И вот однажды наш разработчик заболел. Да еще как! Ему пришлось взять отпуск на целый месяц, к тому же руководство запретило ему любое общение с компанией и коллегами. Сидя в заслуженном отпуске, разработчик продолжал тревожиться о судьбе компании, и когда пришло время вернуться в офис, он ожидал, что там воцарился хаос, всё сломалось, сгорело и вообще — без него не работает. И наш разработчик был крайне поражен, когда узнал, что всё в порядке и работает не хуже, чем раньше. А кое-где даже стало чуть-чуть получше. Он-то думал, что за долгие годы стал незаменим. Но оказалось, что мнимая незаменимость — всего лишь плод его воображения. Легенда, миф. Бабушкина сказка...

Как вам преподавали квадратные уравнения в школе? Это был 7-8 класс, примерно. Вероятнее всего, вам рассказали что есть формулы корней через дискриминант, что направление ветвей зависит от старшего коэффициента. Через пару занятий дали теорему Виета. Счастливчикам еще рассказали про метод переброски. И на этом решили отпустить.

Эта статья является переводом материала «Immutable architecture».

В этом посте автор оригинала хотел бы показать общий подход к внедрению иммутабельности в кодовую базу на архитектурном уровне.

Прежде всего, термин «Иммутабельность», применяемый к структуре данных, такой как класс, означает, что объекты этого класса не могут изменяться в течение их жизненного цикла. Существует несколько типов иммутабельности со своими нюансами, но это не являются для нас существенным. По большей части мы можем сказать, что класс является либо изменяемым, что означает, что его экземпляры могут изменяться тем или иным образом, либо иммутабельным (неизменяемым), что означает, что как только мы создадим экземпляр этого класса, мы не сможем изменить его позже.

Две леммы о разрастании — утверждения, использующиеся для доказательства ограниченности важных классов формальных языков: регулярных и контекстно-свободных. Важность этих классов для программистов понять легко: регулярные выражения (один из видов описания регулярных языков) в работе используются достаточно часто, а уж языки программирования, синтаксис которых описывается контекстно-свободными грамматиками, и подавно.

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

План такой: разбираемся, что такое регулярные языки и какова связь между регулярными выражениями и конечными автоматами, формулируем и доказываем лемму о разрастании для регулярных языков, используем её для доказательства нерегулярности нескольких языков. Затем похожий трюк проделываем с контекстно-свободными языками, по пути выясняя, как они связаны с регулярными языками и как обходить обнаруженные ограничения при помощи грамматик общего вида. Поехали!

КДПВ иллюстрирует процесс разрастания для КС-грамматик

Почему видеоролики нравятся людям и как они помогают бизнесу

— Добрый день! Почём мороженое?
— Вот же ценник!

Привет, я все еще Марко и все еще системный программист в Badoo. На прошлой неделе я опубликовал перевод о PIC в шареных библиотеках, но есть вторая часть – про разделяемые библиотеки на х64, поэтому решил не оставлять дело незаконченным.