Приветствую.
Буду благодарен за помощь в реверсе алго:


В eax результат, задача - восстановить MYNUMBER

-----
ds

| Сообщение посчитали полезным:

ELF_7719116
Да, все ты верно понял и описал, не думал что мои обьяснения окажутся настолько сложными для некоторых посетителей форума.

ELF_7719116 пишет:
Недурно бы предыдущие версии проги посмотреть
Посмотрел предыдущую версию, там число циклов было одинаково (0xCB45F61)

calcDword идентична (та же конста MOV EBX,0xF1A05693)

dosprog пишет:
INPUTDATA это то, что навводил пользователь по своим имя\фамилиям_собаки

Да, входящие данные, с одной "перчинкой", возможно, надо было сразу это упомянуть:

chkInput := getCompDword($C7B5339A + licArr[5], szComp, licCount);
chkInput := getCompDword(chkInput, szName, licCount);
k:= 7 * (chkInput + 1);
chkInput := calcDword(k, licArr[5] + $19687E53);

Вот так вот считается дворд, с которым сравнивается "хеш" серийника.

перчинка в это: licArr[5] - это байт, который получается в результате некоторых трансформаций.
То есть влиять можно на оба dword'a , которые в рез-те сравниваются.

-----
ds

| Сообщение посчитали полезным:

Ну, и "для очистки совести" - тут: somemagic(INPUTDATA)
- INPUTDATA это то, что навводил пользователь по своим имя\фамилиям_собаки ?
Если да, тогда я запутался в условиях задачи.. Потому, что это тоже неизвестная.
Я полагал, что это какой-то фрагмент кода, почему-то


--Добавлено--

Да, входящие данные

- тогда всё ото выше от меня было ниачом..


--Добавлено2--

.. даа, а брутить такое жостко - один вызов процедурки calcDword() работает примерно секунду..



| Сообщение посчитали полезным:

dosprog пишет:
.. даа, а брутить такое жостко - один вызов процедурки calcDword() работает примерно секунду..
Дада, у меня вот только только 100 000 посчиталось (в 1 поток правда) Замеры точные не делал, в 5 утра поставил, ~в 6 вечера 100к посчиталось, пздц.

-----
ds

| Сообщение посчитали полезным:

DimitarSerg, ага, новые подробности! Как в хорошем детективе.
Теперь уже и количество итераций может быть вариабельно.
Так licArr[5] от чего конкретно зависит?
Может ли такое быть, что licArr[5] подбирается как некий параметр на этапе генерации серийника?

Я так понимаю, ваша задача в целом - по заданному KNOWN_VALUE (иначе говоря, пользовательским данным)
сгенерировать серийник, который пройдет валидацию по описанной вам процедуре.

| Сообщение посчитали полезным: sefkrd

kunix пишет:
Я так понимаю, ваша задача в целом - по заданному KNOWN_VALUE (иначе говоря, пользовательским данным)
сгенерировать серийник, который пройдет валидацию.
Верно.

kunix пишет:
Теперь уже и количество итераций может быть вариабельно.
Только для подсчета calcDword от INPUTDATA (и то как видно вариабельно в пределах байта 0x19687E53 + licArr[5]), там где calcDword от серийника - там жестко 0x1968BEC2

kunix пишет:
Так licArr[5] от чего конкретно зависит?
От пары символов в серийнике, по сути им можно играть, как душе угодно.

-----
ds

| Сообщение посчитали полезным:

DimitarSerg пишет:
licArr[5]
DimitarSerg пишет:
пары символов в серийнике, по сути им можно играть, как душе угодно.
Слушайте, Вам не приходило в голову, что он может быть банально равен 0 всегда?? (чтобы уравновесить COUNT1 и COUNT2)

| Сообщение посчитали полезным:

DimitarSerg пишет:
От пары символов в серийнике, по сути им можно играть, как душе угодно.
Ну это кое что меняет.

Вам достаточно по заданному KNOWN_VALUE подобрать serial и licArr[5] так, чтобы

FU(EAX=serial; EBX=0xF1A05693; COUNT=0x1968BEC2) = (EAX,EBX) = FU(EAX=KNOWN_VALUE ; EBX=0xF1A05693; COUNT=0x19687E53 + licArr[5]).

Где FU(EAX,EBX,COUNT)=(EAX,EBX) - это ваша функция из первого поста, которая взаимно однозначно отображает пару (EAX,EBX) в (EAX,EBX), и параметризуется COUNT.

При этом serial и licArr[5] - это 5 байт, которые вы можете свободно варьировать.
Верно?

(То есть, я еще и EBX предлагаю делать равными, а не только EAX. Более сильная задача.)

Функция FU() обратима, поэтому сократим итерации.
FU(EAX=serial; EBX=0xF1A05693; COUNT=0x406F) = (EAX,EBX) = FU(EAX=KNOWN_VALUE; EBX=0xF1A05693; COUNT=licArr[5]).

Итого, у вас есть типа две функции, которые псевдо-случайно выдают значения (8 байт). Нужно подобрать параметры, чтобы они совпали.
Короче, я хочу сделать парадокс дней рождения, но надо, чтобы обе функции могли принимать не менее 2^32 различных значений, если варьировать параметры.

И если с FU(EAX:=serial; EBX=0xF1A05693; COUNT=0x406F) все вроде ОК, то FU(EAX:=KNOWN_VALUE; EBX=0xF1A05693; COUNT=licArr[5]) принимает только 256 значений.

Короче, KNOWN_VALUE может тоже можно варьировать, варьируя серийник?

| Сообщение посчитали полезным:

Может я что не так сделал но у меня в х64дбг алгос с 0х20000000 count пробежал в меньше чем секунду.
С атакой дня рождения, 4 байта на input'е выходят в 2^16 итераций брута, а это 65к секунд, или сутки.

| Сообщение посчитали полезным:

hash87szf, тоже вариант, но одна из функций принимает только 2^8 значений, а надо 2^16.

| Сообщение посчитали полезным:

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

| Сообщение посчитали полезным:

kunix пишет:
При этом serial и licArr[5] - это 5 байт, которые вы можете свободно варьировать.
Верно?
Да, верно.

kunix пишет:
Короче, KNOWN_VALUE может тоже можно варьировать, варьируя серийник?
Можно, вот конец функи, где calcDword от серийника считается:

result := licArr[4] + licArr[3] shl $10 + licArr[6] shl 8 + licArr[7] shl $18;
result := calcDword(result, $1968BEC2);

Но вопрос остается актуален: как эти процессы ускорить или может все-таки есть какая-то мат.связь, позволяющая быстро подбирать 5 байт чтобы удовлетворить условие.

p.s. у авторов с математикой точно все прекрасно, софт - лучший шумодав в мире (Neat Image/ Neat Video). Как писали на ру-борде: "они из Владивостока - прихватизировали военные разработки шумоподавления для приборов обнаружения подводных лодок и свалили в Мельбурн"

Добавлено спустя 7 минут
hash87szf пишет:
Чел говорит шо 100к итераций сделал и коллизий нет пока, шо странно.
Я не говорил что коллизий нету, не проверял, просто сгенерил таблицу 0..99999 первых.

-----
ds

| Сообщение посчитали полезным:

DimitarSerg пишет:
вот конец функи
И так на протяжении всего треда, даёшь информацию порциями..
Может, все карты на стол..

| Сообщение посчитали полезным:

DimitarSerg пишет:
Можно, вот конец функи, где calcDword от серийника считается:

result := licArr[4] + licArr[3] shl $10 + licArr[6] shl 8 + licArr[7] shl $18;
result := calcDword(result, $1968BEC2);
А ну я гляжу там можно варьировать аж 5 байта (еще licArr[5]) с стороны KNOWN_VALUE.
Значит должен meet-in-the-middle работать.
Описанное hash87szf будет проще в реализации, наверное.

hash87szf, для атаки дней рождений (или meet-in-the-middle) размерностью 2^N нужно , чтобы ОБЕ функции принимали ~2^(N/2) различных значений из всего пространства при варьировании параметров.
А у нас тут одна принимает 2^(N/2) значений, а вторая сильно меньше.
Но да, с учетом нового инпута от DimitarSerg, должно сработать.

Добавлено спустя 0 минут
sefkrd, Я и говорю, врагу такого заказчика не пожелаешь

| Сообщение посчитали полезным:

Не совсем понял что конкретно вы предлагаете и как по времени ?

Я вот из того, что у меня есть, вход, выход и посчитанных 100к первых входов для calcDword(result, $1968BEC2) думаю играться с licArr[5], ну как играться, просто пройтись 0..255 со своими Имя/Компания/Кол-во и поискать по этим 100к значений, если хоть одно совпадет, то задача считай решена если нет- еще набрутить таблицу, хотя бы до 1млн ну или добавлять символы к Имя/Комания (как судя по всему делал человек из тимы AMPED, так как в его ключе для старой версии смежного продукта имя компании выглядит как AMPEDlb, видимо ребята тоже подбирали)

-----
ds

| Сообщение посчитали полезным:

DimitarSerg, ну hash87szf вам предлагает решение со сложностью где-то ~2^16 вычислений вашей хеш функции.
Если развернуть циклы, да распараллелить, будет норм, думаю.
Еще можно задействовать всякие vectored extensions или вообще видеокарту!

| Сообщение посчитали полезным:

kunix пишет:
для атаки дней рождений (или meet-in-the-middle)
имхо это очень разные весчи
дни рождения это мат. факт
и надо только генерить ~2^n/2 ( == 1.1774*sqrt(2^n) ) ранд инпутов шоб поиметь 50% шанс на кол.

| Сообщение посчитали полезным: reversecode

hash87szf, не буду спорить, не криптограф.
Но прямо "очень разные весчи" - это конечно преувеличение.

| Сообщение посчитали полезным:

Имхо, думать над алгосом не надо, он не развернётся ни в коем случае.
Выглядя так вот:


Единственное шо приходит в голову, это брут в обратную сторону но в один цикл. Начиная с n', подбираем инпут+n (64 бит) но так как цикл один и простой то мне кажется шо коллизий больше будет. Найденный n берём за n' и снова брут наверх в один цикл. И так до тех пор пока дельта циклов из софта не будет набрана, а дельта ведь нужна была точная, пока серж не сказал шо и кол.во циклов мы болтать можем.... Надежда метода на то шо коллизий в один цикл море.

Добавлено спустя 10 минут
Если я правильно algo срисовал да, и если игнорить шо твориться на границах 16бит при ADD переборе то заметьте:
n1' = (i1+n1=E) + (i2+n2=ax) //ax + E = n1'
n2' = n1 + (i2+n2=ax) //n1 + ax = n2'

| Сообщение посчитали полезным: DimitarSerg, plutos, mushr00m, reversecode

я тоже не криптограф, так что мое мнение в данном вопросе мало что значит, но просто из любопытства показал решение hash87szf'a одному из своих сотрудников, суровый very old school crypto, работал на Мин Обороны в свое время, тот согласился с hash87szf'oм.

-----
Give me a HANDLE and I will move the Earth.

| Сообщение посчитали полезным:

hash87szf, ну хз, я бы еще подумал.
Там в процессе вычислений два переноса из младшего WORD в старший, которые в итоге складываются.
Эвристически, в 50% случаев их сумма будет равна единице.
Можно попытаться посчитать N-ую итерацию в общем виде, предположив, что сумме переносов = 1.

| Сообщение посчитали полезным:

Пока вьезжаю в вышенаписанное , запустил 8-поточный брут, который по входящим имя/компания проверит все LicCount (1..99), все licArr[5] (0..255) посчитает выход и сверит со сгенеренной таблицой в 100к.

Добавлено спустя 2 часа 33 минуты
В принципе, даже на маленькой табличке в первых 100к уже нашелся 1 вариант под мое имя/компанию.
Не знаю смогу ли я под этот вариант серийник сделать, но это уже другой разговор, главное, что за разумное время. Пойду спать и поставлю еще таблиц генерить в 8 потоков )

-----
ds

| Сообщение посчитали полезным: sefkrd

Мб подтянуть немного троичной логики для ускорения перебора? Хотя хз насколько тут уместно + суммирования библиотека не поддерживает, придется инструкции заменять, а так забавная штука, тут еще есть парочка доп ссылок по теме.

| Сообщение посчитали полезным:

алго чем-то очень смахивает на разновидность шифро-примтива на основе ARX - https://en.wikipedia.org/wiki/Block_cipher#ARX_(add–rotate–xor) (без ксора)
на подобной конструкции построено довольно много алгоритмов - из достаточно современных salsa, threefish. Их авторы не зря выбрали такую конструкцию

| Сообщение посчитали полезным:

То, что сейчас хочет проделать DimitarSerg, автор софтины делает
для каждого зарегистрированного пользователя.
Очевидно, как-то он это делает по-другому.

| Сообщение посчитали полезным:

Не очевидно.
Для автора нет проблемы сгенерить таблицу в 16ГБ и с её помощью по выходу получать вход моментально.
Это для кейгена не комильфо только.

Я бы попробовал взять в качестве входа 0 и проанализировать как мутирует ключ и выходные данные на каждой итерации.
Возможно есть закономерность (повторяющийся шаблон) и количество итераций можно сократить.
Но не похоже.

Добавлено спустя 23 минуты
https://en.m.wikipedia.org/wiki/Feistel_cipher
Вот это очень похоже.
Вопрос только как обратную последовательность ключей получить если у нас они от входных данных зависят.

| Сообщение посчитали полезным:

cppasm пишет:
Для автора нет проблемы сгенерить таблицу в 16ГБ
Ну вообще-то проблема )
У автора думаю таблица побольше моей (у меня ~3+ Мб за сутки насчиталось ~+ /- , но там счетчик циклов конский, 1 хеш~1c
Мой подход свелся в общем к тому, что я "играю" байтиком licArr[5] (0..255) и кол-вом лицензий (1..99) во вложенном цикле, а затем я уже по таблице ищу полученные дворды, а их получается 256*99 = 25245 . Для статистики: на 800к уже посчитанных в таблицу пришлось 3 коллизии.

Естественно время моей генерации можно уменьшить (сейчас в 8 потоков считается ~5-7минут до первой коллизии), увеличив размеры таблицы и выбросив из цикла licCount (авторы точно не играются ), а например чисто 1 байтик licArr[5] прогнать, то есть не 25245 общих итерация, а 256 (в 99 раз быстрее) , вангую что будут коллизии.

А пока на ру-борде выложил софт и серийник:
https://www.sendspace.com/file/jm7dwt

-----
ds

| Сообщение посчитали полезным: dosprog

DimitarSerg пишет:
сейчас в 8 потоков считается ~5-7минут до первой коллизии
на видеокарте будет намного быстрей

-----
Чтобы правильно задать вопрос, нужно знать большую часть ответа. Р.Шекли.

| Сообщение посчитали полезным:

Между прочим число 0xF1A05693 простое, подозреваю что нужно почитать про классы (или кольца) вычетов из курса алгебры.

кроме того это число является суммой трёх квадратов:
n = a² + b² + c²

a = 55 489

b = 22 077

c = 22 077

Совпадение ? - не думаю. (ц)

| Сообщение посчитали полезным: Hugo Chaves, mak

имхо алго необратим. характерная особенность - сжатие (2 входа и 1 выход).

| Сообщение посчитали полезным:

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

-----
Array[Login..Logout] of Life

| Сообщение посчитали полезным: