Monday, January 2, 2017

Ad lister app with Meteor and CasperJS

The Problem

Recently I listed bunch of stuff on a local web listing site. Unfortunately they keep the ads for 30 days. After this period the adds are gone. I got frustrated by the fact I have to spend time to re-list all the stuff again. It gets worse if I wanted to list the stuff in other sites as well.
What if I can do it with one click...

The Solution

Here comes the little meteor app I came up with to do exactly this. All I have to do is to upload the photos, add the text and press the button. The way it works is simple - the pictures are stored on AWS S3 with metadata on MongoDB collection, the ad titles, text and other related information is stored in another MongoDB collection. Then for each 'submitter' I have a separate meteor package, which posts the ad.

Images orientation 

The html img tag shows the photo as it is taken, keeping the original orientation, but when the photo is opened by the browser itself, or by image viewer software it is rotated according the EXIF orientation flag. When the image is shown, the user can change its orientation from the web interface. It's done just by adding one of the classes and some CSS:
CSS:
div.show-image img.img90 {
    -ms-transform: rotate(90deg); /* IE 9 */
    -webkit-transform: rotate(90deg); /* Chrome, Safari, Opera */
    transform: rotate(90deg);
}

div.show-image img.img180 {
    -ms-transform: rotate(180deg); /* IE 9 */
    -webkit-transform: rotate(180deg); /* Chrome, Safari, Opera */
    transform: rotate(180deg);
}

div.show-image img.img270 {
    -ms-transform: rotate(270deg); /* IE 9 */
    -webkit-transform: rotate(270deg); /* Chrome, Safari, Opera */
    transform: rotate(270deg);
}
The image orientation selected by the user is also stored in the Files MongoBD collection along with the image other metadata. In order to get the right user selected orientation I use ImageMagic to rotate the image and strip all additional metadata from the image itself (like EXIF in JPEGs) as soon as the image is downloaded. I use Fibers/Future block the execution until all the images have been downloaded and rotated.

futures = _.map(files, function(file) {
    // Set up a future for the current job
    var future = new Future();
    // A callback so the job can signal completion
    var onComplete = future.resolver();
    /// Make async http call
    Meteor.call("downloadImage", file.url, dirPath, null, function(x){
        var imgPath = dirPath+"/"+x;
        s.paths.photos.push(imgPath);
        var rot = 0;
        if(file.rot) rot = file.rot;
        console.log("-rotate "  + rot);
        if(rot > 0){
            im.convert([imgPath, '-strip', '-rotate', rot, imgPath], onComplete);
        } else {
            // Inform the future that we're done with it
            onComplete(null, "");
        }
    }, function(e, r){});
    // Return the future
    return future;
});
Future.wait(futures);
console.log(_.invoke(futures, 'get'));

Once this is done, then all the submitters are executed. Each submitter has a collection, where a site relevant information is stored, like username, categories, price, etc. 
Currently I have only one submit package, for DoneDeal.ie site. It is even not fully complete as it adds only free listings and doesn't handle most of the site features.

The source code is published to https://bitbucket.org/nchokoev/adapp under the MIT license.

Saturday, January 31, 2015

Meteor accounts with custom login form

Meteor


After some exercises with PHP and MySQL I decided to dive deeper into the Javascript world. I know it doesn't make much sense, but bare with me.
I started developing a new app with the Meteor framework. My first impression of it - Amazing. I'm still trying to wrap my head around it as I'm a bit new to javascript as well.
I was struggling last day or so with the accounts. I added the accounts and the user interface packages:
meteor add accounts-password
meteor add twbs:bootstrap
meteor add ian:accounts-ui-bootstrap-3
All work as expected. I can create users, login, logout. no issue. ...except... I cannot easily remove the drop down on the log in page. It's a bit annoying.
I sat googling for a fair amount of time. There are of course many solution out there, but all they look to me a bit harder. Being lazy by nature I tough myself 'There must be an easier/clearer way'. On top of that I wanted to keep all the functionality those packages provide. Just wanted to remove the dropdown.
Looking at the code in I see I have to change only couple of lines there. I could go and just modify them, but it's a bit messy. What is there is a way to replace their template with my alternative, where I can change those lines keeping the rest of the functionality untouched? Sure there is! Let me introduce you the meteor-template-extension package.

The Actual Work


The first thing is to add the meteor-template-extension package to the project.
meteor add aldeed:template-extension

Then I created my own version of the '_loginButtonsLoggedOutDropdown' template from the 'ian:accounts-ui-bootstrap-3' package. I call it "My_loginButtonsLoggedOutDropdown" and place it in login.html:

<template name="My_loginButtonsLoggedOutDropdown">
    <div class="container">
<section class="panel">
        <header class="panel-heading">
            <strong>Welcome</strong> 
        </header>
        {{> _loginButtonsLoggedOutAllServices}}
    </section></div>
</template>

I my version of this template I just removed the dropdown and put some styling around.

The final thing is to replace the "_loginButtonsLoggedOutDropdown" with "My_loginButtonsLoggedOutDropdown", where the aldeed:template-extension comes handy. Somewhere in the client side js file:

Template.My_loginButtonsLoggedOutDropdown.replaces("_loginButtonsLoggedOutDropdown");

That's it! Next I put some very very simple CSS:
the CSS
.panel {
    width: 300px;
    margin-bottom: auto;
    margin-left: auto;
    margin-right: auto;
    margin-top: auto;
    background-color:#fff;
    border:1px solid transparent;
    -webkit-box-shadow:0 1px 1px rgba(0,0,0,0.05);
    box-shadow:0 1px 1px rgba(0,0,0,0.05);
    border-radius:2px;
}

.panel-heading {
    border-bottom:1px solid transparent;
    border-top-right-radius:3px;
    border-top-left-radius:3px;
    border-radius:2px 2px 0 0;
    padding:10px 15px;
    text-align:center;
}


Enjoy!

Tuesday, January 21, 2014

Smart Card Interface - ATR String

What is ATR?


The ISO/IEC 7816-3 standard specifies the communication between a smart card and a reader. The very first part of this communication is ATR (Answer To Reset) string, which the card sends straight after reset.
There are two types of reset defined in the standard - 'Cold Reset' and 'Warm Reset'. The ATR string may differ for those two cases.
In the ATR string the card encodes important information for the following communication. The length is variable and can be up to 32 bytes.
The ATR always starts with TS character, also called Initial Character. The TS character encodes the conversion used for further communication. The possible values for the initial character are 0x3B (direct conversion - '1' is high level) or 0x3F (inverse conversion - '1' is low level).
The second character of the ATR string is T0 - format character. T0 encodes the presence of Interface Characters TA1,TB1,TC1,TD1 (bits 7:4) and presence of Historical bytes (bits 0:3)
After T0 follow the optional Interface characters, followed by Historical bytes and TCK - end character (exclusive OR of all the characters).
The interface Characters encode information such as

  • protocol type

  • clock frequency and data rate parameters

  • programming voltage and current


If the reader wants to change any of the parameters, it can be done only first thing after receiving the ATR string following the PPS (protocol Parameter Selection) procedure, described in the ISO/IEC 7816.

Smart card interface schematic.


The schematic show a simple interface between TTL-UART and smart card.

CS1001 abstracts the smart card interface and the ISO/IEC 7816 T=0 protocol, providing simple interface using AT commands via UART.

cs1001_sch

Communication via terminal


The interface chip (U1 - CS1001) is using AT commands to work with the card.

To power on the card the command is 'CON' (for Card ON), to power it off - 'COFF' (for Card OFF).
>at con
3B 68 00 00 00 73 C8 40 13 00 90 00 
>at coff
>

TS = 0x3B - Direct conversion

T0 = 0x68 -

- 0x6 (0110) - TB1 and TC1 are present

- 0x8 (1000) - 8 Historical bytes

The absence of TD1 means no further interface characters are present.

TB1 = 0x00 - this character is deprecated.

TC1 = 0x00 - extra guard time integer, N=0 (default)

Historical bytes:

T1 = 0x00 - Category indicator. 0x00 - the last 3 historical bytes are the status indicator.

T2 = 0x73 - TLV - nesting proprietary data objects.

T3 = 0xC8

T4 = 0x40

T5 = 0x13 - End of TLV structure.

T6 = 0x00 - Status indicator byte 1.

T7 = 0x90 - Status indicator byte 2.

T8 = 0x00 - Status indicator byte 3.

TCK is absent as the T=0 only is indicated (by default).

Saturday, September 14, 2013

STM32 Firmware Loader

For some of my hobby projects I'm using STM32 MCU. To make my life easier when loading different firmwares I created this simple STM32 Firmware Loader.

Using a software USB boot-loader has some disadvantages:

  • It has to occupy some part of the user Flash, which leads to less available Flash memory (usually a whole page)

  • it is difficult (or impossible) to protect it from accidental erase or data corruption.

  • the user firmware has to be build with the boot-loader in mind

  • it has to have own USB PID/VID. Having a VID is a little bit expensive, especially for small hobby projects.


The solution I have is to use the STM32 internal loader. This allows me to use the whole Flash memory for my user code. On top of that I have some more flexibility with this solution - I have a control over the hardware reset pin from the software.

However, all it comes at a price - an external components are needed. The schematic is very simple. A popular FTDI FT232 USB-to-UART converter is used.

Two GPIO from FT232 are used to control STM32_RESET and STM32_BMODE pins, and two pins for UART communication.

1zowJGjuo2TXOMcYcWa3VIGP6CFQd0uE

Operation is simple - when a firmware has to be loaded, the boot mode pin is set to enable the internal boot-loader and a hardware reset is issued. The STM32 goes to boot-loader mode. Via UART the new firmware is loaded, the boot pin is set to a state to enable user code execution and the STM32 is reset again. At this point the new firmware gets executed.

The source code can be found on https://code.google.com/p/stm32-loader/. The GUI is based on Qt.

Subscribe for our NewsLetter!

Wednesday, September 11, 2013

gnome-mplayer remote with qt and libssh2

This is project I've created some time ago for gnome-mplayer remote control. It uses qt as a GUI, libssh2 for ssh communication and dbus to control the player.

The plan was to put all those peaces together and make a remote control for this media player. I started a project, which you can find here: https://bitbucket.org/nchokoev/qtsshremote.

The remote control uses dbus commands over ssh to control the gnome-mplayer.

First thing is to connect to the host and establish ssh connection and get ansi terminal. It's nice to use a terminal as we can see when the command is completed. For this I'm using a little trick - I'm changing the prompt string. Once I receive this string I know the command is executed.

The first command is to set the xorg display environment variable:
"export DISPLAY=:0\n"

To check if there is gnome-mplayer running I'm using the following code. It checks the running processes for 'gnome-mplayer' and gets their PIDs.
"pgrep gnome-mplayer\n"

Setting DBUS_SESSION_BUS_ADDRESS:
QString s = "$(tr '\' '\\n' < /proc/$(pgrep gnome-mplayer | head -1 )/environ | sed -e 's/^/export /')\n";
  execSSHCmd((char*)s.toUtf8().constData(),s.size(), buf, 0);
s = "echo $DBUS_SESSION_BUS_ADDRESS\n";
  execSSHCmd((char*)s.toUtf8().constData(),s.size(), buf, 0);

To get the files and folders I'm using 'ls' command. The only difference is that I force the output to be an entry per line (-1) and no colours (--color=none). It makes much easier the output parsing.
"ls -1 --color=none\n"

The other part of the code is pretty straight forward. It uses the gnome-mplayer dbus messages to control the player.

The nice thing is that it is very easy to open and close the player as well as navigate the the desired media file and play it.

You can download the code and use it without any restrictions. However, I'll appreciate if you leave a feedback or if you send me any modifications you've made.

I hope you find it useful.

Subscribe for our NewsLetter!

Monday, September 9, 2013

GSM Security - attacks on the GSM protocols

file000612993608GSM Security is getting more important. There are many successful attacks on GSM communication reported recently. And the list keeps growing. Today is extremely easy to get access to a technology which allows you to record GSM session and possible decrypt it.

In this article I will mention some of the early attempts to decypher the GSM communication. However, there are projects explaining in more details about the GSM attack itself (like https://srlabs.de/decrypting_gsm/) and providing more information.

Many GSM users rely on the GSM cryptographic system to transfer information securely. Since the late 80's, when GSM network become popular, its cryptographic system is a subject of many attacks. The first attacks on A5 algorithm are purely theoretical but recently there are reports for some successful practical attacks too. The rainbow table attack is one of the most successful attacks on A5 algorithm. Using this approach breaking the cipher is possible within a minute if few packets of cipher text are available. The rainbow tables size is few terabytes, but that is not a problem those days. Furthermore, this method allows using different size of the rainbow tables, which lead to different calculation time breaking the cipher.

The new 3G mobile network uses more advanced KASUMI cipher. Even the KASUMI is better than the old A5 cipher, its implementation makes it weaker than MISTY1. There are also a few attacks on KASUMI which are not applicable on the original MISTY1 cypher.

There are many attacks and cryptanalysis of the A3/A8, COMP128 and A5 algorithms.


A5/1 is developed in 1987, and A5/2 - in 1989. Both protocols are kept secret. However the algorithms ware entirely reverse engineered in 1999 by Marc Briceno from GSM telephone and A5/2 was broken at the same time.

A5/1 was broken on academic level in 1997, but the firs attack on the real cipher is in 2000 by  Alex Biryukov, Adi Shamir and David Wagner.

In 2003, Barkan et al. published several attacks on GSM encryption. The first is an active attack. GSM phones can be convinced to use the much weaker A5/2 cipher briefly. A5/2 can be broken easily, and the phone uses the same key as for the stronger A5/1 algorithm. A second attack on A5/1 is outlined, a ciphertext-only time-memory tradeoff attack which requires a large amount of pre computation.

In 2006, Elad Barkan, Eli Biham, Nathan Keller published the full version of their 2003 paper, with attacks against A5/X Ciphers. A precomputed table is used to attack A5/2 and the key can be found in less than a second on a personal computer using one packet of encrypted information.

In 2007 Universities of Bochum and Kiel started a research project to create a massively parallel FPGA based crypto accelerator COPACOBANA. COPACOBANA was the first commercially available solution using fast time-memory trade-off techniques that could be used to attack the popular A5/1 and A5/2 algorithms, used in GSM voice encryption, as well as the Data Encryption Standard (DES). It also enables brute force attacks against GSM eliminating the need of large precomputed look-up tables.

In 2008, the group The Hackers Choice launched a project to develop a practical attack on A5/1. The attack requires the construction of a large look-up table of approximately 3 terabytes. Together with the scanning capabilities developed as part of the sister project, the group expected to be able to record any GSM call or SMS encrypted with A5/1, and within about 3–5 minutes derive the encryption key and hence listen to the call and read the SMS in clear. But the tables weren't released.

A similar effort, the A5/1 Cracking Project, was announced at the 2009 Black Hat security conference by cryptographers Karsten Nohl and Sascha Krißler. It created the look-up tables using Nvidia GPGPUs via a peer-to-peer distributed computing architecture. Starting in the middle of September 2009, the project ran the equivalent of 12 Nvidia GeForce GTX 260. According to the authors, the approach can be used on any cipher with key size up to 64-bits.

In December 2009, the A5/1 Cracking Project attack tables for A5/1 were announced by Chris Paget and Karsten Nohl[8]. The tables use a combination of compression techniques, including rainbow tables and distinguished point chains. These tables constituted only parts of the 2TB completed table, and had been computed during three months using 40 distributed CUDA nodes, and then published over BitTorrent. More recently the project has announced a switch to faster ATI Evergreen (GPU family) code, together with a change in the format of the tables and Frank A. Stevenson announced breaks of A5/1 using the ATI generated tables.

There are some theoretical attacks on KASUMI. In 2001, an impossible differential attack on six rounds of KASUMI was presented by Kühn (2001).

In 2005, Israeli researchers Eli Biham, Orr Dunkelman and Nathan Keller published a related-key rectangle (boomerang) attack on KASUMI that can break all 8 rounds faster than exhaustive search. The attack requires 254.6 chosen plain texts, each of which has been encrypted under one of four related keys, and has a time complexity equivalent to 276.1 KASUMI encryptions. While this is not a practical attack, it invalidates some proofs about the security of the 3GPP protocols that had relied on the presumed strength of KASUMI.

In 2010, Dunkleman, Keller and Shamir published a new attack that allows to recover a full A5/3 key by related-key attack. The time and space complexities of the attack are low enough that the authors carried out the attack in two hours on a modest desktop computer even using the unoptimised reference KASUMI implementation. The authors note that this attack may not be applicable to the way A5/3 is used in 3G systems; their main purpose was to discredit 3GPP's assurances that their changes to MISTY wouldn't significantly impact the security of the algorithm.

Some time ago I created an article about GSM communication protocol and the attempts to be compromised.

Subscribe to the security newsletter and get the file.

Monday, August 12, 2013

Media SSH Remote Control with Qt and libssh2

After setting up a media center from an old laptop and building libssh2 library with Visual Studio 2010 it's a time to  go a step further and add a simple remote control for the gnome-mplayer - the  SSH Remote Control with Qt and libssh2.

Gnome-mplayer supports many media formats and is very lightweight - runs smoothly on a low end machines. A nice feature of this player is that it can be controlled remotely via ssh using dbus commands.

Using dbus commands over SSH has many advantages:

  • SSH is secure

  • Can access files and folders

  • Easy to implement (thanks to libssh2 library)


I made a simple Qt project to demonstrate remote control for gnome-mplayer using dbus commands over ssh. The project source code for this Media SSH Remote Control with Qt and libssh2 can be found here.

Please, leave your feedback.