For those who are interested in knowing how steep is your N900, or the
object that supports it. Meet the 4×4 inclinometer.

I developed it to use in my car, hence the name 4×4 inclinometer. Using this
application I can know the slope of the obstacles or the ground below my
car.

According to the manual of the car, it can be in an angle of heel of 45 degrees
with no problem, something higher than this is at my own risk. When I read
this information, just imagined the software for the N900:)

The current version depends on Qt 4.6 with the animation framework. The
animation is used to rotate the images of the car, smoothing the movement. I
am not an expert in gimp, so forgive me for the images poorly done. Next
version I will put a simple support for themes.

The intallations files are already in extras-devel, so you just need to
apt-get it.
And the sources are available at:

http://git.zimmerle.org/?p=inclinometer.git;a=summary

The car image and the application background are Trademark of Troller Veiculos
Especias S/A, http://www.troller.com.br

• 2 Comments

The iptables package is on maemo extras devel. There is no support for connection state on the device Kernel consequently the NAT is not working. I tried to compile the modules, but I found myself in trouble trying to load them at the device. If you want to flash a kernel with support for connection state there is one available at my personal repository (read: mWall :: netfilter + ui for maemo for more information). Antoher discussion about that modules can be found at: http://forums.internettablettalk.com/showthread.php?t=30916&page=1

• 0 Comments

For those who are playing with maemo and network, now are available at maemo
extras-devel {fremantle|diablo} the tcpdump package and its dependency (libpcap) working
like a charm

• 0 Comments

Something that certainly bothers me is the fact that i am always online independent of the network. I walk with my n900 in the pocket and sometimes I am using 3g, sometimes using wifi. I am jumping from trusted to untrusted wifi spots, and I have the strange feeling that maybe once (or more…) I will be part of a honeypot, malicious network or something like that.

As part of this type of network my device can be easily identified as an N900. (e.g. MAC address). Once the device is identified a person or a malicious software can start to guess passwords (rootme?) and can try to exploit softwares that are under development.

Avoiding been hacked on that situation I decided to write a small firewall UI for the n900 (netfilter/iptables back end), that allows me to block any incoming connection that is not authorized.

This is just a very first version of the firewall, a lot to be done yet. To install it on your device, check for mWall at my personal repository.

You can install my repository by clicking here: zimmerle’s repo.

I also provide in my repository: the iptables package and a kernel with support to iptables state match. The iptables binary was marked with the suid bit, allowing its execution by users without super powers. But this should be fixed in the next release.

Let me advise you that the firewall rules are not permanent, I mean, you need to run the firewall in every boot. It is under development

The code is available at: http://git.zimmerle.org

• 1 Comment

I always had problems in reading my rss feeds because I never found any good rss reader (google things are not options, I don’t like them) they are too weird to me… The fact is: I’m not able to read my friends – or enemies –  feeds, but I’m a good email reader (Usually I not reply, but I always read) so I decided to search a way to send the feeds to my email so, I will be able to read them.

I found a nice toy to do that, it is called: rss2email. Really nice toy. I just placed it to run on my server and it started to deliver my content

After one week using it, I saw that I didn´t subscribe any new feed. Imagine yourself logging in a server to add a new rss feed… nah too complicated. Too much work for me.

So I decided to create a new mail alias to receive commands and process them by its procmail rules . Well ok, what about the security? And if that MTFK friend decide to clean up my entire feeds? Thats why I decided to verify my gpg signature before process the commands and for that a combination of procmail rules and my cute Perl script is amazing

Here goes my Perl script and enjoy:

#!/usr/bin/perl
#
# Copyright (C) 2009  Felipe Zimmerle da N. Costa
#                     <felipe at zimmerle dot org>
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see <http://www.gnu.org/licenses/>.
#
#

# Config.
$config{'trusted'} = 'E8B11277';
$config{'debug'} = 1;
$config{'rss2email'} = '/your/path/to/rss2email/rss2email.py';
$config{'dat'} = '/your/path/to/rss2email/feeds.dat';
$config{'mailto'} = 'your@mail.something';
$config{'sendmail'} = '/usr/sbin/sendmail';
$config{'label'} = '/your/path/to/labels.txt';
$config{'mail'} =<<EOT;
To: $config{'mailto'}
From: RMO Report <felipe-rss\@zimmerle.org>
Subject: rmo report

RMO Results:

RESULTS

EOT

# Do not edit above this line.
use IPC::Open3;
use IO::Handle;
use Encode;

undef $/;
my $mail = <>;
$mail =~ s/=(\n|\r|\n\r|\r\n)//gom;
$mail =~ s/=3D/=/gom;
$mail =~ s/=20/ /gom;

my ($IN,$OUT,$ERR) = (IO::Handle->new(), IO::Handle->new(),
						IO::Handle->new());
open3($IN, $OUT, $ERR, "gpg") || die "Unable to run: $!\n";
print $IN $mail;
close($IN);

my $from,@cmd,$results,$pr,$ops;

# Parser the commands.
my $o = <$OUT>;
$o =~ s/^add (\"[A-z0-9_. -]+\"|[A-z0-9_.-]+) (.*)/@{[eval { $pr++ ; $cmd[@cmd] =
		["add", "$2", "@{[eval {$a = $1; $a =~ s@^(\")(.*)(\"$)@$2@; $a;}]}"] }]}/gome;
$o =~ s/^(del|delete) ([0-9]+)/@{[eval { $pr++; $cmd[@cmd] = ["delete", "$2"] if $pr < 2;
		$ops++ if $pr > 1 }]}/gome;
$o =~ s/^list/@{[$cmd[@cmd] = ["list"]]}/gome;
close($OUT);

# Check signature.
my $e = <$ERR>;
$from = $1 if $e =~ m/.*key ID ([A-z0-9]+)(\n|\r|\n\r|\r\n)gpg: Good signature from.*/m;
close($ERR);

die "Wow a hacker:\n$mail" if $from ne $config{'trusted'};

foreach my $c (@cmd) {
	my $c_ = $config{'rss2email'} . " " . $config{'dat'} .
				" " . $c->[0] . " " . $c->[1];
	$results .= "Command: $c_\n" . `$c_` . "\n";
	`echo $c->[2],$c->[1] >> $config{'label'}` if $c->[0] eq "add";
}
$results .= "\nDelete request is just welcome if its come " .
		" alone. $ops delete" .
		"s"?"":$ops>1 .  " ignored.\n" if ($ops > 0);

$config{'mail'} =~ s/RESULTS/$results/;

open(S, "|$config{'sendmail'} -t $config{'mailto'}") or die " " .
	"Unable to run sendmail: $!\n";
print S $config{'mail'};
close(S);

I really love Perl. Amazing, just few lines and my problem was solved ;P

• 0 Comments

This document explains the Cable Association (cba) between a MS Windows host and a IOGear HUB [1] using the WiMedia application [2]. The logs analized here have been generated by a usb sniffer, usbsnoop [3]. This analysis was made to clarify the cable association specification. It’s the result of one day’s work by me and my friend Alex.

The analized log can be downloaded here: usbsnoop-iogear-dwa.log

According to the specifications something like that should happen:

Our analisys is divided into blocks. Each block has a usb control message. They are:

• Association information
• Host information
• Association request
• Second association request
• Setting association request

Our first usb_message_control is a request of information association [4].

[12 ms]  >>>  URB 5 going down  >>>
-- URB_FUNCTION_CLASS_INTERFACE:
  TransferFlags          = 00000001 (USBD_TRANSFER_DIRECTION_IN, ~USBD_SHORT_TRANSFER_OK)
  TransferBufferLength = 00000100
  TransferBuffer       = 897ffd48
  TransferBufferMDL    = 00000000
  UrbLink                 = 00000000
  RequestTypeReservedBits = 00000001
  Request                 = 00000001
  Value                   = 00000000
  Index                   = 00000000
[12 ms] UsbSnoop - MyInternalIOCTLCompletion(bab39db0) : fido=00000000, Irp=896c8008, Context=897bd968, IRQL=2
[12 ms]  <<<  URB 5 coming back  <<<
-- URB_FUNCTION_CONTROL_TRANSFER:
  PipeHandle           = 89923990
  TransferFlags        = 0000000b (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK)
  TransferBufferLength = 00000019
  TransferBuffer       = 897ffd48
  TransferBufferMDL    = 8a37b4c0
00000000: 19 00 02 00 00 01 00 01 00 00 00 00 00 00 00 02
00000010: 00 01 00 01 00 6c 00 00 00

  UrbLink              = 00000000
  SetupPacket          =
    00000000: a1 01 00 00 00 00 00 01

These colored bytes represent:

In this block we have a GET_ASSICIATION_INFORMATION [4] request with an ASSOCIATION_INFORMATION [5] anwser. This ASSOCIATION_INFORMATION are composed by two ASSOCIATION_REQUEST [6], one is a RetriveHostInfo request and the another one is AssociateWUSB [7].

Back to top

As a response of our first usb_message_control request, bellow is the host info.

[12 ms]  >>>  URB 6 going down  >>>
-- URB_FUNCTION_CLASS_INTERFACE:
  TransferFlags          = 00000000 (USBD_TRANSFER_DIRECTION_OUT, ~USBD_SHORT_TRANSFER_OK)
  TransferBufferLength = 00000054
  TransferBuffer       = 8a365268
  TransferBufferMDL    = 00000000
    00000000: 00 00 02 00 01 00 01 00 02 00 00 00 00 10 10 00
    00000010: 13 c7 31 42 52 44 30 30 32 30 30 30 c4 9a d5 70
    00000020: 08 00 02 00 10 33 0c 00 2a 00 57 00 69 00 43 00
    00000030: 65 00 6e 00 74 00 65 00 72 00 20 00 57 00 69 00
    00000040: 72 00 65 00 6c 00 65 00 73 00 73 00 20 00 55 00
    00000050: 53 00 42 00
  UrbLink                 = 00000000
  RequestTypeReservedBits = 00000001
  Request                 = 00000003
  Value                   = 00000101
  Index                   = 00000000
[12 ms] UsbSnoop - MyInternalIOCTLCompletion(bab39db0) : fido=00000000, Irp=896c8008, Context=89b253a8, IRQL=2
[12 ms]  <<<  URB 6 coming back  <<<
-- URB_FUNCTION_CONTROL_TRANSFER:
  PipeHandle           = 89923990
  TransferFlags        = 0000000a (USBD_TRANSFER_DIRECTION_OUT, USBD_SHORT_TRANSFER_OK)
  TransferBufferLength = 00000054
  TransferBuffer       = 8a365268
  TransferBufferMDL    = 8a37b4c0
  UrbLink              = 00000000
  SetupPacket          =
    00000000: 21 03 01 01 00 00 54 00

These colored bytes represent:

This is block is structured as a HOST_INFO [8]. Its request is SET_ASSOCIATION_RESPONSE.



Back to top

As requested at the first data exchange, this is the information about the device:

[12 ms]  >>>  URB 7 going down  >>>
-- URB_FUNCTION_CLASS_INTERFACE:
  TransferFlags          = 00000003 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK)
  TransferBufferLength = 0000002c
  TransferBuffer       = 8a4c50a8
  TransferBufferMDL    = 00000000
  UrbLink                 = 00000000
  RequestTypeReservedBits = 00000001
  Request                 = 00000002
  Value                   = 00000200
  Index                   = 00000000
[13 ms] UsbSnoop - MyInternalIOCTLCompletion(bab39db0) : fido=00000000, Irp=896c8008, Context=8a3c0f58, IRQL=2
[13 ms]  <<<  URB 7 coming back  <<<
-- URB_FUNCTION_CONTROL_TRANSFER:
  PipeHandle           = 89923990
  TransferFlags        = 0000000b (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK)
  TransferBufferLength = 0000002c
  TransferBuffer       = 8a4c50a8
  TransferBufferMDL    = 8a37b4c0
    00000000: 02 00 04 00 6c 00 00 00 01 10 10 00 2a 5e 70 14
    00000010: ab 74 ec 49 e1 59 15 03 ee f6 f9 6c  04 10 02 00
    00000020: 01 00 08 00 02 00 09 04 0b 00 40 00
  UrbLink              = 00000000
  SetupPacket          =
    00000000: a1 02 00 02 00 00 2c 00

These colored bytes represent:

This block contains the information about the device, it exchange information about the device id, supported band groups and device friendly name [9].


Back to top

The same request as above but now the response is complete with the device friendly name.

[13 ms]  >>>  URB 8 going down  >>>
-- URB_FUNCTION_CLASS_INTERFACE:
  TransferFlags          = 00000003 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK)
  TransferBufferLength = 0000006c
  TransferBuffer       = 89ae84c0
  TransferBufferMDL    = 00000000
  UrbLink                 = 00000000
  RequestTypeReservedBits = 00000001
  Request                 = 00000002
  Value                   = 00000200
  Index                   = 00000000
[13 ms] UsbSnoop - MyInternalIOCTLCompletion(bab39db0) : fido=00000000, Irp=896c8008, Context=8a573930, IRQL=2
[13 ms]  <<<  URB 8 coming back  <<<
-- URB_FUNCTION_CONTROL_TRANSFER:
  PipeHandle           = 89923990
  TransferFlags        = 0000000b (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK)
  TransferBufferLength = 0000006c
  TransferBuffer       = 89ae84c0
  TransferBufferMDL    = 8a37b4c0
    00000000: 02 00 04 00 6c 00 00 00 01 10 10 00 2a 5e 70 14
    00000010: ab 74 ec 49 e1 59 15 03 ee f6 f9 6c 04 10 02 00
    00000020: 01 00 08 00 02 00 09 04 0b 00 40 00 49 00 4f 00
    00000030: 47 00 45 00 41 00 52 00 20 00 57 00 55 00 53 00
    00000040: 42 00 20 00 48 00 75 00 62 00 00 00 00 00 00 00
    00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00000060: 00 00 00 00 00 00 00 00 00 00 00 00
  UrbLink              = 00000000
  SetupPacket          =
    00000000: a1 02 00 02 00 00 6c 00

These colored bytes represent:

Back to top

This block communicates the success of the cable association operation [10]. If the association is not succeded an AssociationStatus (Attr id: 0x4 and Attr length: 0x4) is expected with the reason. The reason should be one of the listed bellow:

• 0x1, Association unsuccessful
  
• 0x2, Malformated association request
  
• 0x3, Association type not supported

[10589 ms]  >>>  URB 9 going down  >>>
-- URB_FUNCTION_CLASS_INTERFACE:
  TransferFlags          = 00000000 (USBD_TRANSFER_DIRECTION_OUT, ~USBD_SHORT_TRANSFER_OK)
  TransferBufferLength = 0000004e
  TransferBuffer       = 8a003530
  TransferBufferMDL    = 00000000
    00000000: 00 00 02 00 01 00 01 00 02 00 01 00 02 00 04 00
    00000010: 4e 00 00 00 02 10 30 00 13 c7 31 42 52 44 30 30
    00000020: 32 30 30 30 c4 9a d5 70 2a 5e 70 14 ab 74 ec 49
    00000030: e1 59 15 03 ee f6 f9 6c d7 a6 f4 4c 6d 88 0f be
    00000040: b6 0c 25 ef 6f 24 a3 ed 04 10 02 00 01 00
  UrbLink                 = 00000000
  RequestTypeReservedBits = 00000001
  Request                 = 00000003
  Value                   = 00000201
  Index                   = 00000000
[10623 ms] UsbSnoop - MyInternalIOCTLCompletion(bab39db0) : fido=00000000, Irp=896f0008, Context=896caa40, IRQL=2
[10623 ms]  <<<  URB 9 coming back  <<<
-- URB_FUNCTION_CONTROL_TRANSFER:
  PipeHandle           = 89923990
  TransferFlags        = 0000000a (USBD_TRANSFER_DIRECTION_OUT, USBD_SHORT_TRANSFER_OK)
  TransferBufferLength = 0000004e
  TransferBuffer       = 8a003530
  TransferBufferMDL    = 898aac20
  UrbLink              = 00000000
  SetupPacket          =
    00000000: 21 03 01 02 00 00 4e 00

These colored bytes represent:

Back to top

¹ CHID, Conection Host Identify
² CC, Connection Context



[1] http://www.iogear.com/product/GUWH104KIT/
[2] http://www.iogear.com/support/dm/driver/GUWH104KIT#display
[3] http://benoit.papillault.free.fr/usbsnoop/
[4] Association Models Supplement to the Certified Wireless Universal Serial Bus Specification
Revision 1.0 - Table 4-1
[5] Association Models Supplement to the Certified Wireless Universal Serial Bus Specification
Revision 1.0 - Table 4-3
[6] Association Models Supplement to the Certified Wireless Universal Serial Bus Specification
Revision 1.0 - Table 4-4
[7] Association Models Supplement to the Certified Wireless Universal Serial Bus Specification
Revision 1.0 - Table 4-5
[8] Association Models Supplement to the Certified Wireless Universal Serial Bus Specification
Revision 1.0 - Table 4-7
[9] Association Models Supplement to the Certified Wireless Universal Serial Bus Specification
Revision 1.0 - Table 4-8
[10] Association Models Supplement to the Certified Wireless Universal Serial Bus Specification
Revision 1.0 - Table 4-9
[11] Association Models Supplement to the Certified Wireless Universal Serial Bus Specification
Revision 1.0 - Table 4-10

• 0 Comments

After some google researches I concluded that doesn’t exist a python library that’s able me to manipulate some data in a JPEG Exif. I need this, cause I’m involved in a project called Syncropated [1], and this software wants to embed a thumbnail in JPEGs files. As you can see at Exif_2-1_V1.PDF, section 2.5.5 it’s possible.

But if I will code something to write this thumbnail, why do not put some code to parse data and something else?

Below you can read how the Exif works and in another post I will talk more about the pyhton Exif library that I’m coding.

A little bit about Exif format.

First we want to know if the file is a JPEG or not, so we can simple check the two first bytes of the file. If the byte[0] equal then ‘FF’ and the second one is ‘D8′ (Figure 1, ) the file can be considered a JPEG candidate. To be a JPEG, it must follow others rules shown below.
JPEG files thats have Exif must have the word `Exif` in the header. To be more specific these words are supposed to start at the 6th byte of the file, forming a sequence like the green () one that you can see at Figure 1

The 49 49 (Figure 1, ) represent the ordering of the data sequences, if its is Big-endian or Little-endian. Little endian is represented by `II` (Intel format) and Big endian is `MM` (Motorola format)

Figure 1.

Other important thing to know about Exit is the organization of the data, Exif is divided in:

• JPEG HEADER
• 0th IFD
• 0th IFD Values
• 1st IFD
• 1st IFD Values
• 1st Thumbnail – Image Data
• 0th (Primary) – Image Data

An IFD (Image File Directory) is used to store tags, with values and data types. IFDs works like a chained lists. The IF0 points to ID1 and so so…

All IFDs have the same structure, the first two bytes represent the number of tags in the directories (Figure 2 – []).
and all tags in IFD is stored in the same way:

• Tag (Bytes 0 – 1)
• Type (Bytes 2 – 3)
• Count (Bytes 4 – 7)
• Value Offset (bytes 7 – 11)

If the value can be represented in 4 bytes or smaller, it will be saved in the offset space else the offset will point the data and the “x” IFD value will be used.
The pointer to the next IFD is represented at the final of the IFD block, before the IFD values block. If you get the numbers of tags (2 first bytes) and times 12 (where 12 is the size of an IFD tag) you will get the offset to the next IFD postion (represented by 4 bytes).

I have a particular interest in the thumbnail, so as you can see in the explanation above (Exif organization), I need to have an IFD0 and IFD1 to have a thumbnail. IFD1 have two special tags, that points me to the thumbnail. The first one is the JPEGInterchangeFormat (0×0201) and the other one is the JPEGInterchangeFormatLength (0×0202).

The JPEGInterchangeFormat value is an offset to the beginning of the thumbnail and the JPEGInterchangeFormatLength contains the thumbnail size. With this two informations we are able to get any thumbnail embeded in JPEG Exif files ;P

[1] I need to talk more about Syncropated, to read more about visit: http://syncropated.garage.maemo.org

• 2 Comments