forum.opennet.ru - "unixtime переведён в hex по какому алгоритму?" (19)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"unixtime переведён в hex по какому алгоритму?"

Форум Программирование под UNIX (PHP)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"unixtime переведён в hex по какому алгоритму?"	+/–
Сообщение от greenwar (ok) on 24-Ноя-12, 16:28
пытаюсь понять, по какому алгоритму эти цифры (unixtime) были переведены в hex (или что это?) там так же есть и другие цифры, привязанные к этому time: 1353759194 -> 2db40b + 8808965 + 517228 1353759168 -> b194ab + 7109279 + 517228 1353759135 -> b366ed + 7384326 + 517228 может кто с опытным глазом поймёт?
Ответить \| Правка \| Cообщить модератору

Оглавление

unixtime переведён в hex по какому алгоритму?, grgdvo, 01:11 , 25-Ноя-12, (1) –1

unixtime переведён в hex по какому алгоритму?, greenwar, 01:13 , 25-Ноя-12, (2)

unixtime переведён в hex по какому алгоритму?, grgdvo, 01:59 , 27-Ноя-12, (16)

unixtime переведён в hex по какому алгоритму?, pavlinux, 03:23 , 26-Ноя-12, (3)

unixtime переведён в hex по какому алгоритму?, greenwar, 04:47 , 26-Ноя-12, (5)

unixtime переведён в hex по какому алгоритму?, pavlinux, 04:45 , 26-Ноя-12, (4)

unixtime переведён в hex по какому алгоритму?, greenwar, 04:49 , 26-Ноя-12, (6)

unixtime переведён в hex по какому алгоритму?, pavlinux, 04:52 , 26-Ноя-12, (7)

unixtime переведён в hex по какому алгоритму?, greenwar, 04:58 , 26-Ноя-12, (8)

unixtime переведён в hex по какому алгоритму?, pavlinux, 05:03 , 26-Ноя-12, (9)

unixtime переведён в hex по какому алгоритму?, greenwar, 05:10 , 26-Ноя-12, (10)

unixtime переведён в hex по какому алгоритму?, pavlinux, 05:24 , 26-Ноя-12, (11)

unixtime переведён в hex по какому алгоритму?, greenwar, 05:28 , 26-Ноя-12, (12)

unixtime переведён в hex по какому алгоритму?, pavlinux, 05:38 , 26-Ноя-12, (13)

unixtime переведён в hex по какому алгоритму?, greenwar, 05:43 , 26-Ноя-12, (14)

unixtime переведён в hex по какому алгоритму?, pavlinux, 05:48 , 26-Ноя-12, (15)

unixtime переведён в hex по какому алгоритму?, greenwar, 19:07 , 29-Ноя-12, (17)
unixtime переведён в hex по какому алгоритму?, pavlinux, 05:52 , 30-Ноя-12, (18)
unixtime переведён в hex по какому алгоритму?, greenwar, 20:51 , 01-Дек-12, (19)

Сообщения по теме [Сортировка по времени | RSS]

1. "unixtime переведён в hex по какому алгоритму?" –1 +/–

Сообщение от grgdvo (ok) on 25-Ноя-12, 01:11

Если я вас правильно понял, то это количество секунд с момента начала эпохи (1.01.1970 GMT). Об этом написано во всех мануалах! Зачем пытаться, надо просто прочитать.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "unixtime переведён в hex по какому алгоритму?" +/–

Сообщение от greenwar (ok) on 25-Ноя-12, 01:13

> Если я вас правильно понял, то это количество секунд с момента начала
> эпохи (1.01.1970 GMT). Об этом написано во всех мануалах! Зачем пытаться,
> надо просто прочитать.
троллишь?

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

16. "unixtime переведён в hex по какому алгоритму?" +/–

Сообщение от grgdvo (ok) on 27-Ноя-12, 01:59

> троллишь?
туплю. извините

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

3. "unixtime переведён в hex по какому алгоритму?" +/–

Сообщение от pavlinux (ok) on 26-Ноя-12, 03:23

> пытаюсь понять, по какому алгоритму эти цифры (unixtime) были переведены в hex
> (или что это?)
> там так же есть и другие цифры, привязанные к этому time:
> 1353759194 -> 2db40b + 8808965 + 517228
> 1353759168 -> b194ab + 7109279 + 517228
> 1353759135 -> b366ed + 7384326 + 517228
> может кто с опытным глазом поймёт?
Это откуда? Чем/кем были переведены? Тему скажи...
А то тут три уравнения с 6-ю неизвестными.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "unixtime переведён в hex по какому алгоритму?" +/–

Сообщение от greenwar (ok) on 26-Ноя-12, 04:47

>> пытаюсь понять, по какому алгоритму эти цифры (unixtime) были переведены в hex
>> (или что это?)
>> там так же есть и другие цифры, привязанные к этому time:
>> 1353759194 -> 2db40b + 8808965 + 517228
>> 1353759168 -> b194ab + 7109279 + 517228
>> 1353759135 -> b366ed + 7384326 + 517228
>> может кто с опытным глазом поймёт?
> Это откуда? Чем/кем были переведены? Тему скажи...
> А то тут три уравнения с 6-ю неизвестными.
так если бы я знал ЧЕМ :(
есть какой-то алгоритм, вот и хочу его найти

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

4. "unixtime переведён в hex по какому алгоритму?" +/–

Сообщение от pavlinux (ok) on 26-Ноя-12, 04:45

> 1353759194 -> 2db40b + 8808965 + 517228
> 1353759168 -> b194ab + 7109279 + 517228
> 1353759135 -> b366ed + 7384326 + 517228
> может кто с опытным глазом поймёт?
Короча я нашёл такую закономерность.
Если сумма справа написана в шестнадцатеричном измерении, то
работает уравнение, переведённое в десятичную систему счисления:
(с точностью до второго знака).

     UNIX_TIME
1 - ------------
      10 * SUM

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "unixtime переведён в hex по какому алгоритму?" +/–

Сообщение от greenwar (ok) on 26-Ноя-12, 04:49

>[оверквотинг удален]
>> может кто с опытным глазом поймёт?
> Короча я нашёл такую закономерность.
> Если сумма справа написана в шестнадцатеричном измерении, то
> работает уравнение, переведённое в десятичную систему счисления:
> (с точностью до второго знака).
>

>      UNIX_TIME
> 1 - ------------
>      10 * SUM
>

а сумма, в данном случае, чего?

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

7. "unixtime переведён в hex по какому алгоритму?" +/–

Сообщение от pavlinux (ok) on 26-Ноя-12, 04:52

>[оверквотинг удален]
>> Короча я нашёл такую закономерность.
>> Если сумма справа написана в шестнадцатеричном измерении, то
>> работает уравнение, переведённое в десятичную систему счисления:
>> (с точностью до второго знака).
>>

>>      UNIX_TIME
>> 1 - ------------
>>      10 * SUM
>>

> а сумма, в данном случае, чего?
числа справа

                  1353759194
1 -  -------------------------------------
     10 * (0x2db40b + 0x8808965 + 0x517228)
ну и так далее ...
1353759168  = b194ab + 7109279 + 517228
1353759135  = b366ed + 7384326 + 517228

Результаты такие:
-0.0737443548,  0.035920647 и 0.014794913

---
Единственное что приходит на ум, это 10-ричная форма минут.
Кстати, последняя константа в суммах: 517228 - это астрономическая неделя в секундах.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "unixtime переведён в hex по какому алгоритму?" +/–

Сообщение от greenwar (ok) on 26-Ноя-12, 04:58

>[оверквотинг удален]
>
>       1353759194
> 1 -  -------------------------------------
>      10 * (0x2db40b + 0x8808965 + 0x517228)
>
> ну и так далее ...
>  1353759168  = b194ab + 7109279 + 517228
>  1353759135  = b366ed + 7384326 + 517228
> Результаты такие:
>  -0.0737443548,  0.035920647 и 0.014794913
так результатом должен стать этот unixtime, например
а эти цифры вообще ниачОм получаются

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

9. "unixtime переведён в hex по какому алгоритму?" +/–

Сообщение от pavlinux (ok) on 26-Ноя-12, 05:03

>> Результаты такие:
>>  -0.0737443548,  0.035920647 и 0.014794913
> так результатом должен стать этот unixtime, например
> а эти цифры вообще ниачОм получаются
Эти цифры показывают погрешность от уравнения:  y = 10 * x;
Например = 10 * ( 1 + 0.014794913 ) * (0x2db40b + 0x8808965 + 0x517228) = UNIX_TIME, а именно 1353759194;
Думаю даже числа отбросить можно, оставить просто (10 * SUM = UNIX_TIME);
----
> есть какой-то алгоритм, вот и хочу его найти
Ты лучше скажи где откопал, условия, место... источники....
Ещё раз скажу, у меня только одна мысль для чего это нужно:
запихнуть UNIXTIME в три 16-разрядных регистра, потом с выталкиванием
побитово сложить и дорисовать нолик (умножить на 10)

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

10. "unixtime переведён в hex по какому алгоритму?" +/–

Сообщение от greenwar (ok) on 26-Ноя-12, 05:10

>>> Результаты такие:
>>>  -0.0737443548,  0.035920647 и 0.014794913
>> так результатом должен стать этот unixtime, например
>> а эти цифры вообще ниачОм получаются
> Как ни о чём, например = 10 * ( 1 + 0.014794913
> ) * (0x2db40b + 0x8808965 + 0x517228) = UNIX_TIME, а именно
> 1353759194;
> Думаю даже числа отбросить можно, оставить просто (10 * SUM = UNIX_TIME);
если неделя, то почему не меняется каждую неделю? это константа
если получается unixtime, то тогда имеем 2 неизвестных: 2db40b и 8808965, которые генерятся.. рандомно? должна быть закономерность какая-то
> Ты лучше скажи где откопал, условия, место... источники....
условия: unixtime это время текущее, а 2db40b - его checksumm (ну так переменная называется в коде жабаскрипта)
8808965 хз что, но без неё сервер не пропускает данные
последняя цифра - константа
это hidden-данные из формы

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

11. "unixtime переведён в hex по какому алгоритму?" +/–

Сообщение от pavlinux (ok) on 26-Ноя-12, 05:24

>>>> Результаты такие:
>>>>  -0.0737443548,  0.035920647 и 0.014794913
>>> так результатом должен стать этот unixtime, например
>>> а эти цифры вообще ниачОм получаются
>> Как ни о чём, например = 10 * ( 1 + 0.014794913
>> ) * (0x2db40b + 0x8808965 + 0x517228) = UNIX_TIME, а именно
>> 1353759194;
>> Думаю даже числа отбросить можно, оставить просто (10 * SUM = UNIX_TIME);
> если неделя, то почему не меняется каждую неделю?
Это скорее дополнение, типа два случайных и дописочка
> если получается unixtime, то тогда имеем 2 неизвестных: 2db40b и 8808965, которые
> генерятся.. рандомно? должна быть закономерность какая-то
Их сумма - константа, а меж собой рандомны, это уравнения вида: x + y = z, x < z
То есть генерим любое (x) меньше (z), потом делаем (z - x = y)
>> Ты лучше скажи где откопал, условия, место... источники....
> условия: unixtime это время текущее, а 2db40b - его checksumm (ну так
> переменная называется в коде жабаскрипта)
Ну вот, мы только что похакали генератор чексуммы :)

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

12. "unixtime переведён в hex по какому алгоритму?" +/–

Сообщение от greenwar (ok) on 26-Ноя-12, 05:28

>[оверквотинг удален]
>> если получается unixtime, то тогда имеем 2 неизвестных: 2db40b и 8808965, которые
>> генерятся.. рандомно? должна быть закономерность какая-то
> Их сумма - константа, а меж собой рандомны, это уравнения вида: x
> + y = z, x < z
> То есть генерим любое (x) меньше (z), потом делаем (z - x
> = y)
их сумма не может быть константой. если 2 константы сложить, то unixtime не получится (оно ведь изменяется каждую секунду)
>>> Ты лучше скажи где откопал, условия, место... источники....
>> условия: unixtime это время текущее, а 2db40b - его checksumm (ну так
>> переменная называется в коде жабаскрипта)
> Ну вот, мы только что похакали генератор чексуммы :)
ну я тут просто зритель :)
причём, в 5 утра мало понимающий :))
вот тут: 10 * ( 1 + 0.014794913 ) * (0x2db40b + 0x8808965 + 0x517228) = UNIX_TIME
цифра 0.014794913 откуда берётся??

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

13. "unixtime переведён в hex по какому алгоритму?" +/–

Сообщение от pavlinux (ok) on 26-Ноя-12, 05:38

>[оверквотинг удален]
> цифра 0.014794913 откуда берётся??
Так из первого уравнения:   1 - (UNIXTIME/(10*SUM))
Как я думаю, умножение на 10 сто пудов есть, а дальше нужен алгоритм вычисления чексуммы.
Мы и так дофига знаем:
1. То, что одно число константа и равна недели.
2. Уравнение: 1 - (UNIXTIME/(10*SUM)), дает взаимосвязь с точностью до 0.1
3. Сумма из CRC и случайного меж собой связаны.

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

14. "unixtime переведён в hex по какому алгоритму?" +/–

Сообщение от greenwar (ok) on 26-Ноя-12, 05:43

>>[оверквотинг удален]
>> цифра 0.014794913 откуда берётся??
> Так из первого уравнения:   1 - (UNIXTIME/(10*SUM))
или я где-то туплю, или ты это же уравнение потом используешь с этим же числом
и ещё дело в том, что мне чексумма и второе число как бэ не известны, я их должен получить

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

15. "unixtime переведён в hex по какому алгоритму?" +/–

Сообщение от pavlinux (ok) on 26-Ноя-12, 05:48

>>>[оверквотинг удален]
>>> цифра 0.014794913 откуда берётся??
>> Так из первого уравнения:   1 - (UNIXTIME/(10*SUM))
> или я где-то туплю, или ты это же уравнение потом используешь с этим же числом
Блин, этим уравнением, и его результатом, я тебе показал, как взаимосвязаны числа
слева и справа (из первого сообщения).
То есть, к тебе прилетели эти три числа, берёшь их складываешь
(0x2db40b + 0x8808965 + 0x517228), потом умножаешь на 10, это
и будет примерный UNIX_TIME, с точностью до 1.5 минут :)
---
Короче, без алгоритма CRC - все бесполезно. Аппроксимация, интерполяция, экстраполяция
и т.п., для дискретных величин малоэффективны и дают лишь оценку сложности.
В твоём случае алгоритм CRC должен быть полной фигнёй, коль просматривается
такая зависимость.
По делу тут можно только генерировать и ловить коллизию CRC, не менее 3 штук.
тогда восстановишь алгоритм расчёта второго числа. И уже после - найдёшь алгоритм CRC.

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

17. "unixtime переведён в hex по какому алгоритму?" +/–

Сообщение от greenwar (ok) on 29-Ноя-12, 19:07

>>>>[оверквотинг удален]
>>>> цифра 0.014794913 откуда берётся??
>>> Так из первого уравнения:   1 - (UNIXTIME/(10*SUM))
>> или я где-то туплю, или ты это же уравнение потом используешь с этим же числом
> Блин, этим уравнением, и его результатом, я тебе показал, как взаимосвязаны числа
> слева и справа (из первого сообщения).
> То есть, к тебе прилетели эти три числа, берёшь их складываешь
> (0x2db40b + 0x8808965 + 0x517228), потом умножаешь на 10, это
> и будет примерный UNIX_TIME, с точностью до 1.5 минут :)
погрешность великовата, конечно, там с точностью до секунды палится
но вполне допускаю, что прокатит случайная генерация, как ты говорил выше: x + y = z, x < z
а там уже погрешностью можно управлять, если числа внатуре рандомные
вполне сойдёт за алгоритм, учитывая, что там все остальные алгоритмы вообще никакие
я чё-то не могу повторить эту операцию:
                    1353759194
1 -  -------------------------------------
     10 * (0x2db40b + 0x8808965 + 0x517228)
ну и так далее ...
1353759168  = b194ab + 7109279 + 517228
1353759135  = b366ed + 7384326 + 517228

Результаты такие:
-0.0737443548,  0.035920647 и 0.014794913
не получаю я такие результаты в перле..
0x2db40b + 0x8808965 + 0x517228
как эти 0x вычисляются?

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

18. "unixtime переведён в hex по какому алгоритму?" +/–

Сообщение от pavlinux (ok) on 30-Ноя-12, 05:52

>>>>>[оверквотинг удален]
> как эти 0x вычисляются?
Да забей ты на эти результаты, это так... оценочная пристрелка была.
Нужны суммы хотя бы 10 подряд секунд, потому как замеры с шагом в
26 и 33 секунды почти тот же рандом. :)

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

19. "unixtime переведён в hex по какому алгоритму?" +/–

Сообщение от greenwar (ok) on 01-Дек-12, 20:51

>>>>>>[оверквотинг удален]
>> как эти 0x вычисляются?
> Да забей ты на эти результаты, это так... оценочная пристрелка была.
> Нужны суммы хотя бы 10 подряд секунд, потому как замеры с шагом
> в
> 26 и 33 секунды почти тот же рандом. :)
а говорил "хакнули" :)
ок, вот:
1354380191      9d3af9  5288526    515632
1354380192      9d3af9  9683068    516435
1354380193      47a703  4367619    514030
1354380194      c86baf  1001106    514033
1354380195      df8d31  3593081    513232
1354380196      3f0ec5  10404958   514034
1354380201      728680  15322612   512433
1354380202      728680  9224301    513225
1354380204      abfaa7  3249889    522041
1354380205      701027  729426     510821
1354380206      701027  13903112   520433
погорячился я с "константой" ^^
блин, уравнение с 3мя неизвестными
если решишь, тебе наверное нобелевку давать можно :))

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "unixtime переведён в hex по какому алгоритму?"	–1 +/–
Сообщение от grgdvo (ok) on 25-Ноя-12, 01:11
Если я вас правильно понял, то это количество секунд с момента начала эпохи (1.01.1970 GMT). Об этом написано во всех мануалах! Зачем пытаться, надо просто прочитать.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	2. "unixtime переведён в hex по какому алгоритму?"	+/–
	Сообщение от greenwar (ok) on 25-Ноя-12, 01:13
	> Если я вас правильно понял, то это количество секунд с момента начала > эпохи (1.01.1970 GMT). Об этом написано во всех мануалах! Зачем пытаться, > надо просто прочитать. троллишь?
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	16. "unixtime переведён в hex по какому алгоритму?"	+/–
	Сообщение от grgdvo (ok) on 27-Ноя-12, 01:59
	> троллишь? туплю. извините
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору

3. "unixtime переведён в hex по какому алгоритму?"	+/–
Сообщение от pavlinux (ok) on 26-Ноя-12, 03:23
> пытаюсь понять, по какому алгоритму эти цифры (unixtime) были переведены в hex > (или что это?) > там так же есть и другие цифры, привязанные к этому time: > 1353759194 -> 2db40b + 8808965 + 517228 > 1353759168 -> b194ab + 7109279 + 517228 > 1353759135 -> b366ed + 7384326 + 517228 > может кто с опытным глазом поймёт? Это откуда? Чем/кем были переведены? Тему скажи... А то тут три уравнения с 6-ю неизвестными.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	5. "unixtime переведён в hex по какому алгоритму?"	+/–
	Сообщение от greenwar (ok) on 26-Ноя-12, 04:47
	>> пытаюсь понять, по какому алгоритму эти цифры (unixtime) были переведены в hex >> (или что это?) >> там так же есть и другие цифры, привязанные к этому time: >> 1353759194 -> 2db40b + 8808965 + 517228 >> 1353759168 -> b194ab + 7109279 + 517228 >> 1353759135 -> b366ed + 7384326 + 517228 >> может кто с опытным глазом поймёт? > Это откуда? Чем/кем были переведены? Тему скажи... > А то тут три уравнения с 6-ю неизвестными. так если бы я знал ЧЕМ :( есть какой-то алгоритм, вот и хочу его найти
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору

4. "unixtime переведён в hex по какому алгоритму?"	+/–
Сообщение от pavlinux (ok) on 26-Ноя-12, 04:45
> 1353759194 -> 2db40b + 8808965 + 517228 > 1353759168 -> b194ab + 7109279 + 517228 > 1353759135 -> b366ed + 7384326 + 517228 > может кто с опытным глазом поймёт? Короча я нашёл такую закономерность. Если сумма справа написана в шестнадцатеричном измерении, то работает уравнение, переведённое в десятичную систему счисления: (с точностью до второго знака). UNIX_TIME 1 - ------------ 10 * SUM
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	6. "unixtime переведён в hex по какому алгоритму?"	+/–
	Сообщение от greenwar (ok) on 26-Ноя-12, 04:49
	>[оверквотинг удален] >> может кто с опытным глазом поймёт? > Короча я нашёл такую закономерность. > Если сумма справа написана в шестнадцатеричном измерении, то > работает уравнение, переведённое в десятичную систему счисления: > (с точностью до второго знака). > > UNIX_TIME > 1 - ------------ > 10 * SUM > а сумма, в данном случае, чего?
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	7. "unixtime переведён в hex по какому алгоритму?"	+/–
	Сообщение от pavlinux (ok) on 26-Ноя-12, 04:52
	>[оверквотинг удален] >> Короча я нашёл такую закономерность. >> Если сумма справа написана в шестнадцатеричном измерении, то >> работает уравнение, переведённое в десятичную систему счисления: >> (с точностью до второго знака). >> >> UNIX_TIME >> 1 - ------------ >> 10 * SUM >> > а сумма, в данном случае, чего? числа справа 1353759194 1 - ------------------------------------- 10 * (0x2db40b + 0x8808965 + 0x517228) ну и так далее ... 1353759168 = b194ab + 7109279 + 517228 1353759135 = b366ed + 7384326 + 517228 Результаты такие: -0.0737443548, 0.035920647 и 0.014794913 --- Единственное что приходит на ум, это 10-ричная форма минут. Кстати, последняя константа в суммах: 517228 - это астрономическая неделя в секундах.
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору


	8. "unixtime переведён в hex по какому алгоритму?"	+/–
	Сообщение от greenwar (ok) on 26-Ноя-12, 04:58
	>[оверквотинг удален] > > 1353759194 > 1 - ------------------------------------- > 10 * (0x2db40b + 0x8808965 + 0x517228) > > ну и так далее ... > 1353759168 = b194ab + 7109279 + 517228 > 1353759135 = b366ed + 7384326 + 517228 > Результаты такие: > -0.0737443548, 0.035920647 и 0.014794913 так результатом должен стать этот unixtime, например а эти цифры вообще ниачОм получаются
	Ответить \| Правка \| ^ к родителю #7 \| Наверх \| Cообщить модератору


	9. "unixtime переведён в hex по какому алгоритму?"	+/–
	Сообщение от pavlinux (ok) on 26-Ноя-12, 05:03
	>> Результаты такие: >> -0.0737443548, 0.035920647 и 0.014794913 > так результатом должен стать этот unixtime, например > а эти цифры вообще ниачОм получаются Эти цифры показывают погрешность от уравнения: y = 10 * x; Например = 10 * ( 1 + 0.014794913 ) * (0x2db40b + 0x8808965 + 0x517228) = UNIX_TIME, а именно 1353759194; Думаю даже числа отбросить можно, оставить просто (10 * SUM = UNIX_TIME); ---- > есть какой-то алгоритм, вот и хочу его найти Ты лучше скажи где откопал, условия, место... источники.... Ещё раз скажу, у меня только одна мысль для чего это нужно: запихнуть UNIXTIME в три 16-разрядных регистра, потом с выталкиванием побитово сложить и дорисовать нолик (умножить на 10)
	Ответить \| Правка \| ^ к родителю #8 \| Наверх \| Cообщить модератору


	10. "unixtime переведён в hex по какому алгоритму?"	+/–
	Сообщение от greenwar (ok) on 26-Ноя-12, 05:10
	>>> Результаты такие: >>> -0.0737443548, 0.035920647 и 0.014794913 >> так результатом должен стать этот unixtime, например >> а эти цифры вообще ниачОм получаются > Как ни о чём, например = 10 * ( 1 + 0.014794913 > ) * (0x2db40b + 0x8808965 + 0x517228) = UNIX_TIME, а именно > 1353759194; > Думаю даже числа отбросить можно, оставить просто (10 * SUM = UNIX_TIME); если неделя, то почему не меняется каждую неделю? это константа если получается unixtime, то тогда имеем 2 неизвестных: 2db40b и 8808965, которые генерятся.. рандомно? должна быть закономерность какая-то > Ты лучше скажи где откопал, условия, место... источники.... условия: unixtime это время текущее, а 2db40b - его checksumm (ну так переменная называется в коде жабаскрипта) 8808965 хз что, но без неё сервер не пропускает данные последняя цифра - константа это hidden-данные из формы
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору


	11. "unixtime переведён в hex по какому алгоритму?"	+/–
	Сообщение от pavlinux (ok) on 26-Ноя-12, 05:24
	>>>> Результаты такие: >>>> -0.0737443548, 0.035920647 и 0.014794913 >>> так результатом должен стать этот unixtime, например >>> а эти цифры вообще ниачОм получаются >> Как ни о чём, например = 10 * ( 1 + 0.014794913 >> ) * (0x2db40b + 0x8808965 + 0x517228) = UNIX_TIME, а именно >> 1353759194; >> Думаю даже числа отбросить можно, оставить просто (10 * SUM = UNIX_TIME); > если неделя, то почему не меняется каждую неделю? Это скорее дополнение, типа два случайных и дописочка > если получается unixtime, то тогда имеем 2 неизвестных: 2db40b и 8808965, которые > генерятся.. рандомно? должна быть закономерность какая-то Их сумма - константа, а меж собой рандомны, это уравнения вида: x + y = z, x < z То есть генерим любое (x) меньше (z), потом делаем (z - x = y) >> Ты лучше скажи где откопал, условия, место... источники.... > условия: unixtime это время текущее, а 2db40b - его checksumm (ну так > переменная называется в коде жабаскрипта) Ну вот, мы только что похакали генератор чексуммы :)
	Ответить \| Правка \| ^ к родителю #10 \| Наверх \| Cообщить модератору


	12. "unixtime переведён в hex по какому алгоритму?"	+/–
	Сообщение от greenwar (ok) on 26-Ноя-12, 05:28
	>[оверквотинг удален] >> если получается unixtime, то тогда имеем 2 неизвестных: 2db40b и 8808965, которые >> генерятся.. рандомно? должна быть закономерность какая-то > Их сумма - константа, а меж собой рандомны, это уравнения вида: x > + y = z, x < z > То есть генерим любое (x) меньше (z), потом делаем (z - x > = y) их сумма не может быть константой. если 2 константы сложить, то unixtime не получится (оно ведь изменяется каждую секунду) >>> Ты лучше скажи где откопал, условия, место... источники.... >> условия: unixtime это время текущее, а 2db40b - его checksumm (ну так >> переменная называется в коде жабаскрипта) > Ну вот, мы только что похакали генератор чексуммы :) ну я тут просто зритель :) причём, в 5 утра мало понимающий :)) вот тут: 10 * ( 1 + 0.014794913 ) * (0x2db40b + 0x8808965 + 0x517228) = UNIX_TIME цифра 0.014794913 откуда берётся??
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору


	13. "unixtime переведён в hex по какому алгоритму?"	+/–
	Сообщение от pavlinux (ok) on 26-Ноя-12, 05:38
	>[оверквотинг удален] > цифра 0.014794913 откуда берётся?? Так из первого уравнения: 1 - (UNIXTIME/(10SUM)) Как я думаю, умножение на 10 сто пудов есть, а дальше нужен алгоритм вычисления чексуммы. Мы и так дофига знаем: 1. То, что одно число константа и равна недели. 2. Уравнение: 1 - (UNIXTIME/(10SUM)), дает взаимосвязь с точностью до 0.1 3. Сумма из CRC и случайного меж собой связаны.
	Ответить \| Правка \| ^ к родителю #12 \| Наверх \| Cообщить модератору


	14. "unixtime переведён в hex по какому алгоритму?"	+/–
	Сообщение от greenwar (ok) on 26-Ноя-12, 05:43
	>>[оверквотинг удален] >> цифра 0.014794913 откуда берётся?? > Так из первого уравнения: 1 - (UNIXTIME/(10*SUM)) или я где-то туплю, или ты это же уравнение потом используешь с этим же числом и ещё дело в том, что мне чексумма и второе число как бэ не известны, я их должен получить
	Ответить \| Правка \| ^ к родителю #13 \| Наверх \| Cообщить модератору


	15. "unixtime переведён в hex по какому алгоритму?"	+/–
	Сообщение от pavlinux (ok) on 26-Ноя-12, 05:48
	>>>[оверквотинг удален] >>> цифра 0.014794913 откуда берётся?? >> Так из первого уравнения: 1 - (UNIXTIME/(10*SUM)) > или я где-то туплю, или ты это же уравнение потом используешь с этим же числом Блин, этим уравнением, и его результатом, я тебе показал, как взаимосвязаны числа слева и справа (из первого сообщения). То есть, к тебе прилетели эти три числа, берёшь их складываешь (0x2db40b + 0x8808965 + 0x517228), потом умножаешь на 10, это и будет примерный UNIX_TIME, с точностью до 1.5 минут :) --- Короче, без алгоритма CRC - все бесполезно. Аппроксимация, интерполяция, экстраполяция и т.п., для дискретных величин малоэффективны и дают лишь оценку сложности. В твоём случае алгоритм CRC должен быть полной фигнёй, коль просматривается такая зависимость. По делу тут можно только генерировать и ловить коллизию CRC, не менее 3 штук. тогда восстановишь алгоритм расчёта второго числа. И уже после - найдёшь алгоритм CRC.
	Ответить \| Правка \| ^ к родителю #14 \| Наверх \| Cообщить модератору


	17. "unixtime переведён в hex по какому алгоритму?"	+/–
	Сообщение от greenwar (ok) on 29-Ноя-12, 19:07
	>>>>[оверквотинг удален] >>>> цифра 0.014794913 откуда берётся?? >>> Так из первого уравнения: 1 - (UNIXTIME/(10SUM)) >> или я где-то туплю, или ты это же уравнение потом используешь с этим же числом > Блин, этим уравнением, и его результатом, я тебе показал, как взаимосвязаны числа > слева и справа (из первого сообщения). > То есть, к тебе прилетели эти три числа, берёшь их складываешь > (0x2db40b + 0x8808965 + 0x517228), потом умножаешь на 10, это > и будет примерный UNIX_TIME, с точностью до 1.5 минут :) погрешность великовата, конечно, там с точностью до секунды палится но вполне допускаю, что прокатит случайная генерация, как ты говорил выше: x + y = z, x < z а там уже погрешностью можно управлять, если числа внатуре рандомные вполне сойдёт за алгоритм, учитывая, что там все остальные алгоритмы вообще никакие я чё-то не могу повторить эту операцию: 1353759194 1 - ------------------------------------- 10 (0x2db40b + 0x8808965 + 0x517228) ну и так далее ... 1353759168 = b194ab + 7109279 + 517228 1353759135 = b366ed + 7384326 + 517228 Результаты такие: -0.0737443548, 0.035920647 и 0.014794913 не получаю я такие результаты в перле.. 0x2db40b + 0x8808965 + 0x517228 как эти 0x вычисляются?
	Ответить \| Правка \| ^ к родителю #15 \| Наверх \| Cообщить модератору


	18. "unixtime переведён в hex по какому алгоритму?"	+/–
	Сообщение от pavlinux (ok) on 30-Ноя-12, 05:52
	>>>>>[оверквотинг удален] > как эти 0x вычисляются? Да забей ты на эти результаты, это так... оценочная пристрелка была. Нужны суммы хотя бы 10 подряд секунд, потому как замеры с шагом в 26 и 33 секунды почти тот же рандом. :)
	Ответить \| Правка \| ^ к родителю #17 \| Наверх \| Cообщить модератору


	19. "unixtime переведён в hex по какому алгоритму?"	+/–
	Сообщение от greenwar (ok) on 01-Дек-12, 20:51
	>>>>>>[оверквотинг удален] >> как эти 0x вычисляются? > Да забей ты на эти результаты, это так... оценочная пристрелка была. > Нужны суммы хотя бы 10 подряд секунд, потому как замеры с шагом > в > 26 и 33 секунды почти тот же рандом. :) а говорил "хакнули" :) ок, вот: 1354380191 9d3af9 5288526 515632 1354380192 9d3af9 9683068 516435 1354380193 47a703 4367619 514030 1354380194 c86baf 1001106 514033 1354380195 df8d31 3593081 513232 1354380196 3f0ec5 10404958 514034 1354380201 728680 15322612 512433 1354380202 728680 9224301 513225 1354380204 abfaa7 3249889 522041 1354380205 701027 729426 510821 1354380206 701027 13903112 520433 погорячился я с "константой" ^^ блин, уравнение с 3мя неизвестными если решишь, тебе наверное нобелевку давать можно :))
	Ответить \| Правка \| ^ к родителю #18 \| Наверх \| Cообщить модератору