Algoritmo DEC->HEX

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).

Saludos Miguel Giménez

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

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

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,

Un saludo.

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

2. 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

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:

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:

1000d = 3E8h

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

Si, 202020 = A456

Más muestras:

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

0 a 181 = E000

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

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

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

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

12500 = 0044

15000 = 2052

1000 = 4005

32500 = 60B2

35000 = 80C0

42500 = A0E9

2500 = C00D

0 = E000

Saludos.

"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

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

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.

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.

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.

"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

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.

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

Un saludo a todos!

algoritmo.

tanto.

"E000", del

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

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

"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.

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.