Qt Weekly #27: WiFi networking support on embedded devices

As a part of the Qt for Device Creation offering we provide several

helpful add-on modules that assist in creating applications for embedded devices. In this blog post I would like to demonstrate some of the features supported by the B2Qt WiFi add-on module.

What is it?

The B2Qt WiFi module provides APIs for connecting embedded devices to a wireless network. There are C++ and QML APIs available for managing wireless network connectivity, scanning for wireless network access points, retrieving information from these access points, monitoring for network state changes and more. The API allows you to manage when and to which network to connect, and when to go offline.

Overview of the API

The module consists of 3 classes:

• (Q)WifiConfiguration – Used to define a network configuration.


• (Q)WifiDevice – Represents a physical device.


• (Q)WifiManager – Main interface to the WiFi functionality (Singleton).

How to use it

Here is a code snippet in QML demonstrating how easy it is to connect a device to a wireless access point named “bus-station-wifi” that uses the WPA2 security protocol:

    import B2Qt.Wifi 1.0

    WifiConfiguration {
        id: localConfig
        ssid: "bus-station-wifi"
        passphrase: "mypassword"
        protocol: "WPA2"
    }

    Connections {
        target: WifiManager
        onBackendStateChanged: {
            if (WifiManager.backendState === WifiManager.Running)
                WifiManager.connect(localConfig)
        }
        onNetworkStateChanged: {
            if (WifiManager.networkState === WifiManager.Connected)
                print("successfully connected to: " + WifiManager.currentSSID)
        }
    }

    Component.onCompleted: {
        if (WifiManager.backendState === WifiManager.Running) {
            WifiManager.connect(localConfig)
        } else {
            // starts initialization of wifi backend
            WifiManager.start()
        }
    }

And the following code illustrates how to achieve the same in C++:

class WifiConnectionHandler : public QObject
{
    Q_OBJECT
public:
    WifiConnectionHandler()
    {
        m_config.setSsid("bus-station-wifi");
        m_config.setPassphrase("mypassword");
        m_config.setProtocol("WPA2");

        m_manager = QWifiManager::instance();
        connect(m_manager, &QWifiManager::backendStateChanged,
                this, &WifiConnectionHandler::handleBackendStateChanged);

        if (m_manager->backendState() == QWifiManager::Running) {
            m_manager->connect(&m_config);
        } else {
            m_manager->start();
        }
    }

protected slots:
    void handleBackendStateChanged(QWifiManager::BackendState state)
    {
        if (state == QWifiManager::Running)
            m_manager->connect(&m_config);
    }

private:
    QWifiManager *m_manager;
    QWifiConfiguration m_config;
};

The previous examples showed how to connect to a network for which the configuration is known beforehand. As mentioned earlier, the WiFi module can also be used to scan for available WiFi access points. In the next example we use the scan results and present them in a list where the user can select which network to use.

    Binding {
        target: WifiManager
        property: "scanning"
        value: WifiManager.backendState === WifiManager.Running
    }

    WifiConfiguration { id: config }
    ListView {
        anchors.fill: parent
        spacing: 8
        model: WifiManager.networks
        delegate: Row {
            spacing: 10
            Text { text: ssid }
            TextField { id: passwordInput }
            Button {
                text: "connect"
                onClicked: {
                    config.ssid = ssid;
                    config.passphrase = passwordInput.text
                    WifiManager.connect(config)
                }
            }
        }
    }

Here you can see a screenshot of a more advanced application running on a Nitrogen6_MAX board that utilizes WiFi API for wireless network setup.

For more information check out the documentation.

Source :- Qt Blog http://ift.tt/1JCvqWA

Qt Weekly #26: Protecting your application against hacking

Open-source applications are open by nature, indented and encouraged for tweaking, hacking and further development. For a business critical application or a device there sometimes is desire to make it closed and prevent modifications. Because of the dual licensing, Qt offers a commercial license option that is well suited for making closed applications and devices allowing many ways of protection. Everything can be hacked, but it is possible to make hacking your Qt based application or device difficult.

For the purposes of this blog post, I have divided the ways to protect your application into three categories: legal means, securing the application and external protection. I concentrate into a few easily achievable and simple ways to make reverse engineering of a Qt based application difficult, not into making a binary fully secure or protected against tampering or copying. If the system needs to be fully secure, it has to be achieved by different means that making reverse engineering harder.

Legal means

Whereas the applications and devices using the open-source licensed Qt should be open for hacking and playing around, it is possible to prevent such when using a commercial license of Qt. One of the most important legal protection means provided by the commercial license of Qt is to forbid modifications and reverse engineering – and using various methods to prevent these. It is quite typical that the end user license agreement of an application or device states that reverse engineering is forbidden, which is allowed for commercial license. However for an application or a device created with the open-source licensed Qt it is not allowed to prevent reverse engineering or modifications, neither in the end user license agreement nor by making it difficult. In addition to legal protection the commercial license of Qt makes it possible to use various technical means to secure your application or device.

Securing the application

As it is allowed to legally prevent modifications and reverse engineering when a commercial license of Qt is used, it is also possible to take actions to prevent these. Static linking is one of the easiest ways of protection as it prevents changing the Qt binary used by the application and also makes reverse engineering harder. With static linking the application and Qt libraries are combined into the same binary. A possible hacker needs to take much more demanding and time consuming ways to modify the behaviour of the system compared to dynamically linked application.

When using static linking a good further measure to protect against reverse engineering is to strip symbol names away from the binary. Depending upon the compiler you use this is either automatically done for release builds, or can be done as an extra step for the statically linked binary. For example, MSVC automatically removes symbol names from a statically linked Windows release binary. On Linux and Mac this can be done with strip command. After the symbol table is removed from the statically linked binary, it is quite well protected against reverse engineering. These steps are easily done and do not require modifying your Qt application source code, thus static linking and removing the symbols can be regarded as the most efficient way to obfuscate the binary and to make reverse engineering difficult.

If use of dynamic linking is needed, some protection against simply changing the dynamically linked Qt library to a new version can be gained via using libinfix to change the library names (e.g. change libQt5Core to stgElse). Another approach is to change the used namespace with configure option –qtnamespace. Namespacing Qt puts all classes inside a defined namespace resulting, for example, QString being called someNewName::QString. In addition to using libinfix and namespaces it is also possible to use a generic c++ obfuscator for Qt applications. The protection gained by using all these means to a dynamically linked library is typically weaker than using static linking. When considering the level of obfuscation, it should be noted that no matter how much the code is obfuscated, it is still eventually possible to reverse engineer.

For Qt Quick applications it is recommended to use Qt Quick Compiler if there is desire to protect the QML parts of the application. While the application logic, and thus typically the most critical parts to protect, is usually done with c++ and therefore always compiled to binary, it is a good further measure to also protect the QML parts of the application. The Qt Quick Compiler compiles QML to binary and protects against reading the QML parts of the application. An additional benefit of the Qt Quick Compiler is improved performance of the application, especially at startup.

External protection

As the Qt application is just like any other binary running in your target operating system and hardware, you can use all generic means available for protection in your environment. Operating system may offer means to digitally sign the applications, as is typically the case with the applications distributed via application stores. There are also many different products available to provide security for application binary, and these typically work for Qt applications as well.

For embedded devices some protection is gained even without any special security hardware, as it is often difficult to get access to and modify software embedded into a physical device. The most efficient protection is to have hardware containing functionality to prevent a modified binary from running (either in the device hardware, or an external one, such as a USB dongle). In some cases it is also possible to leverage another system via a network connection to provide tamper protection. Static linking and obfuscating the binary make reverse engineering difficult, but only the external protection mechanisms of the target hardware and operating system provide full protection.

It should be noted that leveraging external protection typically requires a commercial Qt license, similarly as the other means of preventing user from changing or modifying Qt libraries. LGPLv2.1 is a bit ambiguous when it comes to whether or not the user should be allowed to run the modified application, but it is rather clear that it was the intention. For LGPLv3 it is clearly stated in the license that in addition to being allowed to modify the open-source library the user must be able to run the modified library as part of the system, and that the needed tools to achieve this must to be provided.

Summary

If there is a need to create a closed application or a device, the commercial license of Qt is the right choice. With the commercial license it is possible to utilize various means for making it difficult to modify functionality of the application or device built with Qt:

• Making reverse engineering forbidden in end user license agreement and taking actions to prevent it is allowed when Qt is used with a commercial license.


• An easy way to protect against modifications and reverse engineering is to use static linking instead of dynamic linking and build Qt into same binary with your application to prevent changing the Qt libraries.


• When using static linking it is important to use release builds and when needed to manually strip out the symbols before distributing the binary.


• If dynamic linking is needed, some protection against reverse engineering can be gained by building Qt with different names for libraries using libinfix and changing the used namespace. This mainly protects against user being easily able to change the dynamically linked Qt libraries – the protection against reverse engineering provided by static linking is much better.


• Using Qt Quick Compiler that compiles QML to binary and protects against reading the Qt Quick parts of the application is an efficient way of further protecting your application.


• No need to provide possibility to modify software embedded into a device, thus making it possible to use capabilities of the hardware and the operating system to prevent modifications to system software.

In case you want to learn more about the ways to protect your application, feel free to contact us. We can help you to implement protection for your application both via technical and licensing means.

Source :- Qt Blog http://ift.tt/1BiAiLR

Licensing of new modules in Qt 5.5

With the release of Qt 5.4, we added LGPLv3 as a licensing option to Qt. Some of the new modules released in Qt 5.4 (Qt WebEngine, Qt Canvas3D and Qt WebView) where made available under GPLv2+, LGPLv3 and commercial licensing terms. The reason was that we believe that this license combination is a better match than LGPLv2.1 for our objective of supporting Free Software while at the same time making sure we have the necessary funding to develop Qt further in the years to come. For more details, please check out the blog post from last summer.

Qt 5.5 is now coming closer, and we expect to have the Alpha release for it ready in February. While the focus of Qt 5.5 has been mainly on improving stability and fixing bugs, there will also be a couple of new modules added with the release. As with Qt 5.4, some of this new functionality is available under a LGPLv3/GPLv2+ and commercial licenses.

After discussing and agreeing with the main contributors of the modules in question, the KDE Free Qt Foundation and some of our main stakeholders, we consider this the best way to move forward. The new modules will be available under LGPLv3/GPLv2+ and commercial licensing terms. This allows us to make these modules available to the Free Software community, as well as being able to support and further develop them in the long term. The two new modules that will get added to Qt 5.5 under the new licensing terms are Qt 3D and Qt Location.

Qt 3D existed as part of the Qt Mobility APIs that Nokia did on top of Qt 4.8. Over the last two years, developers from our partner KDAB have put a lot of effort into refactoring the code base and making the API more flexible and suitable for the future. The API is now a powerful tool to integrate 3D content into Qt, featuring both C++ and QML APIs. Check out the series of blog posts from KDAB for more details about the APIs. KDAB endorses and supports to license this module under GPLv2+ and LGPLv3 for the open source version of Qt.

Qt Location is also a module that was part of the Qt Mobility APIs for Qt 4.8. As with Qt 3D it underwent lots of changes moving from Qt 4.8 to Qt 5, and is now also ready to become part of Qt 5. The API works in conjunction with the existing Qt Positioning module providing APIs for mapping, place search and navigation. It also comes with both C++ and QML interfaces.

The Qt Quick Enterprise Controls have so far been only available to commercial licensees. They offer a lot of really useful functionality on top of the regular Controls. With Qt 5.5, The Qt Company is going to contribute these to the open source Qt Quick Controls under LGPLv3/GPLv2+. This will affect the licensing of the Qt Quick Controls, and they will also now be available under LGPLv3, GPLv2+ and commercial terms. In addition to making the existing Enterprise Controls available to the Free Software community, we will also add a couple of new features. Amongst them is a fully functional TreeView, probably one the largest missing feature in Qt Quick Controls for the desktop platforms.

As we move along with releases, we expect to continue to license functionality under LGPLv3/GPLv2+ and commercial terms. It allows The Qt Company to grow its investments into new functionality in Qt and make it available to the Free Software community.

Source :- Qt Blog http://ift.tt/1zQM4eT