I recently started using Genymotion for emulating an Android image so I could test an app.  To install the app I simply dragged and dropped the apk file into the running Genymotion VM of the phone.  But for some reason the app just kept crashing with the error “unfortunately, your application has stopped”.

Running the following gave me a ton of output but this was what was the relevant bit:

$ adb -e logcat

java.lang.UnsatisfiedLinkError: Cannot load library: load_library(linker.cpp:750): library “/system/lib/libhoudini.so” not found

What in the world is libhoudini??? Some googling brought me to this post.

According to this I needed an ARM translation library so the app still thinks it’s running on an ARM processor (which it isn’t because it’s running in x86 Virtualbox hypervisor).  Simply drag-n-drop the ARM translation.zip file into the Genymotion VM and boom, you should be good to go!

If you are writing some Ring0 (or privileged mode code), say something like device drivers in Windows you’d probably be better served with a separate development machine and a deployment machine. This helps you to write poor code and still not lose hair because your development machine blue screens! 🙂

My setup was using a Windows 8.1 development machine and a Hyper-V based Windows 7 machine for debugging. You will need to execute different tasks on the “guest” (Hyper-V based Windows 7 virtual machine) and some other tasks on the development machine.  I followed many of the things from the MSDN blog post here

On your guest machine you would want to setup a named pipe and setup debug settings. To do that this is what you need to do:

Setup a virtual com port in the Hyper-V Settings (File -> Settings) , this port will be used to communicate from the host machine to the guest to communicate the Kernel debugging commands.

Now make sure that your target guest machine is configured to “listen” those commands.  Inside the guest VM, start a command shell (cmd.exe -> Run as Administrator).

Configure the bcdedit commands so that the machine can now be debugged.  Right after the 2nd command, reboot your Virtual Machine.

With the VM now configured to listen the debug commands via the COM1 port, and the debug mode on in the bootup settings, now start the WinDbg x64 on the host (using “Run as administrator”; you need administrative privileges for communication via Serial port).  In your kernel debugger on the host or the development machine (I’m assuming that these are both on the same physical hardware here).  Click on File -> Kernel Debug and you should see the following screen in the WinDbg window:

Hit Ctrl+Break or Debug -> Break and you will see something like this:

Just remember that when you break in the debugger, your guest in Hyper-V should become “unresponsive”.  The only thing is that it is not really unresponsive, its just being debugged.  Just to make sure, that you have the symbols package that is quite useful for debugging run the following command:

!process 0 0

If you see something like the following screen show up:

The following error means that the symbols are not defined.  Symbols help the debugger give more information about the commands that you are going to execute in the debugger.

**** NT ACTIVE PROCESS DUMP ****
NT symbols are incorrect, please fix symbols

To fix this, use the following commands:

kd> .sympath SRV*c:\symcache*http://msdl.microsoft.com/download/symbols
kd> .symfix
kd> .symfix c:\symcache
kd> !sym noisy
kd> .reload /o

Then again try the command: !process 0 0 and see if you get a good response.  A good response looks like the following:

With this you should be good to go! Happy debugging and writing cool Ring0 code.

I recently purchased a Proxmark3 from GeZhi Electronics. The proxmark3 client wouldn’t work. In fact the `dmesg` output did not even show the /dev/ttyACM0 device as was said all across the forum. i tried flashing the firmware but kept getting this error:

~/proxmark3/client# ./flasher -b ../bootrom/obj/bootrom.elf 
Loading ELF file '../bootrom/obj/bootrom.elf'...
Loading usable ELF segments:
0: V 0x00100000 P 0x00100000 (0x00000200->0x00000200) [R X] @0x94
1: V 0x00200000 P 0x00100200 (0x00000b38->0x00000b38) [RWX] @0x298
Attempted to write bootloader but bootloader writes are not enabled
Error while loading ../bootrom/obj/bootrom.elf

Also this is what showed up in the dmesg:

[ 7953.991935] usb 2-1.4: new full-speed USB device number 40 using ehci_hcd
[ 7959.078302] usb 2-1.4: New USB device found, idVendor=9ac4, idProduct=4b8f
[ 7959.078314] usb 2-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 7959.078321] usb 2-1.4: Product: ProxMark-3 RFID Instrument
[ 7959.078326] usb 2-1.4: Manufacturer: J. Westhues
[ 7959.078331] usb 2-1.4: SerialNumber: ChangeMe
[ 7959.080485] hid-generic 0003:9AC4:4B8F.0014: hiddev0,hidraw0: USB HID v1.00 Device [J. Westhues ProxMark-3 RFID Instrument] on usb-0000:00:1d.0-1.4/input0

Note that in the above the device doesn’t show up as a /dev/ttyACM0 device which is what we need for the proxmark3 client application to work.
So it seemed like there was an issue with the Proxmark3 not being recognized as a CDC device. So I went through the googlecode repository and went to a version of firmware where CDC was not being used. It also seemed that the flasher was the issue. So I used an old flasher to flash with the latest firmware and boom it worked! Remember to keep the button on the Proxmark3 pressed when you plug it in, and keep holding it down until the firmware update has finished.
Here are the commands:

# svn checkout http://proxmark3.googlecode.com/svn/trunk/ proxmark3
# export DEVKITPRO=$HOME/proxmark3/
# export DEVKITARM=$DEVKITPRO/devkitARM
# export PATH=${PATH}:${DEVKITARM}/bin
# cd proxmark3
# make all
# cd ..
# svn checkout -r 629 http://proxmark3.googlecode.com/svn/trunk/ ~/proxmark3-old-3
# cd proxmark3-old-3/
# make all
# cd client
# ./flasher -b ../../proxmark3/bootrom/obj/bootrom.elf ../../proxmark3/armsrc/obj/osimage.elf ../../proxmark3/armsrc/obj/fpgaimage.elf

And boom! There you … all flashed and now the device is recognized as a /dev/ttyACM0 device.

hey, we need to check that your connection works, torrent this file and md5 it

http://services.2014.shallweplayaga.me/hackertool.torrent_fe3b8b75e9639d35e8ac1d9809726ee2

The torrent file when loaded into Vuze showed that the file name was every_ip_address.txt. So I downloaded some of the file and observed the format. The format of the file was “0.0.0.1\n0.0.0.2\n…. “.

So I wrote a quick python script to calculate the md5:

#!/bin/python
import hashlib
m = hashlib.md5()
fsize = 0
a = ''
for i in xrange(256):
    for j in xrange(256):
        for k in xrange(256):
            for l in xrange(256):
                a = str(i)+'.'+str(j)+'.'+str(k)+'.'+str(l)+'\n'
                fsize += len(a)
                m.update( a )
print m.hexdigest()

The flag was “1a97f624cc74e4944350c04f5ae1fe8d”.

If you use Windows 8 x64 and when you launch the Cisco VPN Client adapter and you see the following error:
Reason 442: Failed To Enable Virtual Adapter Here’s how to fix it.
Open your command prompt in Administrator mode by right clicking at the left lower corner of the screen and going to “Command Prompt (Administrator)”. You will have to log in as an administrator. Launch registry editor by typing “regedit.exe”. Browse to “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CVirtA“. In the DisplayName key, you will see something like @oem8.inf,%CVirtA_Desc%;Cisco Systems VPN Adapter. Edit that to just say Cisco Systems VPN Adapter. Try to connect again by launching the VPN Client. It should work!