I built a new lab environment at home, using VMWare ESXi 5.0, which is a very nice product, if we expect the windows-only GUI 1GB HDD needed to install bloatware. You can do pretty much anything from there, except something that looks so important that I wonder why it’s not on the windows GUI: mapping local disks to VMs.
I made this little post as a reminder for myself rather than a full tutorial. You can get more info on http://blog.davidwarburton.net/2010/10/25/rdm-mapping-of-local-sata-storage-for-esxi, on which this post is based.
In a nutshell:
- log on vmware ESXi as root.
- locate the name of your fs in /vmfs/devices/disks/, i.e. “/vmfs/devices/disks/t10.ATA_____Hitachi_HDT725025VLA380_______________________VFL104R6CNYSZW“
- go to where you want to copy it. I suggest you create a directory in a datastore for this, like “/vmfs/volumes/datastore1/harddisks/“
- vmkfstools -z /vmfs/devices/disks/t10.ATA_____Hitachi_HDT725025VLA380_______________________VFL104R6CNYSZW Hitashi250.vmdk
- In your VM, use “attach existing virtual disk” and browse the harddisks directory on datastore.
- On linux, you will need “rescan-scsi-bus” to have you new hard disk detected.
This weekend I found a nice application to control my mac from my iPhone. It’s Remotemouse from http://www.remotemouse.net.
Unfortunately, when testing I found out that there was no pairing request nor any authentication… I just fired up wireshark to see what was happening and as expected, it’s a very dump cleartext protocol that indicates mouse gestures, clicks, and keyboard events.
I took my editor and went with this little script that connects to my mac, put the mouse on the upper right corner (over the search lense), click it and search for the terminal. Opens it and launches a bindshell.
Remotemouse is binding on all interfaces, ipv4 and ipv6, so if you’re using it and allow direct connections from the outside, you are vulnerable.
Continue reading “Remotemouse considered harmful”
During my holidays, I had plenty of time to study and reverse a program, which was completely coded in C++. This was the first time I seriously studied a C++ codebase, using IDA as the only source of information, and found it quite hard.
Here’s a sample of what you get with Hex-rays when you start up digging into an interesting function:
v81 = 9;
v63 = *(_DWORD *)(v62 + 88);
if ( v63 )
v64 = *(int (__cdecl **)(_DWORD, _DWORD, _DWORD,
_DWORD, _DWORD))(v63 + 24);
if ( v64 )
v62 = v64(v62, v1, *(_DWORD *)(v3 + 16), *(_DWORD
*)(v3 + 40), bstrString);
It’s our job to add symbol names, identify classes and set up all the information to help hex-rays in giving us a reliable and certainly understandable output:
padding = *Dst;
if ( padding < 4 )
if ( this2->encrypt_in != null )
if ( this2->compression_in != null )
avail_len = buffer_avail_bytes(this2->compression_buffer_in);
ptr = buffer_get_data_ptr(this2->compression_buffer_in);
buffer_add_data_and_alloc(this2->decrypted_input_buffer, ptr, avail_len);
packet_type = buffer_get_u8(this2->decrypted_input_buffer);
*len = buffer_avail_bytes(this2->decrypted_input_buffer);
this2->packet_len = 0;
Continue reading “Reversing C++ programs with IDA pro and Hex-rays”
A weakness ?
While reading the actual posts around the allegations of a so-called backdoor in the OpenBSD IPSec code, which would have been inserted by the FBI through a developer, some comments have been posted on both Slashdot and LWN about “long-standing bugs in SSH2”. The page which details the criticism can be found here. These comments were done by Bernard Perrot when he was patching OpenSSH to comply with the (dumb) restrictions to the use of cryptography in France by the French law.
“I often like to point out an incomprehensible weakness of the protocol concerning the “padding” (known as covered channel): in both version 1 and 2 the packets, have a length which is a multiple of 64 bits, and are padded with a random number. This is quite unusual and therefore sparing a classical fault that is well known in encrypting products: a “hidden” (or “subliminal”) channel. Usually , we “pad” with a verified sequence as for example, give the value n for the byte rank n (self describing padding). In SSH, the sequence being (by definition) randomized, it cannot be checked. Consequently, it is possible that one of the parties communicating could pervert / compromise the communication for example used by a third party who is listening. One can also imagine a corrupted implementation unknown by the two parties (easy to realize on a product provided with only binaries as generally are commercial products). This can easily be done and in this case one only needs to “infect” the client or the server. To leave such an incredible fault in the protocol, even though it is universally known that the installation of a covered channel in an encryption product is THE classic and basic way to corrupt the communication, seems unbelievable to me . It can be interesting to read Bruce Schneier’s remarks concerning the implementation of such elements in products influenced by government agencies. (http://www.counterpane.com/crypto-gram-9902.html#backdoors).”
The author says that SSH1 and SSH2 are vulnerable to covert-channel attack.
Continue reading “SSH protocol weakness ?”