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 ?”
When designing the new libssh architecture, we decided to make it completely callback-based, even internally. This provide cool features, like the possibility to extend libssh without recompiling it, or executing more easily asynchronous or nonblocking functions. Libssh 0.5 will run as a state machine, which listen for packets, and then calls callbacks from the packet type. The handlers will evaluate the current state of the session and what to do with packets. Sometimes, the state of the session itself changes as the result of a packet (e.g. when receiving a SSH_AUTH_SUCCESS packet).
A sequence diagram of a synchronous function such as authentication or simple channel read can be systematized as following:
What’s happening is pretty straightforward. The thread X is waiting for a specific packet x (or more precisely, the internal state change caused by packet x). It calls a function called ProcessInput (this is a simplification) which itself locks itself and tries to read packets from the socket. After a packet has been read, the callback for the packet (in this case, x) is called, which updates the internal state of the session.
ProcessInput returns after reading one packet. X verifies that the state changes to x, otherwise, it simply tries a ProcessInput again (not on the drawing) until it receives a state change it can process. Continue reading “Threading design pattern ?”
Hey there, you may know I am a developer of the SSH Library libssh. Last week, a post on the libssh mailing list was reporting a connection problem under Redhat RHEL 4.8. It seemed that the new cipher aes128-ctr, recently implemented in libssh, had a little problem…
This bug looked strange, firstly because we never ever had any cryptographic problems within libssh, secondly because the debugging did not report something broken :
 Set output algorithm to aes256-ctr
 Set input algorithm to aes256-ctr
 Writing on the wire a packet having 17 bytes before
 17 bytes after comp + 10 padding bytes = 28 bytes packet
 Encrypting packet with seq num: 3, len: 32
 Sent SSH_MSG_SERVICE_REQUEST (service ssh-userauth)
 Decrypting 16 bytes
 Packet size decrypted: 44 (0x2c)
 Read a 44 bytes packet
 Decrypting 32 bytes
2010-04-12 13:14:54,211557; 1126189408 procSrvAuth; Did not receive SERVICE_ACCEPT
While giving on the OpenSSH side :
sshd: debug1: SSH2_MSG_NEWKEYS sent
sshd: debug1: expecting SSH2_MSG_NEWKEYS
sshd: debug1: SSH2_MSG_NEWKEYS received
sshd: debug1: KEX done
sshd: Disconnecting: Corrupted MAC on input.
Continue reading “Debugging a cryptographic bug in libssh…”