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


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

-----
ds

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

На си примерно такое

Нет уверенности что можно решить не зная ebx перед выходом, похоже на какой-то простой хэш

-----
В облачке многоточия

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

Код на си. Функция по всей видимости необратима. Поставил для проверки шифровать все числа от 0 до FFFFFFFF, проверю нет ли коллизий. А они должны быть.



-----
PGP key <0x1B6A24550F33E44A>

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

Boostyq пишет:
похоже на какой-то простой хэш
Ну хз хз, "автор как-то генерит" ©

Там в обобщенном варианте считается чексумма от пользовательских данных, назовем dw1, он сравнивается с чексуммой серийника dw2, если упустить часть магии над сирийником, то в самом конце процедура выше считает этот dw2 и кол-во выполнений (в моей функе count) ~500млн... и брутить как-то вообще не комильфо.

-----
ds

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

DimitarSerg пишет:
Там в обобщенном варианте считается чексумма от пользовательских данных, назовем dw1, он сравнивается с чексуммой серийника dw2, если упустить часть магии над сирийником, то в самом конце процедура выше считает этот dw2 и кол-во выполнений (в моей функе count) ~500млн... и брутить как-то вообще не комильфо.

Ну так считаецо то в ту же сторону, а не в обратную
Константы в гугле нет, значит выбрана самостоятельно, а скорее всего рандомная, так что должно быть все дырявое

-----
В облачке многоточия

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

Быстро обращать хэш можно по таблице. Автор может держать у себя файлик на 16 гигабайт однажны посчитанный.

Я бы, если б выпускал шаровару, впихнул вообще 40ка битный медленный хэш. Кейген будет весить всего-то 5 терабайт А меньше - никак (при условии хорошей диффузии в цикле, чтобы не линеаризовалось).
Записал идею в блокнотик, подкину кому-нибудь

-----
PGP key <0x1B6A24550F33E44A>

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

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

-----
ds

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

Boostyq пишет:
Нет уверенности что можно решить не зная ebx перед выходом
Весь алгоритм - сложения 16битных значений с переносом в соседнее. Если ebx на выходе известен, алгоритм должен разматываться, если значение неизвестно - он необратим.
ntldr пишет:
Быстро обращать хэш можно по таблице. Автор может держать у себя файлик на 16 гигабайт однажны посчитанный.
Тут не только MYNUMBER переменная, но и COUNT. 4*(2^64) байт это не 16 гигабайт.

-----
2 оттенка серого

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

Так а какой результат в eax ?
я так понял, зная результат и константу, восстановить COUNT и MYNUMBER ?

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

bartolomeo пишет:
Так а какой результат в eax ?
В смысле какой результат ? Вопрос не понятен (код выше рабочий, можно свои значения поставить и затестить, даже не компилируя, тупо вставив в ольку/x64dbg плагином multimate assebler).

Count не надо восстанавливать, он точно известен, просто очень большой, в моем случае count = 0x20000000.

Ну вот напр, вход 0x12345678, count = 0x20000000, выхлоп 0xE550AFAF.
Задача: как-то зная 0xE550AFAF и count = 0x20000000 получить 0x12345678

-----
ds

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

ntldr пишет:
Быстро обращать хэш можно по таблице
dword по таблице там процессорного времени макс 15 сек))))

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

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

Проверка на коллизии показала, что на 4294967296 входных значений приходится 4294443071 выходных. Я сгенерировал файл с полным брутом и посчитал в нём повторяющиеся числа.

Это для всего-лишь count = 3. Функция необратима, 524225 циферок потерялись.

-----
PGP key <0x1B6A24550F33E44A>

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

DimitarSerg пишет:
Там в обобщенном варианте считается чексумма от пользовательских данных, назовем dw1, он сравнивается с чексуммой серийника dw2
с чего ты взял что тебе нужен этот хэшь? сам серийник должен быть привязан к нему, т.е серийник после манипуляций должен прийти 12345678, а хешь может быть привязан к пользователю что бы потом узнать от кого ушла прога.......

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

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

ntldr пишет:
Проверка на коллизии показала, что на 4294967296 входных значений приходится 4294443071 выходных. Я сгенерировал файл с полным брутом и посчитал в нём повторяющиеся числа.

Это для всего-лишь count = 3. Функция необратима, 524225 циферок потерялись.
Позвольте поинтересоваться, каким образом это было проделано?
Вы сгенерировали файл, затем отсортировали значения и после сравнили в один проход?

-----
В облачке многоточия

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

Boostyq пишет:
Вы сгенерировали файл, затем отсортировали значения и после сравнили в один проход?


Запускаю в консоли, перенаправляю вывод в текстовый файл, получаю 40гб файл с 16ти циферными HEX числами в каждой строке. Затем сортировка, дедупликация и подсчёт оставшихся строк своей прогой.

Сделал как проще. По-уму нужно было сформировать в памяти 16ти гигабайтный массив, затем его отсортировать и посчитать повторы.

-----
PGP key <0x1B6A24550F33E44A>

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

Никак не обратить - из-за <ROL>.

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

ClockMan
Каких 15 секунд ? У меня за ночь (7,5 часов) еще не посчиталось 100 000 ибо count конский просто.

ClockMan пишет:
с чего ты взял что тебе нужен этот хэшь?
потому что сравнение примерное такое:
if encrypt_x(somefunc(Name,Company,Other input data)) == encrypt_x(somemagic(SERIAL_NUM)) {OK}
count = 0x20000000 (число изменено специально, но в проге примерно в районе этого).

Я не знаю под какое значение мне SERIALNUM подбирать, так как это значение "хешируется" функцией encrypt_x

Добавлено спустя 1 минуту
dosprog
А ROL здесь при чем ? Ни один бит при ROL не пострадал

-----
ds

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

dosprog пишет:
Никак не обратить - из-за <ROL>.

Это же не shl/sal

-----
В облачке многоточия

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

Может еще эти данные помогут в решении задачи, а то я не все выложил, возможно ввел кого-то в заблуждение:

chkSerial := calcDword(somemath(SERIAL), $1968BEC2);
chkInput := calcDword(somemagic(INPUTDATA),$19687E53);
ifc chkSerial == chkInput then OK

Второй параметр, как вы уже понимаете - COUNT (счетчик итераций).
Вот это реальные данные из проги, chkSerial я считаю, а нужно узнать somemagic(INPUTDATA)

-----
ds

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

DimitarSerg пишет:
chkSerial := calcDword(SERIAL, $1968BEC2);
chkInput := calcDword(somemagic(INPUTDATA),$19687E53);
(SERIAL, 0x406F) == somemagic(INPUTDATA)
предположу фигню: может INPUTDATA всего с 0x406F итерациями крутят и потом вычитают/прибавляют из/к SERIAL?!?

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

ELF_7719116
Да вот тоже мысли крутятся, не спроста эти числа именно такие (счетчики циклов)... с разницей всего 0x406F

-----
ds

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

DimitarSerg пишет:
А ROL здесь при чем ? Ни один бит при ROL не пострадал

Да, пардон, попутал с действием <RCL>



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


chkSerial := calcDword(SERIAL, $1968BEC2);
chkInput := calcDword(somemagic(INPUTDATA),$19687E53);
ifc chkSerial == chkInput then OK

- а нельзя подглядеть EBX на выходе из <calcDword(somemagic(INPUTDATA),$19687E53);> ?

И дальше уж:

f13nd пишет:
Весь алгоритм - сложения 16битных значений с переносом в соседнее. Если ebx на выходе известен, алгоритм должен разматываться, если значение неизвестно - он необратим.



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

dosprog пишет:
а нельзя подглядеть EBX на выходе из <calcDword(somemagic(INPUTDATA),$19687E53
Что ? И что оно нам даст, у нас здесь и так все известные, задача свелась к тому, что

calcDword(SERIAL, $1968BEC2) == calcDword(somemagic(INPUTDATA),$19687E53);
еще упростим:
calcDword(SERIAL, $1968BEC2) == calcDword(KNOWN_VALUE,$19687E53);

-----
ds

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

DimitarSerg пишет:
еще упростим:
calcDword(SERIAL, $1968BEC2) == calcDword(KNOWN_VALUE,$19687E53);

Ну так похоже, что у них на выходе и EBX тоже должны быть одинаковые.

Хотя, нет, ерунда...


-- Добавлено --
Тогда, если результат функции (EAX) известен, счётчик тоже, - то брутить.
Что и происходит, насколько я понял.



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

DimitarSerg пишет:
calcDword(SERIAL, $1968BEC2) == calcDword(KNOWN_VALUE,$19687E53);

ELF_7719116 пишет:
(SERIAL, 0x406F) == somemagic(INPUTDATA)
Если уж фокуситься на этой процедуре encrypt_x, то странность более всего дифферент по count = 0x406F. Тогда между SERIAL и KNOW_VALUE должна быть прямая зависимость для быстрого вычисления. Алго один и тот-же, и пусть он не обратим.
И второе, есть ли зависимость между KEY (0xF1A05693) и количеством итераций count?! Может найдется такой KEY, при 0x406F итерациях?!

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

ELF_7719116 пишет:
calcDword(SERIAL, 0x406F) == somemagic(INPUTDATA)

Кстати, логично - как-то же он сам генерирует валидный сериал, который для раздачи

ELF_7719116 пишет:
KEY (0xF1A05693) и количеством итераций count?! Может найдется такой KEY, при 0x406F итерациях?!

Так это же вроде бы константа, ещё и жёстко заданная в коде ..



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

Короче DimitarSerg не умеет составлять ТЗ. Так невнятно объяснить еще уметь надо.

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

Ну, так исчерпывающая формулировка задачи уже часто в себе и ответ содержит.

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

kunix
Спасибо, очень полезный коммент, жаль лайки закончились, так бы обязательно лайкнул.

dosprog пишет:
а нельзя подглядеть EBX на выходе
Еще помудрил над этим ... можно , мы ведь сами считаем, кто нам мешает. И в таком случае обратку я написал, напр.
calcDword($12345678,$10000000) = $231E31A1 (ebx = D4B49E5E)

Написанная мною обратная функция
reCalcDword($D4B49E5E,$10000000) , magic:=$231E31A1;

дает мне обратный результат $12345678, но, нам же необходимо найти такое Х, при котором
calcDword(X,$11000000) также даст $231E31A1

-----
ds

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

kunix пишет:
Так невнятно объяснить еще уметь надо.
Судя по написанному, ситуация примерно такая: вводим личные данные (имя, фамилия, страна проживания, кличка собачки...), отправляем на сервер - получаем серийник. В проге вычисляется два хеша - от серийника, и от юзерских данных. Для хешей юзается один и тот-же алго, но на входе разное количество итераций (count). В итоге, зная свои личные данные (или соседа по лестничной клекте), сгенерить первый хеш. Затем, с помощью некоторой зависимости установить второй хеш и реверснуть ветку серийника обратно, попробовав его развернуть из хеша. Неясно лично для меня, какик операции выполняются с данными до процедуры хешировния (возможно INPUT_DATA и SERIAL и без хеша имеют прямую математическую зависимость) в двух ветках и возможно ли урезать count для алго хешировния (если он не обратим).


dosprog пишет:
константа, ещё и жёстко заданная в коде
Да, я понял. Мысль заключалась в том, что автор может юзать меньшее количество итераций для одних и тех же входных данных, зная другие константы KEY. Т е. KEY должен быть в прямой зависимости от COUNT.
Недурно бы предыдущие версии проги посмотреть - какие там константы KEY, COUNT, если сам алго не менялся. Может он вообще по остаточному принципу считается - Т.е. дифферент между count подгоняется после основного обсчета серийника.

ADD
DimitarSerg пишет:
calcDword($12345678,$10000000)
calcDword(X,$11000000) также даст $231E31A1
Поверю что KEY, COUNT1, COUNT2 задаются рандомно. Но дифферент (COUNT1-COUNT2) явно из каких-то математических / логических соображений задан.

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