Золотой ключик. Разбираем на примере принцип создания кейгенов

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

Итак, усло­вие задачи: пред­положим, есть некий набор прос­тых кон­соль­ных ути­лит. В три­аль­ном режиме каж­дая прог­рамма из это­го набора работа­ет с мел­кими, но неп­рият­ными огра­ниче­ниями, одна­ко у нее при­сутс­тву­ет ключ коман­дной стро­ки для вво­да кода акти­вации.

При исполь­зовании клю­ча есть два вари­анта: если код акти­вации неверен, прог­рамма выда­ет стро­ку «Error: Invalid License Key» и завер­шает работу, в про­тив­ном слу­чае отра­баты­вает без огра­ниче­ний. Для наг­ляднос­ти упростим задачу: пред­положим, что прог­рамма ничем не защище­на и не обфусци­рова­на, написа­на на C (про­верить это мож­но в Detect It Easy).

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

Подбор ключа

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