Clave de licencia del Windows

Buscando cómo solucionar un problemilla con un Windows no sé cómo he llegado a este comando que, en teoría, muestra la clave de licencia del Windows que estamos utiliznado:

wmic path SoftwareLicensingService get OA3xOriginalProductKey

Al ejecutarlo desde un cmd no me ha hecho falta elevar privilegios (y eso que mi usuario es mortal). Al menos sí que devuelve una cadena que tiene la estructura de las claves de licencias. Que sea realmente la que se está utilizando... Eso ya no lo puedo asegurar. Pero como chuleta de cómo se podría sacar de llegar a serlo viene muy, pero que muy bien.

Espero que si funciona también os sea de utilidad a vosotros.

Crónica Jornada III - Navaja Negra 2019

Hoy hemos tenido el último día de las Navajas Negras 2019.

Hemos empezado con Amador Aparicio (@amapada) y Ruth Sala (@ruth_legal).

Navaja Negra 2019 - Amador Aparicio

Amador nos ha contado cómo un amigo suyo se encontró con que un enlace que le envió un servicio VTC a la hora de pedir un viaje le llevaba a encontrar información suya y más de la deseada. El problema viene en que dicho enlace no caduca por lo que es posible visualizar el contenido una vez finalizado el viaje. Además no se controla que la persona que accede a dicho enlace es la destinataria dando acceso a cualquiera al mismo. Además nos ha contado cómo demostró una hipótesis suya en la que los enlaces seguían un patrón determinado. Incluso encontró que alguien ya había estado trabajando en un script que permite localizar los enlaces válidos. De dichos enlaces, entre otros datos, aparecen nombres propios, el modelo y matrícula del vehículo empleado para el viaje, coordenadas y horas de origen y destino del viaje. Mientras Ruth ha puesto de manifiesto la problemática legal de este comportamiento y la estructura legal de la empresa la cual tiene diversas sedes con sus propios NIFs. Esto hace que sea más difícil denunciar a la empresa.

Después Santiago Hernández (@santiagohramos) nos ha hablado de detección de amenazas con imágenes.

Navaja Negra 2019 - Santiago Hernández

Nos ha dado unas pequeñas pinceladas de las clasificaciones de la IA: (semi-)supervisado,no supervisado y reforzado. Ha contado algunos problemas del machine learning. Y ya puestos en harina tenemos el concepto de "malware images": convertir malware en imágenes. La ventaja de reconocer patrones de red o binarios en imágenes es que el reconocimiento de fotografías (por no volver a usar 'imágenes') está muy avanzado. Ha hecho una demo en la que se puede ver que las imágenes, al final, se ven como las antiguas pantallas cuando tenían nieve muy fina. Ha explicado tanto las ventajas como los inconvenientes.

Aquí hicimos el desayuno.

La última ponencia la dio Raúl Siles (@dinosec).

Navaja Negra 2019 - Raúl Siles

En su charla nos ha hablado de WPA3. Qué hacen los fabricantes ahora mismo ya que lleva muy poco tiempo. Según las distintas configuraciones que ofrece (personal/SAE, Enterprise, Enhanced Open/OWE, Easy connect/DPP) algunas veces un dispositivo cliente no termina de actuar como marca la especificación. En esos escenarios que nos ha mostrado ha hecho alguna demo en la que ha conseguido, por ejemplo, sacar al cliente de la red cuando realmente una de las partes del diseño está ideada precisamente para evitarlo. Nos ha desgranado características internas de cada una de estas configuraciones.

Al finalizar la charla de WPA3 Raúl ha pasado a hablar del hackathon que organizan en el Cybercamp 2019 animándonos a apuntarnos o incluso si no podemos y tenemos alguna idea que se quiere que se lleve a cabo presentarla y seguro que encuentran a alguien que esté dispuesto a montarla en el evento.

Y ya para finalizar se han entregado los premios del CTF y han hecho un gran sorteo con merchandising de la organización y algunos libros.

Lo siguiente ha sido la comida que nos han dado en el campus.

Me lo he vuelto a pasar muy bien y todo depende de cómo me vaya el año que viene pero espero poder a tener la rutina de visitarlo.

Crónica jornada II - Navaja Negra 2019

La segunda jornada de Navaja Negra ha sido tan intensa como la primera.

Hoy he tenido la posibilidad de hablar un rato con Longinos, que ayer tanto él como Ivan nos pudimos saludar tan solo unos segundos. Además, también se ha acercado a saludarme Patxi, de la Ertzaintza.

La primera charla de hoy la ha dado Carlos Hernández (@k4rliky).

Navaja Negra 2019 - Carlos Hernández

Nos ha enseñado cómo decompilando algunos juegos como el WoW y de su estilo se puede hacer que el cliente con el que se juega cambie comportamientos del personaje que tenemos y se mueva por sitios que programáticamente no estaba pensado. Así podía hacer que el muñequito terminase alojado debajo del camino visual pero a la vez el juego le fuerza a seguir la ruta. Resultado: ningún enemigo le puede atacar (porque no le ven). También hemos podido escuchar parámetros de los juegos como "clipping" (¿quién no recuerda en Doom el truco "noclipping"?), groundLevel (que es el que fuerza este comportamiento que acabo de contar). Nos ha puesto más ejemplos con otros efectos parecidos pudiendo llegar a desplazarse a lugares secretos.

Después Mónica Salas nos ha descrito algunos problemas que dan Google y sus servicios.

Navaja Negra 2019 - Mónica Salas

Por un lado, "es imposible prescindir de los servicios de Google". Nos ha hablado de una auditoría que hizo en una empresa que implementaba MDM en la que parecía que absolutamente todas las configuraciones de los móviles estaban perfectas. Incluyendo un modo kiosco que (apenas) dejaba hacer nada. Exceptuando la configuración del teclado instalado que pedía calificarlo en Google Play. Y ahí es donde saltó la alarma porque desde ese punto pudieron ella y su equipo saltarse todos los controles implantados por el administrador pudiendo salir de ese modo kiosco. La conclusión es que hay que poner aplicaciones de total confianza y tenerlas bien testeadas aunque sean de una simpleza increíble.

La siguiente charla la ha dado Chema Alonso (@chemaalonso).

Navaja Negra 2019 - Chema Alonso y Pablo González

Una vez más ha hablado de la historia de Informática 64 y cómo consiguió con Rodol montar la empresa e ir aplicando diversas ideas que tenían por muy locas que parecieran. Y de eso iba la charla: implantar ideas locas. La que nos ha traído hoy ha sido poner un MAC antidiluviano unido a una raspberry por un puerto serie tipo mini-din (nombre puesto por mi: el circular) y conseguir subir software binario a la nube de Google que da espacio ilimitado para imágenes. Y para conseguir subir el programa lo convierten a imagen. Ha explicado cómo han hecho cada paso y han hecho una demo en vivo con toda la parafernalia necesaria.

Después del desayuno/almuerzo a media mañana le ha tocado a Josu Franco dar la charla.

Navaja Negra 2019 - Josu Franco

Josu nos ha hablado de las amenzadas basadas en usuario, que es el eslabón más débil. En un minuto nos ha contado las características de un producto que hace su empresa: Cytomic.

Al finalizar la charla de Cytomic Josu Barrientos (@bulw4rk) nos ha hablado de los análisis PCI-DSS

Navaja Negra 2019 - Josu Barrientos

Primero ha explicado qué es PCI-DSS: es la normativa que establece absolutamente todas las características que tienen que cumplir todo organismo que quiera operar con tarjetas de crédito: Asegurarse de cómo se transfiere la información, almacenamiento, funcionamiento de los sistemas, obligaciones... Qué consecuencias puede tener no cumplir con la normativa o si se tienen fallos con los clientes. Ha mostrado de una forma muy genérica cómo se haría un pentest a una organización que quería actualizar esta certificación y qué pasos siguió: alcance, descripción del contexto, búsqueda de datos (tanto en los sistemas como con OSINT, como por ejemplo, en LinkedIn), acceso los sistemas por wifi o emparejando en la red una pistola de códigos de barras... El resumen es que consiguió un acceso que no debería de haberse dado en ese contexto.

Sergio Arake (@SergioAraqueC) dio la siguiente ponencia con el título Mikrohackeando.

Navaja Negra 2019 - Sergio Araque

En ella ha descrito de dónde vienen y cómo son los dispositivos Mikrotik y su sistema operativo RouterOS y los subproductos RouterBOARD. Algunos ya sabéis que tengo uno de estos (sobretodo porque ya lo publiqué por aquí en alguna ocasión). También ha contado las distintas formas de acceder a los mismos y algunas vulnerabilidades que se han ido encontrando que permiten comprometerlos sin contar con las numerosas malas configuraciones: usuarios con más privilegios que los necesarios y contraseñas débiles entre otros. Algunas de las huellas de los hackeos son denegación de servicio contra estos aparatos, robos de información, cryptomining o incluirlos como parte de una botnet (VPNFilter). Para finalizar ha dado pautas para fortificar la configuración (muchas un tanto perogrullo, pero nunca está de más): actualizarlos siempre, el firewall bien fortificado, configurar sólo los protocolos de acceso seguros, passwords y roles como Dios manda entre otros.

Una vez más la comida que nos trajo la Organización estuvo bastante bien.

En la sobremesa Noemí Rodríguez (@Noemi_rgarcia) nos habló de las consecuencias legales de Shodan.

Navaja Negra 2019 - Noemí Rodriguez

Ha hecho hincapié en las zonas grises que hay a la hora de acceder a ciertos lugares gracias a encontrarlos a través de, por ejemplo, Shodan. Según la interpretación de las leyes podemos meternos en problemas. Ajustar las leyes que regulan lo físico a lo intangible como son los 1s y los 0s es muy difícil. Ha puesto varios ejemplos de búsquedas de sistemas SCADA, MDBUS o control de estación eléctrica y nos ha dado el término de "allanamiento informático" (artíclo 197 del CP). Uno de los conceptos que se pueden resumir es: si has cambiado algo y ha hecho pupa te cae la del pulpo. Si sólo has mirado y era una empresa, bueno, mejor no hacerlo. Si es una persona física: muy malo porque eso es "revelación de secretos" y muchísimo peor nos encontramos con datos de personas especialmente protegidas. Sobretodo esto último cuando se trata de webcams con, por ejemplo, menores.

Al finalizar los capones de qué puede pasar si accedemos a lugares sin permiso y toqueteamos Joel Serna (@JoelSernaMoreno) y Ernesto Sánchez (@ernesto_xload) han destripado dos alarmas.

Navaja Negra 2019 - Joel Serna y Ernesto Sánchez

Hemos tenido la oportunidad de ver cómo funcionan dos alarmas que han comprado por internet. Han explicado que una de ellas ofrece wifi pero con un SSID que no se puede cambiar y mucho menos la contraseña, la cual obtuvieron reverseando el apk que se utiliza para configurarla. Además, resulta que a pesar de que esa misma alarma decía que funcionaba sobre 3G la circuitería interna realmente era sólo para 2G la cual es relativamente fácil manipular con una estación de telefonía móvil falsa (si bien tampoco es tan sencillo tener una también es bastante más delito que entrar directamente en la estancia donde se encuentra el aparato en cuestión y reventarlo de un martillazo). El NFC que permiten usar resulta que es muy básico y sólo mira el ID del tag y por lo tanto, si se graba otro tag con ese ID tampoco es que sea de mucha utilidad. Al principio han hablado un poco de los sistemas propietarios de las marcas conocidas y ciertos problemillas que podrían tener si publicasen algún reversing de sus sistemas.


Después de la merienda Ricardo Narvaja (@ricnar456) ha dado una pequeña charla.

Navaja Negra 2019 - Ricardo Narvaja

En ella ha dado una pinceladas a los términos básicos para el reversing: bug, vulnerabilidad, exploiting. Definición de buffer overflow, integer overflow, use after free, format string, null pointer deferences. Y algunos tipos de exploits. Como le quedaba tiempo la gente ha tenido la posibilidad de preguntarle muchas cosas.

Al finalizar Ricardo hemos visto una vez más a Ruth Sala (@ruth_legal).

Navaja Negra 2019 - Ruth Sala

Como de costumbre nos ha ilustrado una vez más en los aspectos legales del mundo en el que nos movemos. En esta ocasión nos ha hablado de cómo se debería aplicar un pentest de ingeniería social y todas las áreas legales que deberíamos de tener en cuenta cuando tengamos que aplicar uno de estos. Sobretodo: si se va hacer telefónicamente hay que grabar la llamada. Todo tiene que estar muy bien documentado y por supuesto sin olvidarse del contrato. Nos ha contado que se hizo un CTF para el EuskalHack basado en uno de la DefCON y tuvieron muchos problemas para poderlo llevar a cabo, precisamente por el "intringulis" legal que esto conllevaba. Un área muy interesante y muy comprometida al mismo tiempo.

Y la última ponencia de hoy la ha dado Carmen Torrano (@ctorranog).

Navaja Negra 2019 - Carmen Torrano

Ha empezado dando la cifra escalofriante de dispositivos IoT que va a haber conectados a internet en 2020: 20.000 millones de dispositivos (¿20 millardos?). Se ha puesto de relieve el problema de autenticar que un dispositivo de estos es el que dice que es y que hace sólo lo que se espera de él (y no otras cosas más). Además de los orígenes y destinos del tráfico con los que trabajan. Es muy importante concienciar a los usuarios y aplicarle seguridad a cada dispositivo. Ha dado las razones por las que el machine learning es perfecto para la seguridad IoT: la escala del número de dispositivos y el hecho de de que cada dispositivo tiene una única función determinada (saliendose de esa función es que algo malo hay). Nos ha hablado de honey pots y nos ha presentado un sistema que han montado con unos cuantos pots mostrando estadísticas de ataques incluso en tiempo real.

Y hasta aquí hemos llegado a la segunda jornada de esta edición. Y nos queda otra más que seguro que es igual de interesante que estas dos últimas.

Crónica jornada I - Navaja Negra 2019

Este año 2019 he podido volver a venirme a las Navajas Negras después de dos años de ausencia. Tal y como hacía los otros años anteriores me he venido con Julián.

En la inauguración, además de Rubén, presidente de la organización, han estado otras personalidades de las instituciones de la Universidad y del Ayuntamiento de Albacete.

Navaja Negra 2019 - Inauguración

Han hecho unos agradecimientos a la organización y les han felicitado por los éxitos cosechados.

Después se ha subido al escenario Ricardo Narvaja (@ricnar456) al que la organización ha tenido la oportunidad de entrevistarle.

Navaja Negra 2019 - Ricardo Narvaja

Recordemos que Ricardo es el máximo exponente del reversing en el mundo latino. Entre las cosas ha destacar está el cómo comenzó a aprender a hacer reversing y cómo acabó fundando con otras personas Crackslatinos. También nos ha explicado todas las dificultades que encontró a la hora de hacer reversing y exploiting además de cómo se ganaba la vida.

Al finalizar la entrevista el Dr. Alfonso Muñoz (@mindcrypt) se ha subido al escenario.

Navaja Negra 2019 - Alfonso Muñoz

Ha destripado una serie de ataques ya muy conocidos sobre SSL/TLS. Las características comunes que tienen, qué lecciones se han aprendido de ellos. Para ello los ha resumido mucho ya que no se ha dejado ni uno de los más famosos. HeartBleed, Freak, 3Shake, BREACH, Poodle...). Hemos podido recordar que dependiendo del ataque se conseguía descifrar sólo una pequeña porción el tráfico capturado o gran parte si no todo. Y para ello se buscaban distintos métodos: forzar un downgrade de versión de protocolo de cifrado (o a usar uno peor), aprovecharse de malas implementaciones, ataque de relleno (o también conocido como padding) y ataques de compresión. Las recomendaciones que nos ha recordado (porque en teoría ya deberíamos de saberlas, pero en la práctica...): olvidarse de RSA y asegurarse de que el algortimo escogido hace lo que debe.

Después del desayuno Jesús Díaz Barrero nos ha hablado de SecOps y de un sistema nuevo de su compañia.

Navaja Negra 2019 - Jesús Díaz Barrero

Cuando se adquieren logs surgen problemas como gran ingente cantidad de datos que analizar que no da tiempo a verlos todos. Nos ha presentado un aplicativo: Cortext, que ayuda a minimizar al máximo el análisis de todos esos datos facilitando mucho su gestión y búsqueda de datos importantes.

Cuando ha terminado Raúl Casanova ha mostrado ataques a sistemas dispositivos conectados por bluetooth.

Navaja Negra 2019 - Raúl Casanova

Lo primero que ha comunicado es que es un protocolo (aunque es posible que no esté bien dicho lo voy a nombrar así) de comunicación que se olvida mucho a la hora de hacer pentest. Ha presetado un caso práctico con su demo en la que teníamos un dispositivo (llamémosle móvil) emparejado por bluetooth con una máquina y ha conseguido que otro aparato ajeno termine usando ese "móvil" para hacer pivoting hacia la máquina. Para ello ha usado metasploit, servicios SDP (por ejemplo, el módulo sdp_switch), Vamos: ha hecho la fase de búsqueda, explotación, post-explotación (elevación de privilegios, pivoting...) que se hace en todo pentest. Nos ha hablado de una herramienta suya llamada bluedog.

Antes de la comida Roberto Amado Gómez (@ramado78) nos ha hablado de ataques sin usar malware con herramientas del propio sistema operativo.

Navaja Negra 2019 - Roberto Amado

El título de malwareless es porque se utilizan herramientas del propio sistema operativo para hacer el ataque. Para ello tenemos los conceptos LOLBIN y LOLBAS. La idea es usar dichos comandos que los antivirus no van a dar por maliciosos para que hagan otras cosas para las que no estaban pensados. Ejemplos de esas herramientas: certutils.exe, hh.exe, esentutil.exe... Ha puesto varios ejemplos y demos: en la primera se consigue que una de las herramientas se baje algún fichero al disco (algo "no deseado" por los malos) y otra en la que usando Word se consigue ejecutar un script en VBA que no sólo se queda en memoria y por lo tanto, siempre teniendo en cuenta la persistencia de los procesos, puede hacer mucho daño sin que los antivirus se enteren. Pocas cosas se pueden hacer para detectar este tipo de ataques. Un ejemplo hubiera sido el uso de Autoruns.

Después del descanso de la comida he ido al taller Fishing phisers, impartido por Carolina Gómez y Álvaro Alonso Gutierrez.

Navaja Negra 2019 - Carolina Gómez y Álvaro Alonso Gutierrez

Hemos visto distintas formas de crear páginas para hacer phising incluyendo la generación de certificados que terminan colando sin dar alerta. La presentación ha empezado muy básica porque realmente no estaba destinada para un público con nuestro perfil. Después han nombrado alguna herramienta (además de VirusTotal) como https://www.any.run (muestra durante 3 minutos cómo se comporta un ejecutable y si hace conexiones a alguna dirección IP), Slavasoft.... Han hecho algunas demos con alguna técnica como por ejemplo próxies de certificados digitales. No voy a negar que esta me ha costado bastante (también estaba bastante cansado, todo sea dicho).

Al finalizar hemos podido merendar un poco.

La siguiente hora Alejandro Espinosa y Julio Martínez nos hablaron de dispositivos PLC (domésticos).

Navaja Negra 2019 - Alejandro Espinosa y Julio Martínez

Estos dispositivos son los que se usan para aprovechar la instalación eléctrica para usarla como red de comunicación. Estos aparatos suelen utilizar el protocolo HomePlug AV, si bien ya está la "v2". Su investigación vino porque uno de ellos instaló en su vivienda una pareja de estos dispositivos pero terminaban emparejados con los de otra vivienda de un vecino. Nos han explicado cómo se identiican entre ellos y la red virtual que terminan generando dependiendo de una serie de datos y claves que se intercambian. Dependiendo del nombre de red que se ponga y de la clave introducida pertenecerán a una red o a otra lo que llegado el caso permitiría forzar a que un aparato que se controla se pueda conectar a una red ajena. Han hablado de los términos AVLN, STA y Cco (red, estación, controlador o admin). Nos han mostrado formas en las que se pueden conseguir las claves de una red o dispositivo (como por ejemplo, calculándola a través de su MAC).

Al finalizar esta ponencia Silvia Cuenca nos ha hablado de evidencias digitales para testigos que son dispositivos Android.

Navaja Negra 2019 - Silvia Cuenca

Nos ha explicado qué es un testigo digital (tiene que identificar bien al usuario con sus propias políticas, proteger las evidencias...). Ha usado el Google Pixel 3 que tiene el chip Titan 3 (parecido al TPM) para garantizar la integridad. Según busquemos usar algunos mecanismos de seguridad como el keystore (que guarda un alias de las claves) o el Open Mobile API se podrá soportar en unas versiones de Android u otras (4.3 y 9.0 respectivamente). Además de mostrarnos una tabla de diseño de su aplicación, algunos diagramas de ciclo de vida y métodos varios nos ha enseñado una demo de su aplicación. Como no lo he explicado muy hasta allá: el sistema que ha ideado trata de hacer que el móvil recoja las evidencias y almacenarlas o enviarlas a un servidor seguro siempre mateniendo la integridad de las evidencias en mente para que no se puedan poner en duda.

Para finalizar el día Pilar Vila y Belén Pérez nos han hablado de fonrensic en sistemas industriales. Lo siento, pero la única foto que pude sacar me ha salido (oh, sorpresa! Movida). Si bien muchos de los aspectos de los que han hablado son semejantes entre el forense informático (IT) y de los sistemas industriales (OT) los problemas están en que los sistemas industriales no se pueden parar así como así. Los hay que llevan décadas sin pararse ni actualizarse y si se han producido paradas han sido planificadas durante un periodo muy, muy corto de tiempo (casi siempre un par de minutos). Una parada en un sistema de estos son pérdidas para la empresa propietaria. También está la dificultad de hacer bien las cosas porque se pueden estropear con sólo mirarlas. Y ni que decir tiene que un notario o un juez entiendan de qué va el tema a la hora de judicializar un asunto relacionado con un forense de este tipo. No hay que olvidarse de otros problemas (¿he dicho que los hay que son muy arcáicos?): muchos protocolos y dispositivos existentes cada uno de su propio fabricante y no compatibles entre ellos. Dificultad de encontrar sistemas de conexión como switches gestionados o protocolos estándares, ambientes con temperaturas extremas. Un mínimo ping puede hacer fallar sistemas internos conocidos como PLCs (que no son como los comentados antes), sistemas SCADA. El resumen es que son ambientes mucho más dispares a los encontrados con máquinas menos delicadas que si ya de por sí en un entorno con PCs, SIEMs/UMTs, etc es ciertamente complejo de analizar al vuelo en estos otros entornos va mucho más allá.

Y hasta aquí la primera jornada. Ya veré si me da tiempo a hacer una única publicación para la segunda o termino juntando un único post para los dos días siguientes.

Debian/Linux: cambiando arquitectura x86 a x64

Hace poco os conté que no me aparecía el comando shutdown una vez había elevado privilegios con su y cómo lo solucioné. Todo ello porque descubrí que mi instalación de Debian estaba como x86 cuando mi máquina era x64. No recuerdo por qué lo hice en su momento: si fue un despiste o si tenía una razón que en ese momento era lógica. Así que busqué el procedimiento, lo seguí, me dio problemas, acabé actualizando (de casualidad) a la nueva versión de Debian hasta que me encontré con dicho problema y con su solución, ahí contada.

Como dije escribiría un post contando qué procedimientos seguí. No tomé nota, pero sí he estado manteniendo las distintas pestañas que estuve viendo, por lo que lo más seguro es que alguna cosa no termine de coincidir.

También, y antes de ponernos en harina, toca el típico disclaimer: no hagas esto si no estás muy seguro. Podrías terminar necesitando reinstalar muchísimos paquetes y te volverás loco. Vamos: que casi, casi podrías necesitar reinstalar (tal y como recomiendan en algunos sitios: hacer una instalación limpia antes de hacer el cambio).

Todo lo vamos a hacer en consola con privilegios.

Ejecutamos:

# dpkg --print-architecture

Que nos mostrará la arquitecura actual (que es la que nos indica que estamos en x86)

i386

Vamos a añadir la nueva para poder tirar de x64:

dpkg --add-architecture amd64

Si ahora ejecutamos:

dpkg --print-foreign-architectures

Nos mostrará:

amd64

Ahora toca actualizar el repostorio e instalar el kernel para x64. El mayor misterio es indicar en el que queremos que tire de amd64.

apt-get update
apt-get install linux-image-amd64:amd64

Toca reiniciar. Acuérdate de seleccionar el kernel recién instalado.

Al ejecutar dpkg con los dos parámetros anteriores los resultados se intercambiarán, siendo amd64 el principal e i386 el foreing.

Desconozco por qué hacen un clean pero normalmente para estos casos yo lanzo todos: purge, clean, autoclean, etc.

apt-get clean
apt-get autoclean
apt-get purge
...

Ahora toca descargamos tres paquetes para esta arquitectura y forzar su instalación con dpkg:

apt-get --download-only install dpkg:amd64 tar:amd64 apt:amd64
dpkg --install /var/cache/apt/archives/*_amd64.deb

Tampoco estoy muy seguro si le llegué a pasar el parámetro --force-architecture en alguno  de estos dos comandos. Me suena que sí pero no recuerdo en cuál (mínimo en el segundo).

En teoría ahora podrías instalar cosas en la recién configurada arquitectura. Esto tiene su aquel. Porque según las distintas fuentes ponen un orden u otro sobre cómo o cuándo instalar los paquetes. Al final lo que hace falta es actualizar todos los máximos paquetes necesarios. Además, hay más librerías que harán falta (gcc, libgcc1, libc6...) y se te quejará mucho el sistema si no las has actualizado.

Un ejemplo para las actualizaciones y correcciones de los paquetes puede ser el siguiente...

Actualizar el repositorio:

apt-get update

En algunas de esas instalaciones te forzará a escribir algo así como "Sí, ¡haz lo que yo digo!". Además, no metas ningún typo o no lanzará la instalación. Al final hace una comparación literal de lo que busca (entiendo que se incluyen exclamaciones y todo).

Aunque será necesario corregir o reparar muchas instalaciones (ambos son los mismos):

apt-get -f install
apt-get --fix-broken install

También se puede hacer reinstalación de paquetes. Este parámetro no recuerdo si lo llegué a poner: pero revisando la ayuda de apt-get viene y seguro que en algún momento lo lancé. Más adelante mostraré un ejemplo.

Actualizar todos los paquetes del sistema con respecto al repositorio:

apt-get upgrade
apt-get dist-upgrade

Ir buscando los paquetes instalador como i386 para ver si puedes forzar a que se instalen como amd64:

dpkg --get-selections | grep i386

Y a partir de aquí, forzar la reinstalación:

apt-get --fix-broken --reinstall paqueteParaReinstalar:amd64

Y de todas formas, te encontrarás con que hay paquetes que tienen ambas versiones instaladas. Algunas las podrás desinstalar (no te olvides de poner :i386 no vayas a perder la de la nueva arquitectura).

Así, será necesario repetir muchas, muchas, muchas... muchas veces todos estos procesos de apt-get. Por eso, al ser una locura y encontrarme con tantos problemas, se me ocurrió actualizar a la nueva versión de Debian. Que por suerte llevaba apenas dos semanas publicada. Y aún así, terminé corrigiendo problemas montando el entorno con una unidad de arranque y actualizando muchos más paquetes en ese entorno.

Como podéis ver es... Vamos. Que es bastante lío. ¿Compensa reinstalar de cero e ir montando el sistema de nuevo? Pues no lo sé. Para suele ser mejor recuperar un sistema que montarlo de cero. Pero de vez en cuando toca hacerlo. En mi caso, que llevaba relativamente poco tiempo con la instalación original, no me compensaba ponerlo de cero.

Si puedo ayudar en cualquier duda del procedimiento, por favor, avisadme. A ver si hay suerte y puedo ayudar.

***
Algunas de las fuentes que tuve que utilizar:

https://askubuntu.com/questions/5018/is-it-possible-to-upgrade-from-a-32bit-to-a-64bit-installation
https://unix.stackexchange.com/questions/40463/how-to-convert-a-32-bit-x86-debian-based-system-to-64-bit
https://wiki.debian.org/CrossGrading

Debian; shutdown: command not found

Por cierto: este post lo escribiendo desde el móvil. Espero que el corrector no haga de las suyas.

Hace poco hice una actualización de mi Debian "scratch" a... "buster". Pero por intentar pasar la arquitectura de instalación de 32 bits a 64. Como la cosa no me terminó de ir del todo bien al intentar sustituir las aplicaciones me dio por buscar y encontré con que había nueva versión de Debian.

Para resumir: después de muchas sustituciones y malabarismos varios, di por finalizada la tarea. Pero mi usuario root era incapaz de apagar o. reiniciar la máquina con los comandos.

Así, buscando, me he encontrado con la solución.

El problema se da sólo al elevar simplemente con

#su

Porque ahora, tal cual está, no incluye la variable de entorno $PATH de root. Para que la incluya hay que pasar alguno de los siguientes parámetros: [- | -l (L minúscula) | --login]

Así, ejecutando:

#su -l

Ya nos incluirá en el $PATH la carpeta

/sbin

Que ha dejado de ponerla con el su de toda la vida.

Espero que si os sucede os sea de utilidad.

Elegir qué versión de Python ejecutar

En el siguiente enlace:

https://linuxconfig.org/how-to-change-default-python-version-on-debian-9-stretch-linux

nos indican cómo forzar qué versión de python ejecutamos tenemos varias instaladas a la vez.

Aunque también se tiene la opción de seleccionar el número directamente:

$python3.6
$python2.7

si ejecutamos

$python

¿Qué se ejecuta? Eso es lo que decidimos aquí. Así, además, se debería de poder desinstalar la versión antigua.

Sólo para tenerlo como chuleta. Espero que a vosotros también os sea de utilidad en algún momento.