Getting "#!/bin/bash: No such file or directory"

If you are getting "#!/bin/bash: No such file or directory" when trying to run a bash script on mac written on Windows, the issue is the encoding

According to http://ss64.com/osx/syntax-shellscript.html

If you get an error like "#!/bin/bash: No such file or directory", that is typically an indication that the File encoding or line endings are wrong, use an editor like VI or TextWrangler (shows line encodings at the bottom of the edit window) the script file should be Unicode (UTF-8) and Unix (LF) line endings

Solution to error updating to Windows 8.1 Update KB2919355

The other day I was trying to update my Windows 8.1 Pro to Windows 8.1 Update 1 but I had no luck.

Searching the web I found no solution until I arrived to this article http://netscantools.blogspot.com.ar/2014/04/windows-81-update-kb2919355-woes-and-my.html

Basically my problem was the order which Windows Update applies the updates. As the blogpost says  "the order of the KB's being installed on April 8 was SUPER IMPORTANT and the automatic Windows Update didn't know that so it installed the others first, then tried to install KB2919355 out of order."

What I did, was (a system backup is highly recomendable):

• Went to http://www.microsoft.com/en-us/search/DownloadResults.aspx?q=KB2919355 and downloaded all files

• Then, went to Control Panel/Recovery/Open System Restore and chose a Restore Point that was BEFORE the April 8 mess.
• Did the System Restore.
• Manually installed msu in the order above. I had each in Downloads and I simply double clicked to run them. These KB's must be installed in the following order: KB2919442, KB2919355, KB2932046, KB2937592, KB2938439, and KB2934018

Each one required a reboot. Fortunately SSD reboot time is super fast.

Enjoy it!

PS: The main update is KB2919355, so if you install it without problem but you have other problems installing the other MSU, just run Windows Update as normally

BEPUphysics (physics library) for Monogame

Last night, I was looking for a 3D physics engine for Monogame and I reached BEPUphysics.

BEPUphysics is a 3D physics library by BEPU.  It’s fast and has a bunch of cool features like constraints, terrain, static and instanced meshes, continuous collision detection, custom collision rules, vehicles, easy multithreading, yadda yadda yadda.  Full support for XBox360 and WP7 too!

Investigating BEPU website, I found that there's a work in progress version of BEPUPhysics for Monogame (the clue was a one blog post called "BEPUPhisics and XNA" and said The most likely target frameworks for the rewritten demos will be either SharpDX or, for wider use, MonoGame.) and also a twitt form the BEPUPhysics that said "The new demos application is indeed almost certainly going to be MonoGame based"

So I decided to take a look at BEPU source code repository and community-contributed forks.

I saw a monogame fork of BEPUphysics at http://bepuphysics.codeplex.com/SourceControl/network/forks/StephenOC/MonoGame and quickly download it, but my surprise was when I found that It's a windows version of BEPUphysics. But I far as I know I read it's posible running BEPUphysics on Monogame so I decided to try.

First, I openned Visual Studio and create a Windows class library. Then, I references Monogame Dll (to this test I use Windows OpenGL version) and put all BEPUphysics classes. Dont forget to set your project build propertis symbols to WINDOWS;ALLOWUNSAFE;CHECKMATH;MONOGAME

After a few build trys and removing some unuseful files, my build was succesful!

Then I create a Monogame Windows OpenGL game to test the BlocksExplodeYourCastle BEPU Demo game and I (almost) everything works out of the box! I say almost because the Monogame version of BlocksExplodeYourCastle was a lot of slower then XNA Version, but that's another history.

Also, I found a monogame build on the Monogame brach of PloobsEngine (https://code.google.com/p/port-ploobsengine/source/browse/PloobsEngine/PloobsEngine/Dlls/BEPUphysics.dll?name=MonoReach), but the BlocksExplodeYourCastle monogame version is still slow.

PS: I just run BlocksExplodeYourCastle monogame version and It runs at an acceptable speed! so I just need to make some more tests

A comic of zombies new website launched!

We are very happy to announce that, in addition to our facebook community, we have a new web site for A comic of zombies!

You can visit it from http://acoz.mylittlebets.com and stay in touch with us!

Download original Platformer Starter Kit Source Code for XNA 4

As Microsoft discontinue the XNA development for Windows 8, he removes all links to download XNA 4 starter kits.

I upload original Platformer source code to bitbucket. Here you can download original Platformer Starter Kit Source Code for XNA 4

https://bitbucket.org/hzaldivar/plaformerxna4/

Android SDK y error en VS 2010 "Could not locate Android SDK"

Hoy visitando la pagina de mono droid (http://mono-android.net/) o lo que es lo mismo la posibilidad de programar aplicaciones en .net y visual studio y correrlas en telefonos o tablets Android, me entero que liberaron  la primer version estable lo que me motivo a probarla.

Bajo el trail, instalo todo como dicen las instrucciones (http://mono-android.net/Installation), abro VS, creo un proyecto de prueba, compilo y... sorpresa "Could not locate Android SDK"... VS me estaba diciendo que no podia encontrar el SDK de Android. Inmediatamente me pongo a buscar en google y no aparecia ningún resultado que me satisfaga... sigo buscando y encuentro un par de paginas en idioma oriental y yo 0 de ese idioma. Abro la pagina y Chrome me ofrece traduccion y listo! una traduccion medio a lo cavernicola pero que me dio a entender lo que estaba sucediendo. Al parecer el addin para VS busca el Android SDK en su ruta por defecto que es "c:\android-sdk-windows" y como el SDK se instaló en otra ruta, en la carpeta AppData de mi usuario local, entonces no la encontraba.
Para resolver esto cree un link simbolico desde una linea de comando con permisos de administrador y listo!!!

>mklink /D "c:\android-sdk-windows" "D:\Users\XXXX\AppData\Local\Android\android-sdk"

El futuro de los sistemas operativos y las PCs 2: Midori y Live Mesh

Siguiendo un poco con mi post anterior y sobre el futuro de los sistemas operativos y las PCs, el tiempo no para de darme la razón acerca de adonde se dirige el mundo.

Hay rumores sobre un nuevo sistema operativo de Microsoft llamado Midori. Aunque todavía sea una idea, un borrador o un bosquejo, Midori sería el nuevo sistema operativo de Microsoft pero totalmente distinto al Windows que conocemos hoy en día ya que Internet será su centro y el software como servicio su modelo. Para conocer un poco más acerca de Midori, pueden leer esta nota del diario la Nacion titulada Microsoft prepara al sucesor del Windows o sino Googleando un poco.

Otras de las pistas que me dan la razón es Live Mesh, otro servicio de Microsoft que básicamente un servicio de sincronización de datos entre distintos dispositivos o sea que uno esta en un dispositivo, agrega un archivo al Mesh y este está disponible para ser accedido por los otros dispositivos.

Como leí en un artículo, por ejemplo, uno podría estar en su PC escuchando música, luego tiene que irse y desde otro lugar, con un dispositvo MP3 con WiFi (por ejemplo IPhone o IPod Touch) accede a su colección de música a traves de su Mesh y listo, a olvidarse de subir los archivos al reproductor o tener en cuenta si el espacio es suficiente, etc...

O sea, vuelvo a preguntar, cuál es el futuro de las PCs y los sistemas operativos? El futuro es un mundo conectado, con mi información disponible donde quiera y sin tener que preocuparme con que dispositivo la accedo, sino que simplemente la accedo y si Microsoft se preocupa por cambiar siendo el rey del mundo entonces vuelvo a nombrar la frase de Darwin "no sobreviviran las especies más inteligentes, ni siquiera la más fuertes sino sólo aquellas que sepan adaptarse al cambio."

una-al-dia (01/04/2008) Mitos y leyendas: Las contraseñas en Windows I (Tipos de ataques)

Diariamente recibo el news de una-al-dia sobre seguridad informática desde el sitio de Hispasec (www.hispasec.com)
En esta ocasión recibí uno muy interesante y que vale la pena ser reproducido. Habla sobre las contraseñas de Windows, mitos y realidades. Desde siempre se creyó que el único sistema seguro era UNIX y sus variantes más conocidas con Linux pero la gente de Microsoft estuvo trabajando en mejorar su S.O. y creo que merece la pena ser destacado.
Desde ya no soy fanático ni de uno ni de otro S.O., sólo digo que ambos tienen cosas que destacar y nombrar ventajas y desventajas (un tema muy trillado ya) excede a esta publicación.

Copio el mail tal cual me llegó y aprovecho para felicitar a esta gente que hacen un excelente trabajo.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

-------------------------------------------------------------------
Hispasec - una-al-día                                  01/04/2008
Todos los días una noticia de seguridad          www.hispasec.com
-------------------------------------------------------------------

Mitos y leyendas: Las contraseñas en Windows I (Tipos de ataques)
-----------------------------------------------------------------

Vamos a escribir algunos textos más o menos técnicos sobre las
contraseñas en Windows. Existen diferentes mitos y leyendas que pensamos
no han sido explicados de forma directa (y sin aspavientos) en la
mayoría de la literatura que hemos leído al respecto. Publicaremos de
sencilla, una serie de artículos aclarando detalles que consideramos
interesantes sobre las contraseñas locales en Windows, sus puntos
fuertes y débiles.

Cuando nos presentamos en una máquina Windows, la contraseña que
proporcionamos debe estar almacenada en algún lugar para que el sistema
operativo la reconozca y bien nos deje pasar, bien rechace el acceso.
Almacenar la contraseña y compararla sin más con la que proporciona el
usuario, sería una muy mala política de seguridad. Cualquiera con acceso
al disco duro podría robar la contraseña en texto plano. Lo que se
almacena en realidad es el resultado de aplicar un algoritmo a la clave
introducida. Esto da como resultado una "firma" (o tradicionalmente
llamado "hash"), un valor que en teoría sólo es producido por una
contraseña en concreto. Son firmas lo que siempre se comparará entre sí,
nunca contraseñas. En Windows, ese hash se encuentra físicamente en el
archivo de nombre SAM (Security Account Manager) para contraseñas
locales y en el archivo ntds.dit del controlador de dominio para los
usuarios que se validan contra controladores de dominio. Nos centraremos
en las contraseñas locales.

Para calcular los hashes que se almacenan en la SAM, Windows XP y
anteriores utilizan por defecto dos algoritmos para cifrar cada clave:
LM (por compatibilidad hacia atrás) y NTLM, más avanzado y estándar.
Vista usa (por fin) sólo NTLM y no calcula ni almacena el inseguro LM
por defecto. Un atacante necesitaría tener acceso a estos hashes (uno,
otro, o los dos) para intentar calcular a partir de ellos las
contraseñas en texto claro (aplicándoles fuerza bruta, o métodos más
sofisticados como las tablas rainbow).

Windows no añade 'sal' a las contraseñas

Uno de los problemas históricos del almacenamiento de claves en Windows
es que no 'saltea' las contraseñas. No añade, como UNIX por ejemplo, un
trozo aleatorio de caracteres a la hora de calcular el hash. Con esto se
evitaría que una misma contraseña de dos usuarios distintos, produjese
una misma firma. Esto supone un problema de seguridad, porque si un
atacante de Windows tiene acceso a estos hashes y dos son iguales, puede
tener la certeza de que esos dos usuarios tienen la misma contraseña,
incluso si no sabe cuál.

Tipos de ataque

Existen básicamente dos métodos con los que obtener estos hashes. Uno es
"offline" y tiene como barrera (evitable) una funcionalidad de Windows
de la que hablaremos en el futuro. Otra es "online" y muestra los hashes
tal cual.

Volcado de los hashes "online"

Una forma de obtener los hashes de las contraseñas es conectarse al
proceso LSASS (Local Security Authority Subsystem) como administrador (o
alguien con permisos equivalentes) y volcarlos. LSASS es el proceso que
autoriza y maneja todo el tinglado de las contraseñas introducidas en
Windows. Mantiene una copia en memoria de estas firmas contra las que
compara y valida para ofrecer el token de credenciales correspondiente.
Conectarse a este proceso y volcar los hashes "en vivo" en memoria no
es complicado gracias a programas como pwdump, que en sus distintas
versiones, permite engancharse al proceso y mostrar los hashes de todos
los usuarios locales del sistema.

Este método mostrará en claro el hash LM y NTLM con el que Microsoft
compara todas las contraseñas que le introducimos y ahora sí se podrá
realizar un sencillo ataque de fuerza bruta contra ellos.

Volcado de los hashes "offline"

Si no se tiene acceso al proceso en memoria, bien porque el sistema esté
apagado, bien porque no se disfruten de los permisos necesarios, existen
otros métodos. Como hemos dicho al principio, un lugar especialmente
delicado en Windows (equivalente al etc/passwd de los sistemas basados
en UNIX) se ubica en %systemroot%\system32\config\sam. En todo momento
el archivo está manejado y bloqueado por el proceso de sistema por lo
que no puede ser movido, copiado o accedido mientras el ordenador esté
en marcha, ni siquiera por el administrador.

Esto no impide realmente que alguien pueda hacerse con el archivo.
Existen muchas maneras de llegar a ese fichero sin pasar por Windows.
Arrancar en un sistema Linux alojado en otra partición, o cualquier otra
forma de montar particiones NTFS... (Live Cds, por ejemplo). Otros
métodos consisten en buscar otros archivos SAM diseminados por el disco
duro. Microsoft guarda una copia de seguridad del archivo en varios
directorios, como por ejemplo en %systemroot%\repair cuando el sistema
es instalado. En este directorio se encontrará un archivo SAM de menor
peso que "el oficial" y con fecha de instalación del sistema. Esta SAM
"de repuesto" no se modificará y contendrá la primera contraseña que se
le indicó a Windows, aunque el usuario haya modificado la clave de
administrador posteriormente. Este archivo no está tomado por ningún
proceso, se puede leer por cualquiera, por tanto es necesario vigilar
especialmente los permisos NTFS para controlar su acceso.

También puede existir una copia de la SAM en
%systemroot%\winnt\system32\config\sam.bak, que tampoco se encuentra
bloqueada por ningún proceso. Por último, si el administrador ha
realizado copias de seguridad, es posible encontrar comprimido un
%systemroot%\windows\repair\sam._ que se puede expandir con el comando
de Microsoft "expand".

Una vez que se ha tenido acceso al archivo en cuestión, sea con el
método que sea, se puede "volcar" su interior con herramientas como
samdump, disponible de forma gratuita desde hace años. En teoría, al
volcar este archivo deberíamos obtener los hashes LM y NTLM de las
contraseñas. Pero esto no es así. A partir de Windows 2000, Microsoft
utiliza por defecto el sistema adicional de cifrado Syskey. Samdump
volcará una versión a su vez cifrada de los verdaderos algoritmos de
cifrado de Microsoft LM y NTLM. Con Syskey como medida adicional de
seguridad sobre el sistema que almacena las contraseñas, Microsoft
introdujo una capa más de seguridad, un cifrado de la SAM que dificulta
(no demasiado si no se utiliza bien) los ataques "offline" de fuerza
bruta o diccionario sobre este archivo. Syskey estaba destinado a evitar
estos ataques (pues cifra sobre cifrado) pero en la práctica, ni Syskey
ni los cifrados LM/NTLM han aportado realmente seguridad adicional. Se
sigue dependiendo de la fortaleza de la contraseña que elija el usuario.

¿Por qué el Syskey no suele aportar realmente seguridad? ¿Cómo funcionan
realmente los hashes LM/NTLM? Lo estudiaremos en profundidad en un
próximo artículo.

Opina sobre esta noticia:
http://www.hispasec.com/unaaldia/3447/comentar


Sergio de los Santos
ssantos@hispasec.com


Tal día como hoy:
-----------------

01/04/2007: Vulnerabilidades en NSS de Sun Solaris y Java Enterprise System
  http://www.hispasec.com/unaaldia/3081

01/04/2006: Revelación de información local en Sun Solaris 9 y 8
  http://www.hispasec.com/unaaldia/2716

01/04/2005: Nueva actualización de seguridad para PHP
  http://www.hispasec.com/unaaldia/2351

01/04/2004: Denegación de servicio en manejo de ISAKMP de tcpdump v3.8.1
  http://www.hispasec.com/unaaldia/1985

01/04/2003: Tests antivirus para comprobar la protección del e-mail
  http://www.hispasec.com/unaaldia/1619

01/04/2002: Parche crítico para Internet Explorer versiones 5.01, 5.5 y 6
  http://www.hispasec.com/unaaldia/1254

01/04/2001: Ataque DoS a Website Pro/3.0.37
  http://www.hispasec.com/unaaldia/889

01/04/2000: Cómo ayudar a evitar ataques DoS
  http://www.hispasec.com/unaaldia/522

01/04/1999: "Papa", la resaca de Melissa
  http://www.hispasec.com/unaaldia/156


-------------------------------------------------------------------
Claves PGP en http://www.hispasec.com/directorio/hispasec
-------------------------------------------------------------------
Bajas:   mailto:unaaldia-request@hispasec.com?subject=unsubscribe
Altas:   mailto:unaaldia-request@hispasec.com?subject=subscribe
-------------------------------------------------------------------
(c) 2008 Hispasec               http://www.hispasec.com/copyright
-------------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)

iQEVAwUBR/LpDbXoJ59sgHAGAQJuaQgAugbu0j/w9n7KjaDyqBrJSdO9fB+dQ00l
trGgMJsmL1OfO2Tc80clxsVQgnfMcOASXG/dv2i53V9KCwnJCBy+ZRlwsJI2psb6
+ist1PM4qjLCoZ7WivisrOhvl1AZ3t8mY/looXUsz+HKKwmma8THtyRka4CZ5dhr
4IAKmnLmeg+4IB1Vjcw+l0xU19bPSXUzk3+FFn1Jlx3DMsuAnSQkM3dMad86qgjw
icpv13IjO2ortx/1gKznqneHrRbgaF6oDn82XuWMawp7luQfKrUGMP4ti6jeHyX2
LtX+QRgID4AliTl++b8auxfutuXVL18tUDMxVu4SFiX2/Kr4UVMCLA==
=geFh
-----END PGP SIGNATURE-----