Tag: drwxr

RFID x NFC

Nos dias atuais tem se tornado comum o uso da identificação por radiofrequência / Radio Frequency Identification (RFID). Como por exemplo podemos citar crachás em empresas, cartões de pagamento (ex. cartão de débito), cartões de transporte públicos (ex. cartão de metro, ônibus, etc), Tags para estacionamento e praças de pedágios, entre muitos outros exemplos onde podemos aplicar.

Nos últimos anos, um novo termo começou a expandir-se em conexão com RFID: comunicação de campo próximo / Near Field Communication (NFC).
O RFID e o NFC são muitas vezes confundidos, mas definitivamente não são os mesmos.
Embora os leitores NFC possam ler e escrever em algumas tags RFID, a NFC possui mais capacidades do que RFID e permite uma maior variedade de usos. Você pode pensar em NFC como uma extensão da RFID, com base em alguns dos muitos padrões RFID para criar uma plataforma de troca de dados mais ampla.

O que é RFID?


Imagine que você está sentado na sua varanda à noite. Você liga a luz da varanda, e você pode ver seu vizinho quando ele passa perto de sua casa porque a luz reflete nele e você pode observar.
Isso é RFID passivo. O sinal de rádio de um leitor RFID passivo atinge uma etiqueta, a etiqueta absorve a energia e “reflete” sua identidade.

Agora imagine que você acenda a luz da sua varanda, e seu vizinho vê isso e acende a luz da varanda da casa dele para que você possa vê-lo acenando de sua varanda.
Isso é RFID ativo. O RFID ativo pode suportar um alcance mais longo, porque o receptor possui sua própria fonte de energia e, portanto, pode gerar seu próprio sinal de rádio em vez de depender da energia que absorve do remetente (RFID passivo).

O RFID é muito parecido com as duas varandas utilizadas nos exemplos anteriores. Você e seu vizinho se conhecem, sabem os rostos uns dos outros, mas você realmente não sabe muito além disso sobre ele. Você não troca mensagens significativas.
RFID não é uma tecnologia de comunicação. Em vez disso, é uma tecnologia projetada para identificação. As etiquetas RFID podem conter uma pequena quantidade de dados e você pode ler e escrever a partir de leitores de RFID, mas a quantidade de dados de que é falada é trivial.

O que é NFC?


Agora imagine que outro vizinho passe perto da sua varanda, e quando você o vê, você acaba convidando ele para a sua varanda para conversarem. Ele aceita seu convite, e você se senta junto, troca informações sobre as vidas de ambos e desenvolvem um relacionamento. Vocês se falam um com o outro e vocês se escutam durante alguns minutos. Isso é NFC.

A tecnologia NFC foi projetada para desenvolver a RFID, permitindo trocas mais complexas entre os participantes. O NFC também permite que você escreva dados para certos tipos de etiquetas RFID usando um formato padrão, independente do tipo de tag. Também é possível se comunicar com outros dispositivos NFC em uma troca bidirecional ou duplex.
Os dispositivos NFC podem trocar informações sobre os recursos uns dos outros, trocar registros e informações.



Continua…

Tags : , , ,

“Underlining” problems of software implementation

Today, when considering security aspects, there are many different techniques to implement software and systems, most of them focus on implementation and test/verification. Majority of research in this area is related to develop new tools to check the integrity of the software later, during the verification phase.

To understand design phases that this post considers as baseline, considers the following systems life cycle phases:

Figure 1 – System development Life Cycle

This post introduces a life cycle phase that can be called as conceptual phase. The conceptual phase sometimes is “neglected” due to misunderstood and normally including excuses related to restrictions such as cost, time, and limited resources (summarized as “wasting time” with a conceptual phase).

In IT business, this consideration of time is more crucial because technology evolution has a high pace and launching solutions to market is crucial to survive and guarantee a market share and right time to market.

To support this conceptual phase, we presents a tool called “IDEF0” to give an example and illustrated the importance of knowing everything that interacts with your system or function. The objective is to provide an early knowledge about your System of Interest anticipating events, states and conditions that will emerges during implementation phase or even worst, during operation phase (after deploy, during users usage).

First step is to understand that the system that you will implement has interfaces to others (e.g. users, systems, environment, etc.) requiring inputs, processing these inputs (function/system objective) and providing outputs which are subjected, during “processing”, to controls and mechanism entities (e.g. power, statuses, etc.) so your system is no more a lonely entity and you anticipate stakeholders that interacts to your system and what is normally expected from them.

Figure 2 – IDEF0 Function modeling

Now, your system has a set of interfaces that you need to understand and so, create a set of requirements that met these interfaces (what it shall accomplish). At this point, when you need to understand the users or other systems’ needs, we bring a concept that help you develop better systems, this concept is called, Systems Thinking.

Systems thinking is a capability of developer to view all entities that comprise the system or where it is part of (holistic approach), with System being a set of parts that relate to each other. The most important element in a system view – and sometimes neglected – is the relations among these entities.

With the tool presented and in this conceptual phase it is essential to have an abstraction level of your architecture to understand and identify all the relations of your System of Interest, which is your system under analysis. This abstraction level requires an approach that avoids the implementation decisions (e.g., it will run a specific Operating System) and thinking just about functions and exchanges between entities and stakeholders (e.g. data, energy).

The interface map and correlation of functions empowers developers with the capability to create scenarios that the system will operate and understand the possible threats that can emerge from these scenarios (e.g. if system lose specific input).

Figure 3 – Your system and the interfaces consideration

After this initial analysis, you have a list of your system functions (it shall comply), you have a map of your systems interfaces and you have concepts of operation (or scenarios) for your system (e.g. normal operation, power interruption). With these information, and considering the security aspects you are able to conduct a preliminary security assessment; anticipating cases or flaws prior to implementation or deploy, reducing future fixes (costly).

Figure 4 – Committed life cycle cost against time

During the conceptual phase analysis, you design the system in a high abstraction level allowing early analysis and deriving requirements and constraints that your system requires (e.g. input values – string with X characters – avoiding buffer overflows).

After, it is possible to proceed to the next phase, implementation, where the “code” is developed considering these requirements and constraints raised during conceptual phase that complements the initial objectives. This approach can also be called as Requirements Driven, although this term is very common during software development environment, in general, it is not regarding the entire lifecycle or as proposed during a conceptual analysis in a higher abstraction layer.

An interesting case about architectural security is related to Redis (read more at http://antirez.com/news/96)

Conclusion,

There are problems related to security that cannot be classified as an implementation issue (e.g. flaws) but a bad requirement specification or lack of it, like environment and operational considerations/analysis. Therefore, it could be anticipated with a conceptual phase analysis, which would lead to the development of a more resilient architecture.

This is a simple view of the importance that must be given to a conceptual phase and consequently requirements definitions when developing a system or implementing a code. I hope that this post may be useful to open your mind and if you have, some questions contact us to clarify the concepts and the perspective about this subject.

Tags : ,

Installing RTL-SDR (RTL2832U) driver

This content is a piece of our initiative to explain how to start your studies with RTL-SDR.

In this post we’ll explain about how to install the rtl-sdr driver.

To install the RTL-SDR device on a Linux computer is relatively quick and easy.

These instructions are designed to run on Linux distributions based on Debian or Ubuntu.

Installing the drivers:

1. Open the terminal and make sure you are in the home directory.

2. Update your Linux distribution:

sudo apt-get update

3. Install the necessary tools such as: git, cmake, build-essential

sudo apt-get install git

sudo apt-get install cmake

sudo apt-get install build-essential

4. Install the library called “libusb-1.0-0-dev” which provides access to USB devices.

sudo apt-get install libusb-1.0-0-dev

5. Download and install the RTL2832U from vendor site:

git clone git://git.osmocom.org/rtl-sdr.git

cd rtl-sdr/

mkdir build

cd build

cmake ../ -DINSTALL_UDEV_RULES=ON

make

sudo make install

sudo ldconfig

sudo cp ../rtl-sdr.rules /etc/udev/rules.d/

6. Create a “blacklist” to the default driver which loads automatically using the RTL-SDR device as a TV receiver, because this isn’t the functionality we want to use (tv receiver).

A. Access as administrator the directory: /etc/modprobe.d

B. Create a new file called “blacklist-rtl.conf” and add the following line in the file:

blacklist dvb_usb_rtl28xxu

blacklist rtl2832

blacklist rtl2830

C. Save the file and reboot the machine.

7. After reboot the machine, test if the device is actually running. To test type the follow command in the terminal:

rtl_test -t

(rtl_test -t, command)

Don’t worry with the follow messages:

“PLL not locked”

“No E4000 tuner found, aborting”.

If you see these messages above it is a sign that your driver and your device is working properly and you are ready to install some applications like GQRX, Dump1090, CubicSDR and others…

Tags : , , , , ,

FM transmitter through a Raspberry pi

In this post we’ll turn the Raspberry Pi into an FM transmitter in a few steps.

ATTENTION: remember that in some countries the radio transmissions of any kind are subject to federal laws and regulations.

This is a simple and very interesting article.

To turn your raspberry pi in FM transmitter we will use the rpitx of F5OEO (https://github.com/F5OEO/rpitx) , rpitx is a radio transmitter for Raspberry Pi (B, B+, PI2, PI3 and PI zero) that transmits RF directly to GPIO. It can handle frequencies from 5 KHz up to 500 MHz.

For installing do the following:

git clone https://github.com/F5OEO/rpitx

cd ./rpitx

sudo ./install.sh

The install script (install.sh) will download and install all the needed dependencies. This takes a while.

We gonna  connect a ~20cm or so plain wire to GPIO 18 (which is pin 12 on header P2) to act as an antenna, and tune an FM radio.

The optimal length of the wire depends the frequency you will want to transmit.

GPIO pins (General Purpose Input/Output) are ports (pins) programmable that can be used to input and/or output data. They are mainly used to communicate with external devices like microcontroller or microprocessor.

(GPIO Raspberry pi)
(Raspberry pi with antenna)

In this article we going to transmit FM, so we gonna use the pifm.

Pifm converts an audio file (Wav, 48KHz, 1 channel, pcm_s16le codec) to Narrow band FM (12.5khz excursion) and outputs it to a .ft file. Assuming your audio file is in your current working directory.

./pifm gunsnroses.wav fm.ft

Then after execute the command that created the fm.ft, lets execute the command bellow that will transmit the audio at 92.0MHz (you can change).

sudo ./rpitx -m RF -i fm.ft -f 92000 -l

Video:

Tags : , , , , , , , ,