Mensajes

Si el término es ambiguo excepto para quien no entiende la sutileza.
Algo ejecutable se carga en memoria sin modificación. Algo cargable precisa una preparación.
Quiénes pasaron de un sistema a otro, no pensaron en su definición, sino en las ventajas que ofrecía...

Fíjate por ejemplo que igualmente el término compilar, tampoco significa lo que se hace, sino que procede de los tiempos de las tarjetas perforadas... para ejecutar el programa (que tampoco existía ese concepto, sino el de cálculos), exigia reunir en orden todas las tarjetas que contenían las instrucciones, o sea compilar las tarjetas.

... pero en fin, el nombre se queda aunque luego cambien cosas, porque después de todo el fin perseguido no ha cambiado y aunque en origen un nombre definiera un proceso más o menos específico, al final el nombre se populariza y se asocia al fin perseguido, matiz que con el tiempo se desdibuja y hasta se pierde.

... seguimos llamando 'ordenador, calculador, computador', aún cuando hoy día realizan muchas mas y diversas tareas que las que inicialmente tenían asignadas cuando se acuñó el nombre. Curioso que la 'maquina de escribir', siempre fue eso...y cuando se integró al ordenador, cambió a 'teclado', aún cuando las teclas principales mantienen el mismo modus operandi (salto de línea, retorno de carro, etc...).

Lo cierto es que China hizo lo mismo (que Rusia acaba de hacer), en 2017 (si mal no recuerdo). Aunque no se hizo eco de la noticia en las 'noticias' (o aquel día no las vi)...

Recuerda que windows tiene el SFC (System File Checker)... que opera en tiempo real. deberías revisar el sfcfiles.dll...
Si por ejemplo eliminas x dll de windows, la rescata de alguna carpeta donde tiene copia (por ejemplo en XP (creo que operas con XP, no?), se suelen localizar en servicepackfiles, dllcache, prefetch o incuso puede que de algún 'cabinet'...)
Si cambias todas las copias al únísono (esto es, offline), no tendrá de donde reponer la copia adecuada, lo que no quita que el sistema sepa que esa librería no es genuina. Es preferible que antes de eliminarlas las comprimas en un fichero con contraseña manteniendo las rutas de procedencia.

Y sí, un S.O. hace bien en asugrarse que las dll que tiene no son suplantadas. De hecho debiera ser más estrictos (en mi opinión). No es tanto porque uno no pueda hacer sus cambios en sus equipos, si no para que nadie pudiera hacer cambios en esos equipos que no son suyos.

Ultimamente preguntas mucho sobre PE, te recomiendo el libro:
"Linkers and Loaders" de John R. Levine.

p.d.:
Por supuesto, hay posibilidades de que el cambio que realizas inutilice alguna funcionalidad (en vez del cambio esperado), incluso el arranque si éste es dependiente de ello.

H0st1@s... (Guau, para aprensivos) esta mañana, he sentido un ruido rarísimo en mi tejado... sonó cono una piedra muy pequeña en el techo de mi habitación (los gatos se sobresaltaron y uno de ellos estuvo alerta varios minutos), pero lo raro es que sonó muy fuerte como si hubiera caído desde varios metros... cuando entre las tejas y el suelo que lo soporta (el techo de mi habitación) apenas habrá un metro de altura... pero el ruido era demasiado fuerte para una china supuestamente desprendida de debajo del techo que es lo que supuse... algún pderusco más grande desde esa altura si generaría ese volumen de ruido, pero sonaría más grave, no como una china... francamente no le encontraba explicación, así que miraré al llegar a casa ver si hay un agujero en el tejado... y como lo haya Putin,  tendrás una denuncia 

Pascal es un muy buen lenguaje sobretodo de cara al aprendizaje, de hecho Wirth lo diseñó precisamente para eso, y se convirtió (en su momento) en el lenguaje de facto usado en las universidades.
Uno de los mayores aportes que supuso (que pasa desapercibido para usuarios 'normales') es que el código conduce al compilador, es decir la especificación del lenguaje no difiere demasiado entre el código escrito y el compilado, lo que lo une más íntimamente al hardware y sobretodo ayuda a encarrilar más acertadamente a los algoritmos a ser más exactos y eficientes, de lo que hasta ese momento suponían ser otros lenguajes de programación de alto nivel. O dicho de un modo simplificado, es el primer lenguaje de alto nivel que no dista tanto de un lenguaje de bajo nivel. Todo ello se debe a que es un lenguaje estructurado... hasta entonces los lenguajes eran muy complejos (y a menudo muy extensos) y los compiladores aún mucho más.
Ahora, tiene serias limitaciones (respecto de lenguajes modernos).
C es un lenguaje muy complejo, básicamente es el Frankestein de la programación, cada idea nueva que aparece y sale 'rentable' se endosa en una nueva versión sin apenas tocar nada del resto del lenguaje y con una curva de aprendizaje largo. Aunque cuando uno conoce a fondo un lenguaje, aprender otro es más sencillo que partir de cero (conocimientos), para C esto no se aplica al 100%, pero si uno tiene suficientes conocimientos de  ensamblador, hardware y sistemas operativos, resulta más asequible. Viniendo de Pascal, yo te recomendaría quizás Delphi (sigue activo), sería una actualización, un punto intermedio que te acercaría más a C pero sin salir de Pascal.

lo que me dices es como una tecnica de aprendizaje supervisado para predecir una función a partir de datos de entrenamiento.

No. No se trata de aprendizaje supervisado... No te dejes arrastrar por eso de 'alimentar'... pues en el sentido de entrada de datos, de suministrar los datos.
El algoritmo de silabación todo lo que debe hacer es una de dos opciones (pueden diseñarse para que sea uniforme y proporcione la misma respuesta).
- Pasado un string señalar si todo el string recibido representa una sílaba o no.
- Pasado un string (por ejemplo una palabra), reconocer una sílaba hasta donde logre reconocerla como tal (y lo más larga posible*) e indicar en que punto del string ha terminado esa sílaba.

Esa diferencia en el diseño de la respuesta del algoritmo, puede enfocarse como decía en función de la entrada que se le pretenda proporcionar.
El primero se presta a la combinatoria (A-ZZZZZZ, esto es A-Z, AA-ZZ, AAA-ZZZ,AAAA-ZZZZ, AAAAA-ZZZZZ, AAAAAA-ZZZZZZ). Este modo garantiza obtener absolutamente todas las sílabas que reconoce el idioma español (así sean raramente usadas (por ejemplo 'lex' como en 'sílex' o 'xi' como en 'léxico').
El segundo se presta a pasar como entrada un texto muy largo indicando un índice desde el que mirar y devolviendo el funto final reconocido, así el tramo intermedio entre ambos es la sílaba reconocida (si devuelve true, claro dada una entrada (que contiene la palabra) como  'ZZZZZZZZZZZZ', avanzaraía hasta el final sin descubrir ninguna sílaba.

Es decir hay dos algoritmos uno que determina si un string entrado es una sílaba o que avanza hasta reconocer una sílaba (o saltar si no lo es) y el algoritmo que le entrega esos strings al algoritmo de silabación y que cuando le devuelve una sílaba 'formada' que aún no contiene la añade a la lista de sílabas del español...
Esto, una vez completo el diccionario de sílabas, ya está no se necesita más... de hecho hasta e sprobable que buscando se encuentre algún fichero con todas las sílabas dle español (o casi todas). El primer método (descrito en este mensaje, es decir el de combinatoria) recogerá todas, e tanto el que recibe textos, recogerá solo las sílabas que consten en ese texto, luego para asegurarse que tengan una cantidad lo más amplía posible conviene que reciba muchos textos... las que finalmente no aparecieren es claro que son poco probables.
El mayor problema del alimentador por combinatoria, es que serán enormemente más las combinaciones (de hasta 6 letras) que no son sílabas que las que sí lo son. s

* Sea la palabra 'constructor': lógicamente el reconocedor podría aceptar 'co' como sílaba, pero la idea es dar la sílaba lo más larga que sea posible, luego 'con' también es una sílaba, peor ¿puede ser aún más larga?. Si la sílaba finalmente es 'cons'.

Veré si el fin de semana hecho una ojeada a las reglas vigentes de silabación de la gramática española para sugerir un pseudocódigo del algoritmo preciso...

mi idea es hacer, teniendo una lista de silabas directas, indirectas y trabadas apartir de esas listas probar todas las combinaciones posibles y tratar de formar palabras rapidamente ...

Precisamente por eso te digo, que obtener una lista lo más exaustiva de la sílabas reales, es algo que se hace de una vez y ya, no hay que ir retocando cada cierto tiempo nada. Es una cantidad finita. Un diccionario sin necesidad de crecer...

Finalmente a la hora de aplicar contraseñas, se aplica como te indicaba unos mensajes más arriba, concatenado sílabas de modo recursivo, que es si cabe más eficiente que leer una contraseña de fichero. Esto hace innecesario almacenar diccionarios de Gigabytes o Terabytes, basta ese pequeño diccionario de sílabas.
Es luego en este algoritmo donde uno puede operar para condicionar de formas más complejas... yo sugería (por ejemplo) la inclusión de dígitos (delante, en medio o detrás de una sílaba)...

Despues de terminar de desarrollar el programa para generar diccionario, dejare de publicar diccionario y traere el programa, me voy a poner mas tiempo a desarrollar el programa mejor.

Es lo mejor...
Esas variaciones a base de poner prefijos o sufijos, solo sirve para generar diccionarios interminables en ficheros y que jamás serán 'completos' al gusto de uno...

El diccionarios de sílabas lo creas una vez (con el programa para desarrollarlas que si funciona bien también se ejecutará una única vez), el tiempo entonces lo gastarás a futuro en simplemente filtrar el modo en que las sílabas se combinan para producir (en tiempo real, generar y usar), combinaciones específicamente acotadas...

A pesar de lo que te hayan dicho, no. No es cierto que todos los cables sena iguales...

No existe el 'cable definitivo' y seguramente jamás exista. _Cada pocos años aparece un nuevo cable UNIVERSAL, que lo será hasta que aparecezca el siguiente reclamando lo mismo.

Si tu cable está bien, entonces es el conector del móvil, y sí. En un móvil siempre están soldados. Hay dos razones para ello: Primero el espacio. si porta un zócalo extraíble en vez de soldado, ocupa mucho más y además supone un precio mayor por necesitar un 'chisme' más en el dispositivo. La miniaturización tiende a que cada vez esto sea lo más diseñado por los fabricantes (basta recordar que hasta hace unos años era raro encontrar un móvil que no tuviera la batería extraíble con la carsa trasera, o tras la misma, ahora lo raro es lo contrario, o bien la carcasa es complicada de extraer). Y en segundo lugar, porque para el fabricante es de interés si cualquier daño en el mismo, inclina al usuario a comprar otro nuevo en vez de arreglarlo, aumentan sus cuentas.

El conector en el dispositivo suele dañarse por el mal uso que se le da... se estrae el cable a tirones a menudo ni siquiera corectamente orientado... se duerme con el dentor de la cama (conectado al cargador), se lo usa masivamente mientras se está cargando... con cada tirón a derecha, izquierda se va dañando primero gana holgura y finalmente ni queda encajado. Es una lástima que los conectores de los móviles no se diseñen mucho más resitentes que el del cable (el rempleazo del cable siempre es más barato).

En general los cables tiene conectores machos a ambos lados... y los dispositivos conectores hembras (es bastante malo que un dispositivo tenga salientes, que tropiecen con cualquier cosam por eso siemnpre son entrantes y de ahí que reciban el nombre de hembra). Cuando el cable tiene uno de los conectores hembra suele ser porque actúa como alargador o conversor (se conecta a otro cable)...

Lo mejor que puedes hacer si tienes dañado el conector del móvil es llevarlo a la tienda más cercana que tengas de tu operador (orange, vodafone, movistar, etc...), les explicas el caos y ellos te señalan si pueden arreglarlo y a cuento asciende el coste. Normalmente por ser su cliente, la tarifa puede ser más realista (y sobretodo o al menos garantizada) que si acuedes a cualquier tienda del barrio que se dedique a reparar móviles... (estas tiendas dependen fuertemente de la habilidad y honestidad de quien la lleva).

Lo que estás haciendo no es generar sílabas en todo caso serían dígrafos.
En realidad, lo de menos es el nombre, sino la funcionalidad, y desde luegro, de ese modo no podrás inscribir sílabas muy específicas pero también muy presentes como por ejemplo las que aparecen en la palabra 'constructor', sus sílabas son 'cons-truc-tor', pero t código no generaría los digrafos 'ns' y 'tr' porque solo une silabas con consonantes y viceversa, además eso tolera ciertas construcciones que muy probablemente no se den en palabras (ciñéndonos al caso tu premisa del uso de palabras), o aunque se den su frecuencia sea realmente escasa.

En realidad tu algoritmo de sílabas debiera generar las sílabas que toleran las reglas de silabeo de la gramática española, es decir tu algoritmo debiera considerar dichas reglas e implementarlas en un algoritmo, para poder reconocerlas.
Luego generalas todas supone elegir una entre (al menos) dos estrategias...
- Alimentar el algortimo con pseudosílabas generadas a partir de un algoritmo de bucles (el anterior que te dí vale a condición de que el array contenga los caracteres a-z, y el largo vaya pasando por 1, 2, 3 ,4, 5 y 6 (en español es imposible generar sílabas más largas de 6 y cuesta encontrar ejemplos de estas, incluso de 5)). Cada pseudosílaba es una proposición que el algoritmo de silabeo demuestra si pertenece o no a la gramática española, si el resultado es favorable se añade a la lista.
En este caso, el algoritmo recibe pues un string que es una posible sílaba y el algoritmo debe demostrar si lo es o no.

- Alimentar el algoritmo con textos procedentes de obras en español.
En este caso el algoritmo lo que recibe es un texto que se compone de palabras  y el algoritmo, lo que hace es la partición silábica. Luego con cada sílaba hallada se localiza si ya se tiene almacenada, en caso negativo se añade a la lista.

Ambos algoritmos difieren muy poco. En el primero recibe un string y verifica si al completo es o no una silaba, en el segundo se recibe una palabra y va tomando caracteres formando así sílabas (saltando espacios y caracteres de puntuación cuando aparezcan), con cada una encontrada devuelve la posición alcanzada en la palabra (o devuelve la sílaba), para seguir en una nueva llamada a continuación del punto previo.
La mayor diferencia no reside en el algoritmo de silabeo (que es el mismo en ambos casos), si no en el que alimenta a dicho algoritmo.

Desde luego el algoritmo de silabeo tiene su trabajillo (no es complicado peor lleva su tiempo), primero hay que empaparse (ponerse al día y refrescar lo olvidado) de las reglas de silabeo de la gramática española (desde mis tiempos de estudiante, ignoro si alguna de estas reglas ha cambiado, como sí han ido cambiando las reglas de ortografía (las 'reglas' de cualquier índole, tienen un carácter de 'constante, en el tiempo', pero con tantos y tan frecuentes cambios, más bien dichas reglas ya, parecen 'variables, cada pocos años'))... y luego para hacerlo eficiente en velocidad lo adecuado sería diseñar el automáta para reconocer las sílabas en base a dichas reglas. Esto también puede resultar complicado si las capacidades como programador son limitadas...

...en el pseudocódigo anterior te había dejado una 'tarea' a tu esfuerzo, cuando lo vieras. Debe haber dos condiciones de salida, una cuando acaba el análisis y no se encontró nada (esa salida está), y la otra cuando la contraseña coincide que también debe acabar, que es la que omití... pero viendo tu código y leyendo tus explicaciones, entiendo que tu nivel de programación es el que es, luego ve a tu ritmo, a tu manera si no logras entender más allá.

Busca por ejemplos con las funciones:
MsgWaitForMultipleObjects, CreateWaitableTimer y SetWaitableTimer.

[con un simple bucle recursivo, te adjunto debajo el pseudocódigo para esto]

...Pero si tienes una mejor idea de añadir esta combinación me gustaría saberlo...

Pués sí.
Si tu consideras que la mayoría de contraseñas utiliza sílabas del alfabeto humano, entonces lo razonable es que primero crees un algoritmo para obtener las sílabas del alfabeto humano (tampoco sobra en ese supuesto, añadir dígitos, pares y tríos de dígitos, ya que esto comulga dentro de esa consideración). Este debería ser a lo sumo tu diccionario, que al ser de un tamaño 'aceptable', incluso puede residir en memoria (se carga al iniciar el programa). En vez de andar disperso con !!!!teces!!!! que poco o nada aportan y que hacen tu 'programación' infinita en el tiempo.

Tras tenerlas todas enumeradas, luego sería cuestión de combinarlas entre sí (ese array cargado en memoria) hasta formar el largo requerido (3-4-5-6 sílabas, con un simple bucle recursivo, te adjunto debajo el pseudocódigo para esto)... pero esto último ya 'en combate' ... para probar (debug) que enumera bien las combinaciones de sílabas sí es acertado pasarlo a fichero y comprobar el resultado.

Código [Seleccionar] Expandir


funcion Combinar(entero numSilabas, entero MaxSilabas)
   numsilabas +=1
   Si (numsilabas = Maxsilabas)
       por cada silaba en arrayDiccionario
           stackClave.Append(silaba, stackClave.Size)  // <--- el parámetor size, en realidad es innecesario, se añade exclusivamente para clarificar.
           #si debug=TRUE
               GuardarAfile(stackClave.toString)
           #sino
               probarClave(stackClave.toString)    // <---- creada la contraseña se envía a donde haya que enviarla...
               // o devolver por evento, si la función que prueba la clave no está junto a esta.
           #fin si
           stackClave.Size -= silaba.size
       siguiente
   sino
       por cada silaba en arrayDiccionario
           stackClave.Append(silaba, stackClave.Size)
           llamada a combinar(numSilabas, MaxSilabas)  // <--- aquí la llamada recursiva.
           stackClave.Size -= silaba.size
       siguiente
   fin si
fin funcion


Como se puede ver es muy simple y es eficiente, luego generar la clave a medida que se necesita, hace innecesario guardar diccionarios enormes a fichero.
la variable 'stackClave', puede ser un simple array de bytes-chars que actúa como un stack, con un largo máximo de modo que pueda alojar el número de sílabas 'maxSilabas' de la más larga (así no hay necesidad de generar con cada clave un nuevo array). O bien una clase...
En cualquier caso se requieren unos métodos para manejar dicha variable de stack...
Una 'Append' que añade una silaba al final del size actual y actualiza size, tras usarla, no hace falta borrar nada, solo restar el 'size' de la última sílaba 'append'...
En fin, a buen entendedor pocas palabras bastan.

....y con esto ya tienes la mitad de tu problema, lo otra mitad es generar las sílabas del alfabeto español (o inglés o de otro idioma del que conozcas lo suficiente de su gramática).

¿Te parece estúpido usar el Top2Billion-probable-v2.txt (1.973.218.846 contraseñas) o el rockyou2021.txt (8.459.060.239 contraseñas)?

Sí.
No es práctico usar diccionarios gigantes (desde fichero) con fuerza bruta.
Dado el caso específico, tiene sentido tener un conjunto (pongamos 100mil-10millones) de contraseñas preseleccionadas en un fichero.

Si el diccionario es gigante (como esos monstruos de 2mil y 8 mil millones), es preferible crear las secuencias en el momento justo de usarlo sin tener que almacenar nada a fichero.
Además dependiendo del sistema, si la cadencia de pruebas por segundo no es muy elevada, el tiempo para probar por fuerza bruta esa enorme cantidad, puede hacerlo inasequible.

Si quieres ver lo 'bueno' que son tales diccionarios, basta que anotes en un papel media docena de contraseñas que tú mimo uses y las busques en ellos.
- Si no aparece ninguna... debieras preguntarte porqué van a aparecer las de otros.
- Y si te aparecen demasiadas, es señal de que tu patrón para crear constraseñas, sigue eso, un patrón demasiado 'cuadrado' y elemental.
En definitiva, si tus contraseñas tienen un mínimo de 16 caracteres (muchos sitios, programas, etc... limitan el tamaño máximo a una cantidad ridícula, lo que es un error), la probabilidad de que un dicccionario aunque sea de 8 mil millones la contenga es prácticamente nula, salvo que como usuario se siga un patrón torpe.

Es cierto que aún no todos los sitios, limitan por hardware la cantidad de intentos por segundo. Así que aún será posible 'cazar' contraseñas durante alguns años... a incautos. Los programas no debieran limitarlo salvo que se usare el propio algoritmo del programa.