SSH and SFTP Servers on OpenBSD 6.1 – Part 1



In this tutorial, we will continue to learn about OpenBSD 6 by setting up a SSH server alongside a SFTP server. As most of you may know, SSH is essential for remote administration. Nowadays, more and more network administration is done remotely and it is more important than ever to properly configure and secure outward facing services. Additionally, we often need to transfer files, either for patches, reuse configuration files or install additional applications, especially if your OpenBSD server is not Internet-accessible. In a later post of this tutorial, we will use a specific form of port knocking to hide the presence of our services to background scans to prevent brute-force and dictionary attacks. However for now, we will setup our SSH and SFTP servers. A companion video is available on YouTube.


While OpenBSD makes it easy to enable SSH and SFTP, we will do some additional preparation for increased robustness. First we will create the appropriate users and groups and then we will install each of these services within their own chroot directory to limit damage should ever these services get compromised. Once that done, we’ll enable the SSH daemon, including the internal SFTP service, and make sure they are accessible and working properly. Once done, we will customize and harden their configuration. For the purpose of this post, we will assume that you have a fresh install of OpenBSD 6.1 as if you just finished the steps listed in this previous tutorial, i.e. SSHD was NOT enabled during installation.

Creating the Chroot Directories

While optional, enclosing your services in chroot, especially the one exposed to external hosts, is an excellent security practice. Ideally, they should even be on their own partition. To keep the scope of this post on SSH and SFTP, we will simply create a new tree node and setup our chroot containers from there:

We will then install the basic required files from the OpenBSD 6.1 CD to create our chroot. Within the SSH chroot:
# mount -t cd9660 /dev/cd0a /mnt

And unarchive the base packages unto our chroot:

In any chroot, we need the /dev  directory to exist and populated with the required sub directory. Fortunately, OpenBSD makes it easy for us to do so using the MAKEDEV script:

Finally, we will link the shared libraries required by most programs with out chroot and enable our new sandbox:

The chroot directory doesn’t require any special action since it doesn’t need to execute any program. The only thing left to do now is to set the ownership and permissions:

Creating the users and groups

This step is optional if you intent to have this server only for your own personal use or a very few selected people. However if you expect your user base to grow and have different permissions, having groups makes it so much easier to manage your server while ensuring tighter controls on permissions. We’ll create 2 groups: ssh-users and ftp-users. Within each of these groups, we will have a single user. We’ll create ssh-user for accessing the SSH service and ftp-user for accessing the SFTP service by using the useradd and groupadd commands:

While adding groups requires no explanation, it is important to note that ftp-user requires some specific parameters. Namely, the shell is set to /sbin/nologin. FTP are not required to use a shell and are limited to the FTP server, which is actually integrated into the SSH daemon.

Setting up SSHD

In many cases, sshd will have been enabled during installation and automatically starts at boot. If you are unsure, you can quickly verify if the sshd is running:

If there’s no output, then the sshd is not started. Let’s quickly check that SSH works by first enabling and starting the service, and then testing it out. To enable the service, use the rcctl command:

Then start the daemon to actively listen for SSH connections:

And confirm that the SSH daemon is listening by using netstat:

And now, lets try to connect to our SSH service using the IPv6 loopback interface using  # ssh root@::1 . After entering your password, you should be greeted in your new shell.

Without much work, you already have a solid SSH server available within minutes with OpenBSD. However, let’s configure it further to our needs. We’ll stop the server for now:

First configuration items we will change is to disable remote root login and allow users part of the ssh-users group to access SSH. All configuration for the SSH and SFTP services are done thru the /etc/ssh/sshd_config file. Before editing it, you may want to make a backup to your /root directory. We will edit using the vi editor:

The first change we will make is to prevent the root account from using SSH. We’ll do this by setting the PermitRootLogin option to no. If the line is commented, uncommented it by deleting the ‘#‘:

Next we’ll specify SSH to use our specially created chroot sandbox for any SSH connection by adding or setting the following property:

And the last thing for now, we’ll allow only users part of the ssh-users and ftp-users groups to use SSH by setting this line in our configuration file:

Save you configuration and let’s restart our SSH server using rcctl to confirm these basic settings:

First, we should not be allow to login as root anymore. If you try to login as root, you should get denied access:

Excellent. Now let’s log as ssh-user and confirm we are in our chroot sandbox:

Setting up the SFTP Server

Now that we have a basic SSH server running, we’ll configure the basic SFTP server as well. The SFTP server is provided through the SSH daemon and as such, is configured via the sshd_config file as well. This is because SFTP is actually the FTP protocol tunneled through the SSH protocol. As such, the sshd includes a FTP server within itself. To enable SFTP, we simply need to tell sshd to

And ask sshd to use the internal-sftp subsystem by modifying the Subsystem sftp option to Subsystem sftp internal-sftp. Save the file again and restart the SSH server:

And let’s test our SFTP server.

You may run into a few issues here if something is misconfigured.  To help you diagnosed the problem, consult the /var/log/authlog. For example, you encounter this rather cryptic error message when trying to connect to your ftp server:  "Received message too long 1416128883" . This is often caused by the server producing an unexpected output message. In the context of OpenBSD. This may be caused by the banner send by default which is contained in /etc/motd, in which case you need to specify  Banner none in sections relating to the SFTP server.

You may also get disconnected as soon as you attempt to reach your SFTP server, in which case you will get an error message stating:

In which, you can check the log file to troubleshoot your problem

In this case, OpenBSD is complaining about the permissions set on the SFTP chroot directory. If they are too lax, sshd will simply refuse to allow connections to it. As such, make sure you have the appropriate directory permissions.

At this point, you have a server with SSH and SFTP enabled. You can be stop here if this configuration fills you needs, otherwise we can still customize furthermore the servers.

Additional Settings

For one thing, you may want to disable IPv4 if it’s not needed and allow only IPv6. In your sshd_config file, we will do so by setting the AddressFamily to inet6:

Another useful customization depending on your line of work is to change the SSH port. In this case, we will change the port to 443, which is usually reserved for HTTPS connections. The reason for that is that if I need to reach back to my server from a network with connection restrictions, local connections to remote hosts via port 443 is usually allows. In other words, if a firewall is blocking outbound connections to port 22, establishing as SSH connections via port 443 will usually be allowed, unless there are protocol restrictions in place. In any case, we can change the port with:

Depending on your level of paranoia, we can also tighten some controls relating to connectivity to mitigate brute-force or dictionary attacks:

The MaxStartups property is interesting and warrant further details. From the man page:

it specifies the maximum number of concurrent unauthenticated connections to the SSH daemon. Additional connections will be dropped until authentication succeeds or the LoginGraceTime expires for a connection.

It allows for unauthenticated connections to be denied at random in order to mitigate noisy scanning or DDoS from the Internet. In the example above, we specified the value “5:60:10“, which means that if 5 unauthenticated connections are alive, further unauthenticated connections will be refused with a 60% probability. If 10 unauthenticated connections are established, all further attempts will be denied.

And to further ensure additional security controls, confirm that the following parameters are commented so that the defaults value be used:

Authentication Modes

Another feature that you may want to customize based on your needs is how you or your users connect to the server. Three modes are usually considered to do so:

  • PubkeyAuthentication: requires your client to provide a public key in order to connect to your SSH client. If you have a limited number of users which connects from the same location, this is probably the best option. However if you intent to connect to your SSH server from multiple hosts, you would have to bring your public key with you.
  • PasswordAuthentication and ChallengeResponseAuthentication are very similar in practice. PasswordAuthentication request the client to provide a password via the SSH connection while the ChallengeResponseAuthentication can ask the client one or more question via a TTY. However in most cases, ChallengeResponseAuthentication is configured to ask a password and the only real difference is that the requesting client must type the password rather than providing it via the command line.

For example, the following command would not work with PasswordAuthentication set to “no” and ChallengeResponseAuthentication  set to “yes“:

That being said, there are ways to provide SSH password via the command line, such as using the sshpass package. There is therefore little difference between them. In this example, we configure these parameters as follow:

Hashing Known Hosts Files

When a client connects, the SSHD will store information about the client in the known_host file, which is located in ~/.ssh/. This file will contain the hostname of the client, its IP address and its key. This information is stored in plain text. An additional step to make the life of an intruder harder should your server get compromised is to obfuscated the data in this file be hashing its contents.

The listing above shows the contents of the file before hashing it. To tell SSHD to hash newly added data of the known_hosts file, we will add the following the HashKnownHosts line  in ~/.ssh/config.

From now on, all data added will be hashed. Should you need to hash data already residing in this file, use the command below:

We now have a very solid SSH server. You still have to remain vigilant about new vulnerabilities that may pop up for SSHD or one of its component. In the second part of this series, we’ll cloak our SSH server using some form of port knocking. For now, let’s just tweak our SFTP server slightly. Before that, let’s restart our server.

Final Touch on the SFTP server

We previously set our FTP chroot readonly, but we might want to upload some files to it. If we try it right now, we’ll get the following error message:

We’ll finish this tutorial by adding an upload directory and make it writable to the users of the ftp-users group:


We’ll conclude this part of the tutorial for now. In this post, we detailed how to enable a SSH server on OpenBSD 6.1. We also enabled SFTP and securely configure each service to increase robustness. That being said, nothing is impossible and vulnerabilities may remain: keys can be stolen or confiscated, misconfiguration of other services may be present or malicious internal users may still abuse the system. If you’re a network admin, make sure logging is enabled and more importantly, that logs are analyze either via software or if you have time, manually. In the next part of this tutorial, we will enable a form of port knocking to hide our SSH service to scanning from external hosts. By doing so, we will prevent detection by roaming threats and prevent or at least greatly limit effectiveness of brute force and dictionary attacks against our server.


Additional Readings

The Syrian Civil Conflict in the Cyber Environment


This is an article I wrote a while ago and never got published. It’s a bit outdated now, but I still think it can be useful for historical purposes, so I’ll post a link to it below.


This document analyzes the use of the cyber environment in the Syrian civil war by both the population and the government in order to characterize online tactics and strategies developed and used by each belligerent. This overview allows for generalization of online behavior by hacktivists and nation-state sponsored actors on communication networks in the region, which will continue to see online attacks from various parties in the foreseeable future during similar conflict. In Syria, because of poor infrastructure, low rate of Internet penetration and early adoption of control mechanisms by the current government, the authorities had dominance over their information environment early in the conflict, enabling rapid gathering of intelligence on dissidents. While social medias were leveraged by the population as in many other uprisings for coordination, it was also the theater of multiple offensive cyber operations by internal and external groups, mostly for information operations purposes. Despite the high level of activity, none appeared to have a definitive impact on the ground. While events recorded in this space have not reached the level of intensity of other conflicts, it proves a useful model for similar conflicts in the Middle East region.


Racicot, Jonathan, The Syrian Civil Conflict in the Cyber Environment,, last accessed 2015-09-03

Repost: Stack-based Buffer Overflow Vulnerabilities in Embedded Systems

The buffer overflow attack vector is well documented in desktop and server class machines using the von Neumann memory model, but little has been published on buffer overflow vulnerabilities in Harvard architectures.


I have not written or contributed to the enclosed research paper. I’m simply reposting it here because it’s interesting and for some reason, appears available only via Google cache. So before it disappear from results, I’m reposting it here.

This paper discusses a technique to conduct buffer overflows on processors using the Harvard architecture. In this architecture, the stack starts at the beginning of the memory and grows up, versus Von Neumann architectures in which it grows down.


Most small embedded devices are built on Harvard class microprocessor architectures
that are tasked with controlling physical events and, subsequently, critical infrastructures. The Harvard architecture separates data and program memory into independent address spaces, as opposed to the von Neumann architecture that uses a unified memory system with a single address space for both data and program code. The buffer overflow attack vector is well documented in desktop and server class machines using the von Neumann memory model, but little has been published on buffer overflow vulnerabilities in Harvard architectures. In this paper we show that stack-based buffer overflow vulnerabilities exist in embedded control devices based on the Harvard class architecture. We demonstrate how a reversal of stack growth direction can greatly simplify the attack and allow for easier access to critical execution controls. We also examine popular defense techniques employed in server and desktop environments and the applicability of those defenses toward Harvard class machines.
Link: Kristopher Watts & Paul Oman, University of Idaho, Stack-based Buffer Overflow Vulnerabilities in Embedded Systems

The Variable Message Format (VMF) Protocol – A Data Protocol for Radios (Part 1)

The VMF protocol is a SDR data protocol created to exchange information between multiple different systems by providing a rich and flexible specification. Yet, the VMF is little known even amongst avionics engineering and its knowledge remains the speciality of few. As such, in this post we explore this protocol in details to better understand its inner workings and its uses



Software-Defined Radio (SDR) is a fast-growing market, expanding in a wide array of industries. Growth in this sector alone is expected to reach $USD27.29 billion by 2020 [1]. When only considering that most smartphones are equipped with SDRs, one can quickly understand the active research conducted in the field. SDRs are also in high usage across militaries and law enforcement given the added flexibility to conduct multiple types of operations using the same hardware, often with reduced maintenance costs. Nowadays, military tactical radios and law enforcement equipment are all software-defined to some degree. Within the industry, 93% of all mobile systems leverage SDR for wireless communications [2]. The added agility introduced by software also comes with additional threats, previously absent from hardware-based radios. Within the military, SDRs form the cornerstone of network-centric warfare as they are used to establish networks between different units in order to exchange data such as position, imagery and target information rapidly between ground, maritime, air and space elements. Radios not only process voice; the internal software also manages various networks and data protocols, further increasing the complexity of the application layer of the communication device. The VMF protocol is one such SDR data protocol created to exchange information between multiple different systems by providing a rich and flexible specification. Yet, the VMF is little known even amongst avionics engineering and its knowledge remains the speciality of few. As such, in this post we explore this protocol in details to better understand its inner workings and its uses

Software-Defined Radios

An overview of the architecture of the SDR is required to better appreciate the threats against them and to eventually understand some of the unique characteristics when looking for vulnerabilities in their software. We do so by describing the general software model used by SDRs which have multiple layers, each of which uses different programs to process waveforms and the data contained in them. The Wireless Innovation Forum (WIF) simply defines a SDR as a radio in which some or all of the physical layers functions are software defined, contrasting with previous radios in which all configurable properties were designed and hardcoded into the hardware. Within the definition of WIF, the physical layers refer to the four lowest layers of the OSI model. This innovation allowed for additional agility into the functionalities of radios, as the integrated general purpose processors (GPP) or Field Programmable Gate Array (FPGA) units and the flexible radio-frequency (RF) modulators – all reconfigurable through software – permit the device to operate on a wider range of the spectrum depending on the current operations. These new components are all software controlled, allowing for fast reconfiguration as needed by the operator (see figure 1).

Simplified schema of the major hardware and software components of modern SDRs.
Figure 1. Simplified schema of the major hardware and software components of modern SDRs.

Within the SDR the Software Communications Architecture (SCA) is the open framework generally used to specify how a radio designer should integrate hardware and software components in order to interact efficiently and maximize software reuse [3]. The SCA was developed by the U.S. military as part of the now defunct Joint Tactical Radio System (JTRS). Despite it’s military roots, the SCA is used in the industrial sector as well. The framework divides the radio into 4 layers, each composed of multiple components. These are layers below the user applications (figure 2) and are responsible for processing the inbound and outbound data:

The Software Communications Architecture (SCA) is an open architecture framework abstracting interactions between hardware and software within a software defined radio.
Figure 2. The Software Communications Architecture (SCA) is an open architecture framework abstracting interactions between hardware and software within a software defined radio.

Programmable Radio Hardware; the Programmable Radio Hardware is the layer which regroups the software-reconfigurable elements of the radios such as the RF modulation units, the modems and the link interfaces.

Operating System and Middleware; the operating system, along with the Common Object Request Broker Architecture (CORBA) middleware play the critical role of managing the communications between the software of the core framework and the hardware. CORBA is a message passing technique that is widely used for cross-platform frameworks. All core interfaces are defined using the Interface Definition Language (IDL) which can be compiled in different languages such as C/C++ and ADA. The operating systems included in SDRs are Real-Time Operating Systems (RTOS) such as uOS, TinyOS or VxWorks. These provide multithread support and are required to be POSIX compliant. The RTOS also interfaces with the underlying network interfaces and serial ports.

Core Framework; the core framework is the abstraction layer between the software developers and the underlying hardware. It contains the interfaces and services required for the applications to use the devices of the radio by describing them using the eXtensible Markup Language (XML);

Waveforms; the software at this layer specifies the required parameters to form the needed waveform to communicate with networked devices. By reviewing the framework above, one quickly realizes that the world of radios is now mainly driven by software development and thus exposes itself to the same issues that plagues programs in the wider computing world. The terms ”operating system”, ”drivers”, ”middleware” and APIs are terms well-known to cyber operators and computer security analysts alike, thus making them a target the same way as any other host on any other network.

Tactical Radios

Software radios have significant advantages for the military as they provide a wide variety of dynamic radio protocols in real time. Since SDRs can be reprogrammed remotely for multiple purposes without any hardware changes, maintenance costs and time have decreased. Because of these characteristics, SDRs are one of the cornerstones of network-centric warfare, the currently predominant Western military doctrine. It is therefore not surprising that all tactical military radios in modern western militaries are SDRs, including most of civil aviation for law enforcement and potentially drones. Modern MTRs are more akin to routers than radios and enable the creation of instant networks and the exchange of operational data between the connected nodes over Tactical Data Links (TDL) such as Link-16. Data protocols such as VMF and the Joint Range Extension Applications Protocol (JREAP) enable the exchange of voice, data and imagery by connecting to a network of various platforms and units, both vertically and horizontally. Amongst the data exchanged are: positions, trajectories, maps, navigation data, mission data and intelligence. This implies the presence of user applications managing the data protocol, and additional applications processing the data received. Other data link protocols include the Type 483D, the Chinese equivalent to Link 4C. This transfer of information between platforms is central to the network-centric warfare doctrine which drives the research and development of network radios and increases the complexity of the software and network protocols. In many aspects, the radio can be considered the gateway device between the internal networks of a platform and external nodes requesting to connect to it. Internally within aircraft and ships many MTRs provide multiple interfaces to communicate with other elements of the platform, such as mission computers, display terminals and external software to display geoposition data for example. On a military aircraft, the interfaces of the radio usually include the MIL-STD-1553 bus (or its civilian counterpart, the ARINC429) to link with the avionics as well as Ethernet and serial ports such as RS-232 or RS-485, often used by Remote Control Units (RCUs) for management purposes via protocols such as the Simple Network Management Protocol (SNMP). Externally the radio networks the platform with external units using different systems by forming Mobile Ad hoc Networks (MANETs) and exchanges tactical data using data protocols over the tactical data links. These networks are wireless, infrastructureless, multi-hop and highly fluid. In military usage these are typically low-bandwidth links and are often managed by devices with little computational power. The Ad hoc On-Demand Distance Vector (AODV) is typically the underlying routing protocol, which manages routing in a peer-to-peer network. Routing information is updated constantly, as nodes within a MANET can also act as proxies for far-away nodes.

The Variable Message Format Protocol

The VMF standard was developed by the U.S. Department of Defense to allow messages of variable lengths to be sent over TDLs. A VMF message is bit-oriented and attempts to minimize the use of TDLs by sending only the required data. The objective is to be flexible enough to be able to communicate with any legacy and new host requiring that additional header fields can be added without modifying the underlying specification. The core of the VMF protocol is the Protocol Data Unit (PDU) which contains the header and the user data (figure 3), much like a typical TCP/IP packet. The PDU is processed at the application layer and is composed of the application header and the user data, which can be multiple format as we will see later on. The size of the former is always a multiple of 8 and is padded with null bits as needed.

Schema of the Application Header of a VMF message
Figure 3. Schema of the Application Header of a VMF message. which is composed of fields and grups.

Structure of the Application Header

The first 4 bits of the header always specify the version of the VMF protocol in used by the PDU. As of 2015, 5 revisions of the protocol have been created (table 1):

Code (binary) Revision
0000 MIL-STD-2045-47001A
0001 MIL-STD-2045-47001B
0010 MIL-STD-2045-47001C
0011 MIL-STD-2045-47001D
0100 MIL-STD-2045-47001D w/ CHANGE1
0101-1110 Undefined
1111 Version Sent Not Implemented
Table 1. Version numbers currently defined in revision D w/ CHANGE1

The “Version Sent Not Implemented” value is used to specify that the current implementation of the VMF protocol in the system is not backward compatible with the incoming VMF messages.  For example, a system using revision D of the protocol sending a message to another system using revision C or earlier will receive an answer with the version field set to “15”, specifying that the source system must use an earlier revision (figure 4). If the version is not implemented, but the destination system is still able to process the message, it will nonetheless.

Usage of the Version Not Implemented value
Figure 4. When a previous version of the VMF receives a message from a latter revision, it returns a message with the version field set to “Version Not Implemented” value.

Fields and Groups

Elements following the version number are either “fields” or “groups” as shown in figure 3. A field can generally be thought as single piece of data along with an overhead of 1 or 2 bits; a Field Presence Indicator (FPI) and a Field Recurrence Indicator (FRI). The FPI is a flag which indicate if a value for the field has been specified or not, e.g. if the FPI is set to zero, the following bit is the start of new field or group. If set to one, the following bits represents the value for the field. Some fields occur more than once. These fields include the FRI flag which is right after the FPI. When set to one, the field is repeated right after until the FRI is set to zero as illustrated in figure 5. Note that the FPI is included only once in the first field.

Example of the Field Recurrence Indicator (FRI) within a VMF message
Figure 5. Example of the Field Recurrence Indicator (FRI) within a VMF message used for the Release Marking field.

Groups, as their name suggest, are sets of related fields or sub-groups. A group have a depth down to 6 levels and possess the same presence and indicator flags as fields, which are known at the Group Presence Indicator (GPI) and Group Recurrence Indicator (GRI). The order of fields and groups of the header is fixed, much like any TCP/IP packet.

While most of the fields contain numeric values, some are 7-bit ASCII coded strings, where the value 127 (the DELETE character) is used as the string terminator, i.e. equivalent to the null byte ‘’ in C/C++ character arrays. The terminator is added to the string only if its bit-length is smaller than the maximum length of the field. For example, the “unitname” field is 448-bit long, i.e. 64 characters. If the unitname contains less than 64 characters, the terminator will be added to the value. A complete list of groups and fields, along with their description and constraints can be found in the specification (and maybe discussed in future parts of this article)

Assembly of a VMF Message

The creation of a VMF message is quite similar to the creation of a HTTP request or a TCP/IP packet: it is done via encapsulation of user data through the multiple layers of the SDR. User data is first entered into the radio, usually by the pilot or crew via a Remote Control Unit (RCU) or a subsystem via the internal MIL-STD-1553 bus or ARINC 629 data bus. The radio receives the MIL-STD-1553 message from the bus controller and extracts its data. It then determine to which units on its MANET to send the data. Note that data can be broadcasted to all units on the network via a broadcast address. The default broadcast address is 16777215. Within the SDR, the data is then transferred to the VMF messaging service of the device. Based on its configuration and properties of the data provided, the VMF layer will construct the proper application header and append the user data to form the application PDU.  The PDU is then send to lower layers, transformed into waveforms and digital data converted to analog radio waves to be sent via the antenna of the aircraft. The receiving unit then do the reverse process and dispatch the received data to the internal subsystems of the destination aircraft. The process is illustrated in figure 6.

Encapsulation process of user data into a VMF message.
Figure 6. Encapsulation process of user data into a VMF message.

User Data

The type of user data that is contained within the application PDU is defined by the User Message Format (UMF) field. This field indicates the format of the message contained in the user data field and is associated with the Functional Area Designator (FAD), the Message Number, the Message Subtype, CANTCO reason and CANTPRO reason fields. More about these fields in part 2 of this article.

Binary Files

VMF can be used to transfer files between systems and this is done by setting the UMF field with the value 1 and using the “Filename” field to specify the name of the file. Furthermore, to indicate that the message is a file transfer the GPI of the VMF Message Identification Group needs to be set to zero.

Redistributed Messages

When the UMF field is set to 0100 (4), the content of the user data is another VMF message, much like a forwarded email. Both the application header and user data sections of the redistributed message are included in the user data portion of the message forwarding it. The “Operation Indicator“, “Security Classification” and “Release Marking” fields are required to be similar in both messages. Both messages are to be processed by the receiving systems.


Nodes (hosts) on the network can be identified using one of the following fields: the URN or the Unit name. Both cannot be used at the same time normally. The URN is, as its name implies, a number given to a specific unit to identify it. It acts as a MAC address would. Each URN is unique and only as one unit bearing the number. Distribution of these URN is made by the U.S. Department of Defense. This URN is the addressing scheme at the application layer. VMF can be carried via TCP/IP (or UDP), MIL-STD-1553 or any other lower layer. Note that other addressing scheme can be used, but these will be explored later on.


This concludes part 1 of the introduction to the VMF protocol. In part 2, we will explore further the fields included in the latest revision of the protocol and include actual example of VMF messages. In the meantime, you’re welcome to play with Vmfcat, which is a Python script I’m working on (still incomplete) to generate VMF messages from the command line or via an interactive shell.

The Past, Present and Future of Chinese Cyber Operations

China, as one of many alleged actors on the frontier of cyber espionage, is best understood by briefly examining the past century, how it influences contemporary cyber operations attributed to Chinese-based actors, and how they could be used against the Canadian Armed Forces in a potential Southeast Asian conflict.


Out of nowhere, here’s an article I wrote for the Canadian Military Journal. China,  as one of many alleged actors on the frontier of cyber espionage, is best understood by briefly examining the past century, how it influences contemporary cyber operations attributed to Chinese-based actors, and how they could be used against the Canadian Armed Forces in a potential Southeast Asian conflict.

See the full article here:; or



Facebook Profile from Image Filename


This is not new and I’ve been knowing this for a while (and it’s all over the Internet anyway), but I keep forgetting the details. So basically to find a Facebook profile from the file name of an image, follow these steps:

  1. Images downloaded from Facebook always ends with “_n.jpg” and has 3 numbers divided by an underscore (“_”). For example: 1505501_1378549085743944_745448926_n
  2. The middle number is the Facebook Photo ID, this is the one you’ll need to locate the profile, in this example “1378549085743944”
  3. Then you plug your photo ID at the end of this link:[photo-id]
  4. If the picture is not shared, then you’ll get a “Content Unavailable” message, otherwise you’ll land on the profile.
File "1505501_1378549085743944_745448926_n.jpg"
Image file “1505501_1378549085743944_745448926_n.jpg”

So by going to, you’ll land on the profile where the picture was downloaded from:

Fake Facebook Profile of Chloe Moretz
Facebook profile corresponding to image id “1378549085743944”

Phusking PhotoBucket and Other Pictures Sharing Sites

Fusking picture sharing sites in order to retrieve pictures from private album.


It came to me while I was reading an article on Slashdot about sites popping up, offering the customer to hack into a Facebook, MySpace or other social site for 75$ to 100$. EWeek as a similar article[1]. Seems like those sites mostly use social engineering by sending grammatically deficient e-mail to the victim and somehow, still working most of the time. Most of the time, the goal is to get access to private pictures or information. Hacking Facebook and MySpace accounts is the new “How do I hack Hotmail accounts” of the decade. Just search Google for “facebook hacking service” and plenty of website will be returned.

Same thing with pictures from services like PhotoBucket or Flickr and such. Getting pictures from private albums is much more easier thought and is done thru fusking. The goal is simply to access directly pictures from the private album by guessing the filename of the picture.

As you might know, most cameras have a default naming convention, i.e DSC0001.jpg, Picture0001.jpg etc… (see then end of this article for a complete list) and humans, being lazy as they are, don’t bother renaming them. Since I believe that a example is the best way to learn than 30 pages of detailed explanation, here how it’s done.

Let’s create an account on PhotoBucket first. I used a username I always take everywhere, but it seems that Photobucket didn’t liked it:

PhotoBucket New Account Error
PhotoBucket didn't like me the first time...

Anyway, just deleting the Photobucket cookie solve the problem. Registered using brand new data. Small tips, if you are looking for zip code, try this page: Find A Zip, it has about every zip code for every town in the US (I haven’t verified but looks like it…).

Once in, I created a private album and put two pictures in it; one I renamed and the other I left with a camera default filename.

PhotoBucket Private Album Creation
Private album I created in Photobucket

I named one of those pictures DSC0005.jpg and the other an uncommon name:

PhotoBucket Private Pictures
Private pictures I put into my private album

The URL of my private album is

The filename is


So just to try out the concept,  I signed out and look if, with the album’s URL and the filename, could access the picture. Oh ! Look at that:

PhotoBucket Private Picture Direct Link
Accessing a private picture thru a direct link

So you should be able to guess the rest from here. Nevertheless, there are tools out there to even do the guessing work for you. The one I will use is PHUSK. It’s especially done for PhotoBucket and is for Windows. This shouldn’t be hard to program for another website and another platform.

PHUSK 1.5 Main Window
PHUSK 1.5 Main Window

There is really not much to explain, just type the username of the victim and set up any properties you want (which are pretty much self explanatory). On the first try, it didn’t found any private album, so I had to specify it by selecting “advanced mode” which show this window:

PHUSK 1.5 Advanced Mode Windows
PHUSK 1.5 Advanced Mode Windows

Select “Add Album”, type the album name and then it will appear in the list of albums (which is ordered).

PHUSK 1.5 Add Album Name
PHUSK 1.5 Added Album Name in the List

Started PHUSK again and this time it found the private album, it will then try to brute force filenames, which might take a while.

PHUSK 1.5 Result Window
My private picture with a default filename has been found !

I changed the default lists to make it faster, otherwise it might take a long time (411 albums name X 439 filenames X ~9999 file numbers each…).

Here is a list of filenames used by PHUSK. This can be use to build your own list.

###.jpg Unknown-#.jpg Me.jpg
##.jpg Untitled-###.jpg ME.jpg
#.jpg Untitled-##.jpg mygirls.jpg
Picture###.jpg Untitled-#.jpg Mygirls.jpg
Picture##.jpg untitled-###.jpg MYGIRLS.jpg
Picture#.jpg untitled-##.jpg fine.jpg
Photo###.jpg untitled-#.jpg Fine.jpg
Photo##.jpg stuff###.jpg FINE.jpg
Photo#.jpg stuff##.jpg sexy.jpg
#####.jpg stuff#.jpg Sexy.jpg
####.jpg Stuff###.jpg SEXY.jpg
CIMG####.jpg Stuff##.jpg hot.jpg
CIMG####.JPG Stuff#.jpg Hot.jpg
DSCN####.jpg stuff-###.jpg HOT.jpg
PICT####.jpg stuff-##.jpg hott.jpg
DSC_####.jpg stuff-#.jpg Hott.jpg
DSC0####.jpg mycamerapics###.jpg HOTT.jpg
Image###.jpg mycamerapics##.jpg really.jpg
Image##.jpg mycamerapics#.jpg Really.jpg
Image##.JPG mypics###.jpg REALLY.jpg
Image#.jpg mypics##.jpg ass.jpg
PICT####.JPG mypics#.jpg Ass.jpg
IMG_####.jpg Misc-###.jpg ASS.jpg
_MG_####.jpg Misc-##.jpg bad.jpg
000_####.jpg Misc-#.jpg Bad.jpg
001_####.jpg misc###.jpg BAD.jpg
100_####.jpg misc##.jpg face.jpg
100-####.jpg misc#.jpg Face.jpg
100-####_IMG.jpg misc-new###.jpg FACE.jpg
101_####.jpg misc-new##.jpg page.jpg
101-####.jpg misc-new#.jpg Page.jpg
101-####_IMG.jpg New###.jpg PAGE.jpg
102_####.jpg New##.jpg tits.jpg
102-####.jpg New#.jpg Tits.jpg
102-####_IMG.jpg New-###.jpg TITS.jpg
103-####.jpg New-##.jpg boobs.jpg
103_####.jpg New-#.jpg Boobs.jpg
0##########.jpg new###.jpg BOOBS.jpg
1##########.jpg new##.jpg breasts.jpg
0########.jpg new#.jpg Breasts.jpg
1########.jpg new-###.jpg BREASTS.jpg
########.jpg new-##.jpg naughty.jpg
#######.jpg new-#.jpg Naughty.jpg
######.jpg Old###.jpg NAUGHTY.jpg
Cimg####.jpg Old##.jpg smile.jpg
DCAM####.jpg Old#.jpg Smile.jpg
DC####S.jpg old###.jpg SMILE.jpg
DCFN####.jpg old##.jpg light.jpg
DCP_####.jpg old#.jpg Light.jpg
DCP0####.jpg nude###.jpg LIGHT.jpg
dsc#####.jpg nude##.jpg kiss.jpg
DSC#####.jpg nude#.jpg Kiss.jpg
DSC####.jpg Nude###.jpg KISS.jpg
dsc0####.jpg Nude##.jpg kisses.jpg
DSCF####.jpg Nude#.jpg Kisses.jpg
DSCF####.JPG Sexy###.jpg KISSES.jpg
dscf####.jpg Sexy##.jpg muah.jpg
DSCI####.jpg Sexy#.jpg Muah.jpg
DSCI####.JPG sexy###.jpg MUAH.jpg
dscn####.jpg sexy##.jpg mwah.jpg
EX00####.jpg sexy#.jpg Mwah.jpg
HPIM####.jpg sexxy###.jpg MWAH.jpg
IM00####.jpg sexxy##.jpg drunk.jpg
IMAG####.jpg sexxy#.jpg Drunk.jpg
IMAGE_####.jpg pictures###.jpg DRUNK.jpg
IMAGE####.jpg pictures##.jpg drunken.jpg
IMG0####.jpg pictures#.jpg Drunken.jpg
IMG####.jpg Pictures###.jpg DRUNKEN.jpg
Img#####.jpg Pictures##.jpg sleep.jpg
IMG_00####.jpg Pictures#.jpg Sleep.jpg
IMG_#####.jpg sexypic###.jpg SLEEP.jpg
IMG_####.JPG sexypic##.jpg sleeping.jpg
IMGA####.JPG sexypic#.jpg Sleeping.jpg
IMGP####.JPG sexypics###.jpg SLEEPING.jpg
IMGP####.jpg sexypics##.jpg tongue.jpg
IMPG####.jpg sexypics#.jpg Tongue.jpg
KIF_####.jpg Smile###.jpg TONGUE.jpg
mvc#####.jpg Smile##.jpg cute.jpg
MVC0####.jpg Smile#.jpg Cute.jpg
MVC-####.jpg smile###.jpg CUTE.jpg
MYDC####.jpg smile##.jpg hehe.jpg
P00#####.jpg smile#.jpg Hehe.jpg
P10#####.jpg mirror###.jpg HEHE.jpg
P101####.jpg mirror##.jpg us.jpg
PC00####.jpg mirror#.jpg Us.jpg
PANA####.JPG single###.jpg US.jpg
PDR_####.JPG single##.jpg mesexy.jpg
PDR_####.jpg single#.jpg Mesexy.jpg
PDRM####.JPG Happy###.jpg MESEXY.jpg
PDRM####.jpg Happy##.jpg underwear.jpg
pdrm####.jpg Happy#.jpg Underwear.jpg
pict####.jpg happy###.jpg UNDERWEAR.jpg
Picture#####.jpg happy##.jpg thong.jpg
Picture####.jpg happy#.jpg Thong.jpg
Picture###-1.jpg picture###.jpg THONG.jpg
Picture##-1.jpg picture##.jpg panties.jpg
Picture#-1.jpg picture#.jpg Panties.jpg
Picture###-2.jpg cute###.jpg PANTIES.jpg
Picture##-2.jpg cute##.jpg bra.jpg
Picture#-2.jpg cute#.jpg Bra.jpg
Photo####.jpg xxx###.jpg BRA.jpg
Photo###-1.jpg xxx##.jpg costume.jpg
Photo##-1.jpg xxx#.jpg Costume.jpg
Photo#-1.jpg delete###.jpg COSTUME.jpg
S#######.jpg delete##.jpg heart.jpg
S######.jpg delete#.jpg Heart.jpg
S#####.jpg Halloween###.jpg HEART.jpg
S####.jpg Halloween##.jpg bed.jpg
SANY####.jpg Halloween#.jpg Bed.jpg
SDC#####.jpg halloween###.jpg BED.jpg
scan#####.jpg halloween##.jpg shower.jpg
SPA#####.jpg halloween#.jpg Shower.jpg
ST@_#####.jpg Me###.jpg SHOWER.jpg
STA#####.jpg Me##.jpg bath.jpg
STP#####.jpg Me#.jpg Bath.jpg
PANA###.jpg ME###.jpg BATH.jpg
{user}#.jpg ME##.jpg closet.jpg
DSCI###.jpg ME#.jpg Closet.jpg
DigitalCamera###.jpg me###.jpg CLOSET.jpg
Image(##).jpg me##.jpg kitchen.jpg
Image(##).JPG me#.jpg Kitchen.jpg
mvc-###.jpg 1-###.jpg KITCHEN.jpg
MVC-###.jpg 1-##.jpg fridge.jpg
Sony#.jpg 1-#.jpg Fridge.jpg
PhotoMoto_####.jpg IMG_###.jpg FRIDGE.jpg
###-1.jpg IMG_##.jpg table.jpg
##-1.jpg IMG_#.jpg Table.jpg
#-1.jpg naughty###.jpg TABLE.jpg
Picture###.png naughty##.jpg risque.jpg
Picture##.png naughty#.jpg Risque.jpg
Picture#.png Naughty###.jpg RISQUE.jpg
stuff###.jpg Naughty##.jpg new.jpg
stuff##.jpg Naughty#.jpg New.jpg
stuff#.jpg ass###.jpg NEW.jpg
stuff-#.jpg ass##.jpg old.jpg
S###.jpg ass#.jpg Old.jpg
S##.jpg Ass###.jpg OLD.jpg
S#.jpg Ass##.jpg halloween.jpg
s###.jpg Ass#.jpg Halloween.jpg
s##.jpg Pic###.jpg HALLOWEEN.jpg
s#.jpg Pic##.jpg cleavage.jpg
unknown-###.jpg Pic#.jpg Cleavage.jpg
unknown-##.jpg pic###.jpg CLEAVAGE.jpg
unknown-#.jpg pic##.jpg pic.jpg
Unknown-###.jpg pic#.jpg Pic.jpg
Unknown-##.jpg me.jpg PIC.jpg

So basically, the way out of phuskers is only to rename your files so that it won’t fit any of the above masks. So a simple description (3-5 words) on what’s on the picture might be able to defeat most of these software.

So here you have it how to get pictures from Photobucket.  Although I haven’t shown it here, this concept can be used for other picture sharing sites. As in anything that ever existed, this can be used for good and evil purposes. I started to get interested in computer security by reading that stuff when I was young so my goal here is to do the same, knowing that some script kiddies will probably use this.


1 Security Researchers Find Alleged Facebook Hacking Service ”, Brian Prince, eWeek, September 18, 2009, 2009-12-29

A Study of Smart Cards


Cards are quite an interesting species of object that have invaded our lives in every way: we either use them for public transit, laundry, gift cards, phone cards, credit cards etc… One could gather quite a lot of power buy not only understanding their functioning, but also by being able to tamper their data. I must admit that I have absolutely no knowledge (or almost) of those devices, but hopefully, by the end of this project, this will have completely changed.

Visual Study of Smart Cards

Smarts card are usually the size of the credit cards and dimensions are defined accordingly to the ISO/IEC 7810 standard. The standard defines four card sizes: ID-1, ID-2, ID-3 and ID-000. Smart cards are usually comprised in the ID-1 category although some are into the ID-000 category, which mostly comprise of SIM cards. Each of them are 0.76 mm thick. The properties are defined as follow1:

Example of a card using a chip
Example of a card using a chip
Format Dimension Usage
ID-1 85.60 × 53.98 mm Most banking cards and ID cards
ID-2 105 × 74 mm German ID cards issued prior to Nov 2010
ID-3 125 × 88 mm Passports and Visas
ID-000 25 × 15 mm SIM cards

The material use for the card is usually Polyvinyl chloride (PVC). Of course the most interesting item on rhe card is that golden connector. There are various type of connectors as shown in the picture below:

Different Layouts of Cardpads
Different Layouts of Cardpads

There are also three main types of smart cards: contact cards, contactless and vault cards [2]

The three main types of Smart Card available
The three main types of Smart Card available

Actually the two that are actually important in everybody’s life are the contact and contactless cards, the latest being use in public transit most of the time. For now I’ll concentrate on contact cards.

Contact Cards

Information is transferred using electrical connectors, i.e the golden chip on the card to the reader. Usually, the chip as around 8 connectors as follow:

Now contact cards are divided in two categories : memory cards and multiprocessor cards. Memory cards are furthermore divided into 3 categories:

  • Straight Memory Cards
  • Protected/Segmented Memory Cards
  • Stored Value Memory Cards

The Project

I recently got handed a laundry smart card and for some reason, got fascinated with it. I never really played with hardware but studying those devices have interested me to the point of studying them in a special project. The goal is to be able to modify the contents of the memory of the card. This project will be conducted in two phases :

  1. Dump the content of the memory into my computer
  2. Alter the content and write it back to the card

System Description

A client is handled a Smart Card called “SmartCity” from a company called Coinamatic, which provide laundry solutions to property managers. The card can be loaded and recharged using coins or debit/credit cards through “reload centers“. You can put up to 50$ maximum on the card. To use the facilites, you need to insert the card  into a slot built into the washers/dryers. The washer is a Commercial Energy Advantage Top Load Washer MAT14PRAWW model. The dryer is a 27″ Commercial Single-Load Electric Stack Dryer model MLE24PRAZW.

Next post : the card reader/writer

See also:

EMV 4.2 Specification, EMVCo, May 2008, accessed on 2009-07-20

Infineon SLE4442, Flylogic Engineering’s Analytical Blog, December 1st, 2007, accessed on 2009-07-20

How-to: Read a FedEx Kinko’s smart card (SLE4442), Ian Lesnet, Hack-a-day, November 28th, 2008,, accessed on 2009-07-20

Intelligent 256-Byte EEPROM SLE 4432/SLE 4442, Siemens, 1995, accessed on 2009-07-20

Kinko’s Smart Card (Siemens SLE4442 memory chip), Strom Calson, accessed on 2009-07-20

1K EEPROM – Security Logic with Two Application Zones AT88SC102, Atmel, 1999, accessed on 2009-07-20

[1] ISO/IEC 7810, Wikipedia, accessed on 2009-07-20

[2] Types of Chip Cards, Smart Card Basics, 2005, accessed on 2009-07-20

RAAF website defaced


Atul Dwivedi, an Indian hacker paid a visit to the Royal Australian Air Force (RAAF) last Monday by defacing their website.

This accident comes amid a raise in violence targeted towards Indian native in Australia and apparently Dwivedi protested this situation by leaving a message on the website:

“This site has been hacked by Atul Dwivedi. This is a warning message to the Australian government. Immediately take all measures to stop racist attacks against Indian students in Australia or else I will pawn all your cyber properties like this one.”

Racist incident in Australia against Indian students has increased in the last months
Racist incident in Australia against Indian students has increased in the last months

This site is now up and running as per normal. Of course the webserver wasn’t connected to any internal network and didn’t contain any classified information according to a spokewoman:

“No sensitive information was compromised as the air force internet website is hosted on an external server and, as such, does not hold any sensitive information,1

Microsoft products are used in pretty much every Western armed forces. So it’s save to assume the webserver used by the RAAF is probably running IIS. Of course, IIS implies as Windows machine and a Windows Server machine means that everything is almost certainly all Microsoft based. Of course we can now verify those claims and according to David M Williams from ITWire2 the website is hosted through Net Logistics, an Australian hosting company. The aforementioned article tries to explain the hack with the use of exploits. Which might have been the way Dwivedi did it, but the analysis is quite simple and lacks depth. The site still has an excellent link to a blog detailing the WebDAV exploit, see below for the link.

It’s not impossible to think that Dwivedi might have tricked someone into giving out too much information also. Social engineering can do lots and is usually easier than technical exploits. The Art of Deception by Kevin Mitnick should convince most people of that. Someone could look up on Facebook or another social networking site for some people in the RAAF and then try to pose as them and pose as them.

Then also, why not look for the FTP server? And God knows what else the server is running; maybe a SMTP server also (and probably it does). Now I wouldn’t suggest doing this, but running a port scan would probably reveal a lot of information. Moreover, using web vulnerability tools like Nikto could help find misconfigured settings in ASP or forgotten test/setup pages/files. Up to there, only two things are important: information gathering and imagination.

See also:

Hacker breaks into RAAF website”, AAP, Brisbane Times, July 16, 2009, accessed on 2009-07-17

WebDAV Detection, Vulnerability Checking and Exploitation”, Andrew, SkullSecurity, May 20, 2009, accessed on 2009-07-17

1Indian hacks RAAF website over student attacks”, Asher Moses, The Sydney Morning Herald, July 16, 2009, accessed on 2009-07-16

2 “How did Atul Dwivedi hack the RAAF web site this week?”, David M Williams, ITWire, July 17, 2009, accessed on 2009-07-16

Firefox Javascript Vulnerability


Once again, Javascript is the source of a new exploit that has been recently discovered on Firefox1. The vulnerability can be exploited by crafting malicious Javascript code on a Firefox 3.5 browser and leads to the execution of arbitrary code on the user’s machine. This is due to a vulnerability in the JIT engine of Firefox and affects machine running a x86, SPARC or arm architectures.

The vulnerability resolves around the return value of the escape function in the JIT engine. It’s exploited using the <font> tag. The code for the exploit is public and can be found at milw0rm. The exploit use a heap spraying technique to execute the shellcode.

A fix should be available soon, but the best solution is always to disable Javascript, although a lot of sites rely on it to operate. Another way is to use the NoScript plug-in, which let you enable and disable scripts easily according to a whitelist/blacklist system.

See also:

Mozilla Firefox Memory Corruption Vulnerability”, Secunia, July 14, 2009, accessed on 2009-07-15

Exploit 9137”, SBerry, July 13, 2009, accessed on 2009-07-15

Stopgap Fix for Critical Firefox 3.5 Security Hole”, Brian Krebs, The Washington Post, July 14, 2009, accessed on 2009-07-15

Critical JavaScript vulnerability in Firefox 3.5”, Mozilla Security Blog, July 14, 2009, accessed on 2009-07-15

1 “Mozilla Foundation tackles Firefox bug”, Nick Farell, The Inquirer, Wednesday, 15, July, 2009, accessed on 2009-07-15