¿Qué, Por qué y Cómo?

Microsoft TRK:0285936 Microsoft Case: 31110 Recientemente he notificado a Microsoft un "error" que he localizado en su nuevo navegador Microsoft-Edge. Se trata de un fallo en el parser del campo dedicado a la dirección o URL, el cual encontramos en la parte superior de la ventana del navegador. Aunque Microsoft no lo considera una vulnerabilidad desde el punto de vista de la seguridad del sistema, si que están de acuerdo conmigo en que puede ser utilizado para realizar un ataque de Denegación de Servicio (DoS). En fallo hace que Microsoft-Edge entre en una especie de bucle infinito que se dedica a abrir de manera continuada gran cantidad de nuevas pestañas vacías en el navegador. Esto, no solamente provoca una Denegación de Servicio sobre el equipo atacado, dado que impide que el usuario pueda navegar por internet, sino que además puede llegar a provocar una sobrecarga de la memoria (Heap exhaustion), ya que por cada nueva pestaña que se abre, se consume una ca

If you are programming a custom Windows Runtime component by hand, one of things you must to do is generate the IDL (Interface Definition Language) file. Once you have that file, you can get the metadata file (.winmd) by using the "MIDLRT" tool. MIDLRT is a command line tool used to create metadata (.winmd) files that represent the API of your own custom Windows Runtime component. You can use this nice tool as easy as writing this command: C:>midlrt filename.idl One option you can specify is the "metadata_dir" option, like in this example: C:>midlrt MyRuntimeComponent.idl /metadata_dir "C:\windows\system32\WinMetaData" When the tool MIDLRT has finished his job, you will have the following files in your current directory: dlldata.c MyRuntimeComponent.h MyRuntimeComponent.winmd MyRuntimeComponent_i.c MyRuntimeComponent_p.c Another nice tool you can use with all this stuff is "WINMDIDL". This is also a command-line tool

There is a few methods that you can use to make a C++/CX class with data-bindable capability. The most simple way is by adding an attribute to the class declaration: [Windows::UI::Xaml::Data:Bindable] public ref class SampleDataClass sealed { ... }; But, What about non-public classes? With the non-public classes you can declare the class by implementing either the ICustomPropertyProvider interface or IMap : ref class SampleDataNonPublicClass sealed : Windows::UI::Xaml::Data::ICustomPropertyProvider { ... public : virtual Windows::UI::Xaml::Data::ICustomProperty^ GetCustomProperty(Platform::String^ name); virtual Windows::UI::Xaml::Data::ICustomProperty^ GetIndexedProperty(Platform::String^ name, Windows::UI::Xaml::Interop::Type type) property Windows::UI::Xaml::Interop::TypeName Type { virtual Windows::UI::Xaml::Interop::TypeName get() { return this ->GetType(); } } virtual Platform:: String ^ GetStringRepresentation() { return this ->T

This post is about how to make date/time conversion between Windows::Foundation::DateTime and SYSTEMTIME structure types. Let's go to see by example: // First we obtain the current DateTime from Calendar class Windows::Globalization:: Calendar ^ cal = ref new Windows::Globalization:: Calendar (); Windows::Foundation:: DateTime date= cal->GetDateTime(); // Here, we are converting DateTime to a 64bit value (UniversalTime format) ULARGE_INTEGER time; time.QuadPart = date.UniversalTime; // Now convert the ULARGE_INTEGER to a FILETIME structure FILETIME fileTime; fileTime.dwHighDateTime = time.HighPart; fileTime.dwLowDateTime = time.LowPart; // And finally we get a SYSTEMTIME value by calling the FileTimeToSystemTime Windows Api. SYSTEMTIME systemTime; FileTimeToSystemTime(&fileTime, &systemTime); With C++ and once again, we are doing many things to something simple but sometimes necessary.

In Windows Store applications, for example when you want to make a shared library, it is necessary to make use of common types like Platform::String. All the public types must be types from Windows Runtime to make it possible a cross language usage of your libraries (C++, JavaScript, C#, VB). But when you want to use the C++ standard types like wchar_t or std::wstring, you're going to need a temporary conversion from Windows Runtime types to C++ Standard types. You can access the string value of a Platform::String^ object by using the Data() method like this: Platform:: String ^ ps3DModel( L"Gear" ); std:: wstring _3DModel = ps3DModel->Data(); Now, you can use the _3DModel std::wstring like another C++ standard string by using his own methods. Also, you could have converted to a "const wchar_t type": const wchar_t * _3DModel = ps3DModel->Data(); The problem is when you want to make any changes into the ps3DModel Platform::String objec

OFFTOPIC: Nota: Hoy he decidido escribir esta publicación del blog en inglés. Note: Today I decided to write this blog post in English. In a new application than I am developing for a company, I had to decide if to make use of C++/CX (C++ with Component Extension) or make all the main stuff in C++ standard and ABI/COM. All of you than have had to work with COM (Component Object Model) and fighting with the interfaces, reference count, etc. known the tricky and heavy that it can become. As an example of the easy approach using C++/CX, I am creating a new Uri object, like this: auto uriEasyWay = ref new Windows::Foundation:: Uri ( http://www.manuelvillasur.com ); assert (wcscmp(uriEasyWay->AbsoluteUri->Data(), L"http://www.manuelvillasur.com/" ) == 0); Now, I going to show you the more difficult approach using C++ Standard and  ABI/COM interfaces: HSTRING_HEADER header = {}; HSTRING string = nullptr ; HRESULT hr = WindowsCreateStringRefer

Si eres programador de C++, no te quedes atrás y ponte las pilas con C++ Moderno, porque ya viene pisando fuerte desde hace unos añitos y cada vez se está haciendo notar más. Con las nuevas especificaciones del lenguaje de programación C++ (C++11, C++14, 17 ...) vienen, como es lógico, nuevas características interesantes y poderosas que no podemos dejar de utilizar por desconocimiento. Así, aunque podemos seguir programando en C++ "antiguo", hacer caso omiso de las nuevas características del lenguaje impedirá, entre otras cosas, que seas más productivo. Como ejemplo, puedes echar un vistazo a esta función que localicé hace tiempo por Github ( https://gist.github.com/goldshtn/7433212 ) en la cual puedes ver algunas de estas nuevas características del lenguaje: # include < iostream > # include < future > using namespace std ; template < typename Fn, typename ... Args> auto do_async_with_log (ostream& os, Fn&& fn, Args&

Si necesitas saber donde se instalan las aplicaciones en Windows 10, tan solo debes dirigirte al siguiente directorio/carpeta y ahí las encontrarás: C:\Program Files\windowsapps ó C:\Archivos de Programa\windowsapps Recuerda que al igual que en Windows 8 ( como ya comenté aquí ), esta carpeta está protegida y necesitarás los permisos adecuados para poder acceder a ella.

Todo programador de C/C++ sabe que un handicap extra a la hora de diseñar software e implementarlo correctamente, es la gestión de recursos/memoria. En este lenguajete de programación es bien conocido el trabajo de punteros y reservas/liberación de memoria y los riesgos que ello conlleva si no se realiza correctamente. Encontrarse con problemas de "fugas de memoria", "saturación de recursos", "buffer overflows", UaF, además de propiciar el mal funcionamiento del software o su comportamiento no controlado, pueden dar pie a graves problemas de seguridad. Con esta idea en mente, un buen día Bjarse Stroustrup, inventor del lenguaje de programación C++, ideó una técnica de programación conocida como RAII (Resource Adquisition Is Initialization). Traducido al español, significaría algo así como que la adquisición de recursos es inicialización. La idea general consiste en dejar que sea el propio destructor del objeto el que se encargue de liberar los recurso

Just a Little reminder about using base64 with OpenSSL in Windows Operating Systems. Encoding: C:\> OpenSSL enc -base64 < file_name_plain_text.txt Decoding: C:\> OpenSSL enc -base64 -d < file_name_base64_encoded.txt

En la anterior entrada del blog comentaba que podíamos seguir principalmente dos vectores de búsqueda a la hora de localizar código vulnerable en el caso que nos ocupa (Android Stagefright). Pues bien, en esta nueva entrada me voy a centrar en el vector de búsqueda por código fuente. Dado que tenemos acceso al código fuente, la manera más sencilla de localizar alguna vulnerabilidad, sin lugar a dudas será esta. Son muchos los tipos de vulnerabilidades que puede tener un software y, una de ellas bien conocida y documentada son los "Integer Overflows" y los "Integer Underflows". Parece bastante lógico pensar, que dada la complejidad del código de un sistema operativo (Android en este caso), no será difícil que algún programador cometa determinados tipos de errores y los desbordamientos de números, enteros en este caso, no son una excepción. Como sabemos a día de hoy, desde la versión Android 2.2 hasta Android 5.1.1.r4 se han encontrado diversos fallos

Pero ¿Qué vectores podemos/debemos seguir para localizar este tipo de vulnerabilidades? A priori, yo me decantaría principalmente por dos vectores muy distintos y, para los cuales se tendrán que emplear técnicas muy diferentes. VECTOR de búsqueda 1 Ante todo hay que tener en cuenta que Android es un proyecto Open Source, lo que significa que tenemos acceso a su código fuente. Así, un claro vector de búsqueda sería por esta vía, es decir, analizando el código fuente en busca de aquellos 'Bugs', descuidos y metodologías, técnicas y funciones inseguras utilizadas por los ingenieros del software. Por tanto, un poco para empezar a buscar es el repositorio del código fuente de Android, el cual podemos encontrar en la siguiente URL: https://android.googlesource.com/ Como podemos ver en dicho repositorio, la cantidad de código fuente con la que tendremos que lidiar es claramente INMENSA, entonces ¿por qué camino debemos ir? En el caso que nos ocupa sobre StageFr

Antes incluso de hablar sobre la existencia o no, de los exploits/POC correspondientes, que sin duda a estas alturas ya los hay, sería interesante saber que es exactamente "Stragefright". Pues bien, Stragefright es básicamente el motor de reproducción de medios digitales que incorpora Android de forma nativa. Este componente software, incorpora ya una serie de codecs de-facto para la reproducción de la gran mayoría de los formatos multimedia más populares y generalizados. En el siguiente digrama (cortesía de Google), se puede ver como interactuan las aplicaciones de reproducción o gestión de medios, con el framework multimedia nativo de Android (Stragefright). Se distinguen las siguientes partes o capas en dicha arquitectura, a saber: - El framework de aplicación, es donde se encontraría el codigo en si de la aplicación de usuario, la cual, haciendo uso de las APIs correspondientes (android.media) pueden interactuar con el hardware multimedia. - Binder

Aquí uno de esos post que sirven para saciar la curiosidad de los "mente-inquieta", que gustan de conocer las interioridades de todo aquello que les rodea. En esta ocasión algo pequeñito y sencillo a la vez, pero de vital importancia en la tecnología que nos acompaña cada a día en nuestro entorno, el condensador electrolítico.