Algoritmo DEC->HEX

¿ alguien me podria dar una pista sobre como obtener el algoritmo empleado en la siguiente conversión ? En la columna de la izquierda, hay una cifra en formato decimal, y en la derecha en hexadecimal. El número decimal máximo permitido, es el 202.020.

1000 = 4005

5000 = E01B 10000 = E036 15000 = 2052 20000 = 206D 25000 = 4089 30000 = 40A4 35000 = 80C0 40000 = 80DB 45000 = 00F7 50000 = 8112 55000 = 412E 60000 = 4149 ¿ hay algún método, más o menos científico, para recuperar un algoritmo, en casos no muy complejos, como este (supongo) ?
Reply to
KT88
Loading thread data ...

la siguiente

derecha en

casos no muy

Los tres dígitos de menos peso están claros, para el de más peso sería conveniente tener más muestras (incluyendo el 0).

¿El 202.020 es x456?

Saludos Miguel Giménez

Reply to
Miguel Gimenez

Me lo apunto, para que no se me olvide. ;=D

PD: ¿ ya has escrito la carta a los Reyes Magos ?

Reply to
KT88

la siguiente

derecha en

casos no muy

Los 3 dígitos de menor peso parece que son N_decimal/182. El otro no tengo ni idea. ¿Es posible conocer otros valores? p.e. 182000, 182022,

182045, 182068 182091, ...

Un saludo.

Reply to
mcesar

En el mensaje: snipped-for-privacy@individual.net, KT88 escribió:

El número de la derecha no es, obviamente, el de la izquierda expresado en hexadecimal. Aparte de la conversión de base hay algún tipo de codificación. Lo que pides no es entonces el procedimiento para pasar de base 10 a base

  1. A primera vista, no parece que la codificación se realice mediante una función matemática sencilla, dado que 1000, 25000, 30000, 55000 y 60000 tienen imágenes próximas y alejadas de otros valores intermedios; además a

45000 le corresponde un valor pequeño.

Como primera medida, te sugiero que expreses la columna de la derecha en decimal, a ver si por ahí aparece algo.

Para pasar de base 16 a base 10, no tienes más que multiplicar por las potencias correspondientes de 16 y sumar. Por ejemplo:

412Eh = 4*16^3 + 1*16^2 + 2*16 + 14 = 16686

Para realizar el proceso inverso, no tienes más que dividir sucesivamente por 16 el número en cuestión y los sucesivos cocientes, tomando luego en orden inverso, el último cociente y todos los restos. Por ejemplo:

1000 = 16*62 + 8 62 = 3*16 + 14 ====>

1000d = 3E8h

Pero te lo hace directamente la calculadora de Windows (en versión científica)

--
Saludos,

Ignacio Larrosa Cañestro
 Click to see the full signature
Reply to
Ignacio Larrosa Cañestro

Si, 202020 = A456

Más muestras:

0 = E000 2500 = C00D 7500 = C029 12500 = 0044 17500 = 0060 22500 = 007B 27500 = E097 32500 = 60B2 37500 = 60CE 42500 = A0E9 47500 = A104 52500 = A120 57500 = A13B
Reply to
KT88

Para todos esos, da el mismo resultado, 83E8. Parece que el algoritmo, tiene algún grado de resolución mínimo, porque desde 0 a 181, el resultado es el mismo, osea E000, y a 182 ya se convierte en 6001, y vuelve a cambiar a

364 = A002.

0 a 181 = E000

182 a 363 = 6001 364 = A002

Parece que SI, hay una relación con lo que tú indicas, cada 182, el resultado varía.

Reply to
KT88

¿ mandeeee ?

Yo sospecho, que el número hexadecimal, en realidad esta "swapeado", osea los 2 bloques (de 2 dígitos cada uno), hexadecimales, están invertidos, una vez aplicado el algoritmo.

Además, en la operación interviene el 182 (como dijo mcesar), puesto que cada

182 números decimales, el código hexadecimal cambia, pero se mantiene idéntico mientras tanto.

Por ejemplo, del 0 al 181 decimal, el resultado en hexadecimal, es el mismo, "E000", del

182 al 363 produce un "6001", etc..etc.. Seguramente, la operación inicial, da un 00E0 y 0160, respectivamente, y el último paso del algoritmo, simplemente los invierte (swap).
Reply to
KT88

[...]

En mi vida he conseguido completar un crucigrama.

A ojímetro me parece que el hay algo que es multiplo de 5000 (o multiplo de 5000, 2500, 500, ó 250):

Tambien cada 5000 unidades decimales hay un desplazamiento de

1B hexadecimal (27 en decimal)

12500 = 0044

17500 = 0060 22500 = 007B 45000 = 00F7

15000 = 2052

20000 = 206D

1000 = 4005

25000 = 4089 30000 = 40A4 55000 = 412E 60000 = 4149

32500 = 60B2

37500 = 60CE

35000 = 80C0

40000 = 80DB 50000 = 8112

42500 = A0E9

47500 = A104 52500 = A120 57500 = A13B

2500 = C00D

7500 = C029

0 = E000

5000 = E01B 10000 = E036 27500 = E097 ¿Puede estar relaccionado con una tabla de senos o una "lookup-table"?

Saludos.

Reply to
RF

"KT88" escribió en el mensaje news: snipped-for-privacy@individual.net...

en la siguiente

derecha en

en casos no muy

Nos puedes contar un poco mas al respecto. Es decir, que es lo que pretendes con esto ?. Como sabes la codificación ?. Es por curiosidad pero si es información confidencial, pues nada, me quedo con las ganas.

Saludos

Reply to
Fulgen

Es posible que tu problema sea de otro tipo: DEC utilizaba una codificación propia para ahorrar espacio y metía cada carácter en sólo

5 bit, con lo que en dos bytes metía tres letras. En 5 bit sólo entran las letras básicas y sólo en mayúsculas.

Si va por ahí tu problema prueba a descomponer los 16 bit en tres grupos de 5 (uno sobra) y a ver si tiene algún sentido.

Reply to
F?lix.

Bueno cuando digo DEC, me estoy refiriendo a decimal, no al sistema DEC de telefonía digital u otros sistemas o marcas. Aunque en realidad, esta conversión decimal ---> hexadecimal, incluye un algoritmo, por medio, para enmascarar el resultado, y supongo que también para ahorrar espacio, puesto que los datos hexadecimales (o binarios, según se lean), están almacenados en una Eeprom.

Reply to
KT88

Obtener el algoritmo de conversión, para implementarlo en un microcontrolador.

Tengo el software que lo calcula, pero desconozco el algoritmo que emplea.

La utilidad del dispositivo, que estoy diseñando, si que es confidencial.

Reply to
KT88

"KT88" escribió en el mensaje news: snipped-for-privacy@individual.net...

telefonía

algoritmo, por

espacio, puesto

en una Eeprom.

Pues si la conversión esta almacenada en una EPROM puede ser altamente probable que no exista algoritmo de conversión. Quizas sabiendo el concepto que maneja podria dar una idea (si, ya me has dicho que es confidencial), pero asi a palo seco me parece que es dar palos de ciego.

Saludos

Reply to
Fulgen

Si los tres ultimos digitos fueran SIEMPRE la division entera por 182 entonces el primero deberia deducirse de los otros, tal vez con un listado de varios multiplos consecutivos de 182 se pueda encontrar la relacion.

Saludos. Eduardo.

"KT88" escribió en el mensaje news: snipped-for-privacy@individual.net...

desde 0 a 181, el

vuelve a cambiar a

resultado varía.

Reply to
Eduardo

Entonces, no es posible copiar esa eeprom y hacer que un PIC la lea ?

Un saludo a todos!

formatting link

Reply to
GasparV

2 bloques

algoritmo.

182 números

tanto.

"E000", del

último paso

No, no hay swap. Los tres digitos de menos peso son directamente el resultado de dividir por 182. El de mayor peso (que siempre es par, por lo que veo) debe obtenerse de forma similar, miraré los nuevos números.

Saludos Miguel Giménez

Reply to
Miguel Gimenez

"KT88" escribió en news: snipped-for-privacy@individual.net:

¿Tienes el soft que hace la conversión? Entonces tienes el algoritmo.
Reply to
Franois

"KT88" wrote in news: snipped-for-privacy@individual.net:

Es decir, reproducir una llave por hardware. Vamos que es una pregunta de "hacking" (grupo al que se te olvido enviarla)

Es decir, estas intentando "crackearla".

Aunque es facil deducir para que sirve.

Reply to
Antonio Martos

Si tienes el software, tienes el algoritmo. Y se obtiene desensamblando.

Otra cosa es que tengas una Eprom. Entonces no tienes el software (ni el algoritmo) ... tienes el hardware y la codificacion.

Si tienes todos los valores de entrada y salida, no necesitas el algoritmo para reproducirlo. A no ser que lo necesites para alguna otra cosa.

Reply to
RF

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.