Updates from August, 2012 Toggle Comment Threads | Keyboard Shortcuts

• 

  matvp 9:34 am on August 29, 2012 Permalink | Reply  

  This is a project I had to work on last semester. In the end I was able to control a colourdome-camera with a joystick, processed by a micro controller (it’s at the left of my laptop on the screenshot).

  As final-in-touch, I made it possible to login with a smartcard (note the smartcard reader on the right), an interface pops up after successful authentication. Right after, data is snooped from the joystick to track it’s movement and apply it on the camera.

  I found some code on my paste service that describes how I’ve handled the smart-card reading, it might come in handy for somebody someday. http://matvp.info/paste/view.php?id=204

  

   

  Reply Cancel reply

  Required fields are marked *

  Name *

  Email *

  Website

• 

  matvp 10:33 pm on August 28, 2012 Permalink | Reply  

  It was about time I’d collect a little more knowledge regarding engineering and technology dealing with electrical circuits, electronics in short.
  Their-for, I’ve asked a friend to assist me in creating a basic domotica system. After a few schematics and plenty of time discussing what we should do and what not, we both came to the conclusion the possibilities were endless.

  Now, we bought a micro controller as a core system for our domotica infrastructure. Several moments ago, I finished writing the payload, up to the next task. Synchronizing the data on the external “data” server (yes, that’s how we call it…) and the data actually loaded and processed by the micro controller will most likely be a heavier task. Thus, this is where the fun begins.
  Below are a few screenshots of a very basic setup where we managed to let a LED light blink based on data processed by the microcontroller. We’re aware of the fact that this ain’t much at all, nothing useful actually, but we’ve only been exploring for about an hour. Which is kind of a decent result so far.

  An ice cold beer was needed after our first successful test.

   
• 

  matvp 10:05 pm on August 9, 2012 Permalink | Reply  

  

  I am proud to announce that I have been selected as a semi-finalist in Adobe’s very own contest.
  My work that got selected is my very own mobile game. As for now, it’s mainly development plans and a small proof-of-concept (or a little more actually!).

  One of the strong aspects of my game is that it is entirely written in as3 and, yes, believe it or not, it runs on 60 frames per second (no fps drops at all!). Fully GPU driven and written in a way to use iOS’ memory to the max. In my opinion, one of the downsides for not using as3 as a mobile game development tool are the large resources needed, slower performance (both can be fixed fairly easy though) and as last, it’s time consuming to integrate existing systems. Let’s take the GPU accelerated framework Starling and the all-known physics engine Box2D. To optimize both to run smooth aside, it requires some work. This is one of the main reasons why my game runs decent though.

  

  I’m always open for idea’s. Feel free to send me an email at me@matvp.info for questions regarding this game, or basically, anything. I’m always willing to assist.

   
• 

  matvp 9:24 pm on August 8, 2012 Permalink | Reply  

  Relocate Import Address Table pointer 

  By just reading a little further how IAT exactly works, I managed to replace the pointer inside the table with my own specified function pointer. By accessing the first thunk from an imported module, it’s fairly easy to iterate through all thunks. At first, we must locate the import table, described by the PIMAGE_IMPORT_DESCRIPTOR type.

  PIMAGE_IMPORT_DESCRIPTOR get_import_table( HINSTANCE inst ) {
          PIMAGE_DOS_HEADER dos = ( PIMAGE_DOS_HEADER ) inst;
          IMAGE_OPTIONAL_HEADER opt = ( IMAGE_OPTIONAL_HEADER ) ( ( ( PIMAGE_NT_HEADERS ) ( ( unsigned char* ) dos + dos->e_lfanew ) )->OptionalHeader );
  
          return ( PIMAGE_IMPORT_DESCRIPTOR ) ( ( unsigned char* ) inst 
  		+ ( ( IMAGE_DATA_DIRECTORY ) ( opt.DataDirectory[1] ) ).VirtualAddress);
  }
  

  With the import table located from the given module, we can now easily access the first thunk. Also, we got full control of the imports, described by both the name of the thunk and the pointer within the IAT. Eventually I came up with the following code stub to access the currently looped thunk name.

  PIMAGE_THUNK_DATA thunk = ( PIMAGE_THUNK_DATA ) ( ( unsigned char* ) ret + importedModule->FirstThunk );  
  PIMAGE_IMPORT_BY_NAME importName = ( PIMAGE_IMPORT_BY_NAME ) ( ( unsigned char* ) ret + ( ( PIMAGE_THUNK_DATA ) ( ( unsigned char* ) ret + importedModule->Characteristics ) )->u1.AddressOfData );
  

  And finally, this is how you retrieve the name and the address. By unlocking the page with the PAGE_READWRITE flag, it’s possible to change the pointer to your own function pointer, resulting in some sort of API “hook”. It’s always a good thing to backup the original IAT location of the function (thunk->u1.Function) in order to call the original function and not your hook (would result in a pointless loop anyways).

  while( *( unsigned short* ) thunk != 0 ) {
  	printf( "%s: 0x%xn", importName->Name, ( unsigned long ) thunk->u1.Function );
  	thunk++;
  }

  With a few fault corrections there and then, and a little code-cleaning, I wrote a fully working concept. The complete source code can be found here: http://matvp.info/paste/view.php?id=229