Analyzing the Fiat Blue&Me iPhone Adapter

I recently got a new car, a Fiat Punto to be more precise. The car has a lot of gadgets inside, like the cruise control, USB, bluetooth for the cellphone, etc. It also has the an infotainment system called "Blue&Me", which is pretty well done, with a not too bad voice control system. Well, I have a USB connector, so I'd like to attach my iPhone in order to listen to my playlist. Sadly, the Blue&Me system is not able to read the iPod/iPhone directly, we need to buy a tiny device:



This small piece of hardware is charged around 140$ in the Fiat store. It bugs me: why the hell is it so expensive ? Is there any custom hardware inside or what ?

Let's open it and see what's inside:

• TOP view:
  

• BOTTOM view:
  

1. STM32F101C8T6: The STM32F101xx access line family incorporates the high-performance ARM Cortex-M3 32-bit RISC core operating at a 36 MHz frequency, high-speed embedded memories (Flash memory up to 128Kbytes and SRAM up to 16 Kbytes), and an extensive range of enhanced peripherals and I/Os connected to two APB buses. All devices offer standard communication interfaces (two I2Cs, two SPIs, and up to three USARTs), one 12-bit ADC and three general purpose 16-bit timers.
   
   Price for a single chip: ~5$
   
   
2. SMSC USB2512I: The SMSC 2-Port Hub is low power, OEM configurable STT hub controller IC with 2 downstream ports for embedded USB solutions.
   
   Price for a single chip: ~5$
   
   
3. PL-2303MX: USB to Serial Bridge Controller.
   
   Price for a single chip: ~7$
   
   
4. There is a small chip I wasn't able to identify.
   

There are other passive electronic components, like voltage rectifiers, etc. If you have access to a lab where you can print your own PCB, the overall cost of this tiny adapter is ~20$.

If you look carefully at how the adapter is designed, you might find that the chips are not placed at right location. The USB2512I(USB Host) chip is close to the male connector whereas the UART (slave) chip is close to the female USB connector. This does not really correspond to how it should work, since the iPhone [slave] must be connected to a host [aka female input] and the adapter must behave as a slave [aka male output] with respect to the car.



As you can see, there is a 10Pin connector, probably a JTAG (according to the ARM datasheet). I am surprised they let the pins, now I just want to test what's going on in the chips. However, we don't need all this information. Another approach is to check what are the signals coming in and out from this device: how does the iPhone communicate with the car and vice-versa, how does the car communicate with the iPhone ? For this, we must be able to sniff the USB connexion. How ? You might use an expensive USB sniffer, or there might be another better [aka cheaper] option: dumping the content right after the PL-2303 and right before the USB2512i, because we will have a serial signal :).

Dumping out the content of the Arduino

I'm very impressed by how easy it is to make a small program on the arduino, the community did a great job. Also, I think it's a very easy introduction to embedded systems, because you don't have to worry about the low-level aspect of embedded systems in general.
Recently, I had to analyze a "black-box". By black-box I mean a box that you don't know anything about. In my case, it was a 3k$ video component, with a FPGA (Cyclone II) and an atmel (Atmega168). I got it for a little moment, I also had an AVR programmer but I did not know how I could dump out the content of the atmega chip.

It turns out that in Windows, you can just install AVR Studio and from there you will have a nice GUI with all the options to maybe retrieve the content from the memory. This programs does a great job, but what about Linux ?

Well, avrdude is your friend in the Linux world. I wanted to dump the content of the memory, so an idea might be to use it this way:

~/arduino-0017/hardware/tools/avrdude \
-C~/arduino-0017/hardware/tools/avrdude.conf -v -v -v -v \
-pm328p -cstk500v2 -P/dev/ttyUSB1 -D  -Uflash:r:/tmp/kikou.hex:i

And ohh... magic, all the content is dumped on the file /tmp/kikou.hex.

Well, this is an intel hex dump, so not really readable:

:200240008093A30181E0809370011092A001089580919E0190919F012
:2002600081E0809399011092A00110927101109270010895809198018
:200280009801109299010895EF92FF92CF93DF93FB012091700122231
:2002A000710123503081231708F420834081C3E7D1E0BE0150E00E941
:2002C00071012FEF3FEF219713C099912927022E2295207F2025032E3
:2002E000269532272327220F220F220F20258150882359F790EF283B8
:20030000CF91FF90EF9008958091550160919A010E945F03809110016
:20032000910181E08093980108951F920F920FB60F9211242F933F934
[...]

I tried to dump it as "raw output", but you will get an hexdump. "Ce n'est pas folichon" I'd like to say. From the hexdump, one cool thing would be a disassembler, but apparently, nobody has done one on Linux. If you know a way to read hexfiles (avr-objdump won't work here), drop me a message!
Another solution is to use the AVR Studio program in Windows, apparently it does the job, but I haven't tried yet.

We'll probably come back on that very soon 8).

My first steps with the Arduino

I recently received the arduino I ordered on Makershed. Actually, I took a starter kit to play with this small piece of hardware. The board has an ATMEGA328 uproc (8-bit) with few I/Os to play with.

They offer a nice tiny sdk to write your code/compile and upload. I've nothing to say, it's working great, they did a good job, however, since I am an emacs aficionados (and I'm not a Java fan), I wanted do the process manually.

The first was to analyze a bit was was given in the arduino (software) package. The file being in arduino-0017/hardware/cores/arduino/Makefile gives you the makefile to compile your programs. We can already notice that it does not work out of the box and that you've to modify it.

Here are my modifications:

INSTALL_DIR = $(HOME)/arduino-0017
PORT = /dev/ttyUSB0
UPLOAD_RATE = 57600

AVR_TOOLS_PATH = /usr/bin
SRC = $(ARDUINO)/pins_arduino.c $(ARDUINO)/wiring.c \
$(ARDUINO)/wiring_analog.c $(ARDUINO)/wiring_digital.c \
$(ARDUINO)/wiring_pulse.c \

AVRDUDE_FLAGS = -V -F -C $(INSTALL_DIR)/hardware/tools/avrdude.conf \

Well, you notice that one file somehow disappeared in SRC. I simply removed it and it seems to be working. Also, the AVR_TOOLS_PATH was pointing on a wrong directory.

Now, for compiling your stuff, a simple make must be enough.

The next step was the upload that was a big deal for me. Actually, it was working with the Java interface, but not with avrdude. Actually, I was using the following command, because I saw it somewhere:

avrdude -V -F -C ~/arduino-0017/hardware/tools/avrdude.conf -p m328p -P /dev/ttyUSB0 -c stk500 -b 19200 -U flash:w:applet/Fading.hex -vvvvvv

Well, I got the following message:

avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding

So WTF (Huh, btw, I entered twice avrdude avrdude [...], it segfaults after trying one :)) ? How so it's working with the Java App, but not with the avrdude ? As a wise guy said once "one week of trial and error can save up to half an hour of reading documentation", well, actually I could have read the Arduino troubleshooting section, but...

My idea was to sniff the what's going on /dev/ttyUSB0 when using the Java IDE and compare it with the avrdude command. To sniff it, I found jpnevulator as being usefull.

When running it, ./jpnevulator --read --tty /dev/ttyUSB0, turned out that I was getting the "programmer is not responding" error message even in the Java IDE :), this meant that the Java IDE was calling avrdude somehow (since this is an avrdude error message).

Cool, I downloaded the Java files from their svn and started to grep on these. In arduino/app/src/processing/app/debug/Uploader.java I found something interesting:

      if (verbose || Preferences.getBoolean("upload.verbose")) {
        for(int i = 0; i < commandArray.length; i++) {
          System.out.print(commandArray[i] + " ");
        }
        System.out.println();
      }

So, since I did not want to recompile all the files (lazy ?), I just wanted to set this boolean upload.verbose to true. Turns out that the preferences are read from a file ~/.arduino/preferences.txt, so you just have to add "upload.verbose=true" somewhere in there.

Now we run the Java program again and we the nice working avrdude command. We can use it directly after resetting the device (by pushing the button or directly sending a reset signal).

The command it now:

/usr/bin/avrdude -V -F -C ~/arduino-0017/hardware/tools/avrdude.conf -p atmega168 -P /dev/ttyUSB0 -c stk500v1 -b 57600 -U flash:w:applet/Fading.hex

Basically, the speed was wrong. Again, don't forget to push the reset button before shipping the code on the board

Finding the number of parameters directly in the assembly

Recently, when working on my library tracer, I wanted to know the number of parameters a function uses. I did not have any access to source code or debug info, so I had to find another way to get this information. Programs like ltrace/strace have an extra file, usually located in /etc/ to define the prototype of certain functions. When ltrace does not know a specific function prototype, it simply sets the number of parameters to 5 by default. However, by doing a simple analysis of the assembly code we can infer the number of parameters with a pretty high success rate. In my study I assumed we are using a x86_64 Linux box that binaries have not been obfuscated.

We will focus on regular registers, but the theory applies for FPU registers too. By convention, on x86_64, GCC will use the registers to pass the arguments (before using the stack), in the following order: %di - %si - %dx - %cx - %r8 and %r9. Thus, without loss of generality, up to 6 parameters can be passed through registers (before using the stack), with some exceptions for bigger data structures.

We define a block as being the set of instructions between two instructions changing the control flow (e.g.: ret / call / j). First, we localize this instructions in the disassembled program. From there, we move backward to retrieve the different parameters.

Let's do it on a example. The following snippet of code defines 4 blocks:

402406:       84 c0                   test   %al,%al
402408:       0f 84 62 ff ff ff       je     402370
----------------------------------------------------------
40240e:       40 84 ff                test   %dil,%dil
402411:       74 e0                   je     4023f3
----------------------------------------------------------
402413:       83 3d e2 5e 21 00 03    cmpl   $0x3,0x215ee2(%rip)
40241a:       75 d7                   jne    4023f3
----------------------------------------------------------
40248c:       48 8b 2d 35 69 21 00    mov    0x216935(%rip),%rbp
402493:       ba 05 00 00 00          mov    $0x5,%edx
402498:       be 88 0b 41 00          mov    $0x410b88,%esi
40249d:       31 ff                   xor    %edi,%edi
40249f:       e8 24 fb ff ff          callq  401fc8

If we take the last block, and we perform a backward analysis, we figure out that the registers %di, %si, %dx (and %bp) are modified. According to the _cdecl_ calling convention, it is likely that the function will take 3 arguments before jumping into the plt trampoline.

Sadly, this is not always as clear as in the previous example. For instance, we can see that the others block does not follow this nice rule, but can we deduce the function are not expecting any parameter ? As it was previously stated, it is very rare that a function in called only once. Although, the main purpose of a function is exactly the opposite, ie being called as often as possible from various parts of the program. Thus, by applying the previous criterion over all functions, we can deduce a heuristics that will retrieve the number of arguments with a good success rate.

Every time we encounter a function call, we save the set of registers of the block. A map looks like the following: (%di. %si. %dx. %cx, %r8, %r9). Every element is a boolean and says whether the register was used or not.

Let's take the same function as before, dcgettext(..) from /bin/ls. The function is called around 15 times in the overall program, but all the registers cannot be retrieved every time.

(0, 0, 1, 1, 0, 0)
(0, 0, 1, 0, 0, 0)
(0, 1, 1, 0, 0, 0)
(1, 0, 1, 0, 0, 0)
(1, 1, 1, 0, 0, 0)
[...]

Typically, (0, 0, 1, 1, 0, 0) means that only registers %dx and %cx were used. Thus, we take the set that has been used the most frequently. Let's assume the set appearing the most often is: (0, 0, 1, 0, 0, 0). This would mean that only register %dx is used. However, we do have a discrepancy compared to the official _cdecl_, because the first parameter must be sent through the %di register.

A good practice is to set to 1 all the registers that are on the left of the top-right register in the map. Thus, (0, 0, 1, 0, 0, 0) will become (1, 1, 1, 0, 0, 0). This means that register %di and %si are also used. To make sure our theory is correct, we can check in the man pages that the prototype is correct:

char * dcgettext (const char * domainname, const char * msgid, int category);

For the function having an associated man page, this technique has been shown to be very effective, by retrieving correctly the number of registers 90% of the time. When the mean gives us a guessable output, we will always choose the value that have more registers set, in order not to miss any of them. Note that this technique is very light, since it does not require to go into the called function to analyze the parameters in there.

To implement this, I chose Perl for a simple reason: I get the binary output from objdump and then I can parse into it pretty easily with simple regex. Using this kind of techniques we can also infer the type of the parameters, but this is another story 8).

Using Stumbleupon to spread virii ?

Chances are that you discovered my website by "stumbling upon". I like this way of spending time, by fucking around over the Internet. You just click and you get a new webpage that fits sometimes what you like.


However, it might be a great way to spread virii also. Assume that you stumble a virus you intentionally added on a box you own. Then people will come on this website and their browser will ask for downloading this file. When you know that the lambda user will always click on "OK", you might infect him with a high percentage rate. This idea worth trying...

Abuse the load time of a Web page, for DoS & profit

In my university, we have different canteens (this is how it's called) where you can eat for lunch. Each canteen puts its food on a common website.

You also have the possibility to see what was yesterday's lunch, but also tomorrow's one. Basically, if you request tomorrow's offer, the URL will look like

http://X?ref=1

If you want yesterday's URL, you will type

http://X?ref=-1

And obviously, if you want to have the menu that was available 2 days ago, you just have to type

http://X?ref=-2

Of course, the idea is to input a big number here and see what happens. Usually, big numbers are escaped. Let's have a try...

http://X?ref=-20000

This gives us the offers of the Wednesday, Jan 19 1955. Of course, the entry is empty, but it's fun to come back that much. Now we add one more '0'

http://X?ref=-200000

The date now is Jan 1st 1970. This date should talk to you (doesn't it ?). Do we have an overflow somewhere in there ? Clearly, there is a validation input issue. I also quickly tested other escape patterns, they did not work.

However, we can measure the load time of the page to see if our input modifies it. To do it, I will use this small script that will only count the load time

for i in $(seq 1 8000000 2000000000)
do
  curl -s -w "%{time_total}\n" -o /dev/null http://X.php?ref=-$i >> /tmp/result.txt
done

Then, we can plot the result of the previous command.

I admit I wasn't expecting such an increase. The script probably has an internal loop and iterates over the argument we provide. If we decrease the granularity by increasing the increment, but also the limit, this rule is confirmed as you can see on the next plot.



This time, we start seeing some discrepancies, but the overall picture is still linear. Since we get such a nice graph, why not trying with HUGE values ?

curl -s -w "%{time_total}\n" -o /dev/null http://X?ref=-200000000000
30.084

The last request took 30s to be computed. So what's next ? If it takes 30 seconds for 1 request, what will happen for 4000 requests ?

for i in {1..4000}
do
  curl -s -w "%{time_total}\n" -o /dev/null http://X?ref=-200000000000 > /dev/null &
done

You will notice that a '&' was added at the end of the command, in order it to fork. It will probably dramatically slow down your computer, but you will eventually crash the remote machine.

Actually, the load time trick has already been used in the past. Typically, you could use this to query a database: depending on the time it takes to answer, you'll be able to deduce whether the login/pass was in the database or not (sort of "side channel attack").

Well, once you can identify this kind of behavior (change in the processing time upon request), it becomes just a matter of requests for the machine to become out of ressources. Here, the server is misconfigured: one should not allow so many request from a client in such a small time, especially when they increase the resource consumption, and one should also check the input validation more carefully.

Defeat google's canned response

There is a great application in gmail lab, called "canned responses". Basically, it replies on your behalf, when your email matches the filter you set up.
This is great for example if you go on vacation and you want to auto-reply a particular message. However, gmail is following "too well" the standard.

In my case, I was really disturbed by the emails I was receiving from my school associations. You know, they are the kind of emails you absolutely don't care about.

So what's the problem ?

The problem is this emails are sent through lists. Usually, there is a moderator deciding whether or not forwarding the email. In my case, I couldn't unsubscribe from the list and I was receiving like 3-5 emails/day.
When using the gmail canned responses, it replied to the "list-bounce" (ie following theReturn-Path in the email header and then, the sender did not receive my email back. That was a pitty.
The idea was then to:

1. Effectively reply to the sender, not to the bouncer.
   
2. Also send an email to the list moderator to show my displeasure.

Sounds like a perl script would be very easy to write. I created a new gmail account and I enabled the POP (Settings->Forwarding and POP/IMAP). On my main email address, I forwarded the email matching a certain pattern to this new mailbox.
To respond to the sender, I was using the mailx command, for simplicity.


Perl is new for me, so my coding style is crappy, I know. Of course, feel free to criticize it if you feel the need.

#!/usr/bin/perl -w
my $user = 'bobo@gmail.com';
my $pass = 'papassword';
my $home = '/home/blabla/automailer';

my $pop = new Mail::POP3Client(
   USER     => $user,
   PASSWORD => $pass,
   HOST     => "pop.gmail.com",
   PORT     => 995,
   USESSL   => 'true',
);

my $count = $pop->Count();
for my $i (1 .. $count) {
my $name = "";
my $email = "";
my $subj = "";
foreach ($pop->Head($i)) {
   $name = $1 if /^(?:From):(.+)<(.+)>/i;
   $email = $1 if /^(?:From):(?:.+)<(.+)>/i;
   $subj = $1 if /^(?:Subject):(.+)/i;
}

# We remove the spaces at beginning/end
s/^\s+// for $subj;
s/\s+$// for $subj;
s/^\s+// for $email;
s/\s+$// for $email;
s/^\s+// for $name;
s/\s+$// for $name;

# We save the history
open FILE, "< $home/contact.txt" or die;     my @array = ;
close FILE or die;
my $found = 0;
my $number = 0;
for my $i (0..$#array) {
   if ($array[$i] =~ /$email\s+(\d+)/) {
       $number = $1;
       $number++;
       $array[$i] =~ s/$1/$number/;
       $found = 1;
       # print FILE;
   }
}
if ($found == 0) {
   push(@array, "$email 1\n");
   $number = 1;
}
open FILE, "> $home/contact.txt" or die;
print FILE @array;
close FILE or die;

my $msg;
$msg .= "Hi $name,\n\n";
$msg .= "I'm an auto replier.\n";
$msg .= "Thanks a lot for your email \"".$subj."\", but I am absolutely not interested. Next time,
please remove my address from your contact list.\n";
$msg .= "Since apparently you already sent me ".$number." times an email, I am going to do the same
x6. Thus, I'm sending you back ".($number * 6)." emails.\n" if ($number > 1);
$msg .= "\n";
$msg .= "Thanks,\n";
$msg .= "\n";
$msg .= "Blabla.";
$msg .= "\n";
# print $msg;
open FILE, "> $home/msg.txt" or die;
print FILE $msg;
close FILE or die;

for (my $i = 0; $i < $number; $i++) {                
 `mailx $email -s \"Not interested: $subj $i\" < $home/msg.txt`;   
 `mailx crappylist\@vovo.com -s \"Not interested: $subj $i\" < $home/msg.txt`;         }     

 $pop->Delete($i);
}
$pop->Close();

So what do we do ?

• We first connect to the server and retrieve every email.
• For each email, we take the sender's name, email address and the subject.
• We build the message with the previously collected data.
• We send the message and update the history. An entry in the history is email - times. First time we are polite, then we send 6x the number of emails the sender sent to us.
• We send the email using mailx (easy way...).
• We delete the message on the server, in order not to reprocess it.

There we have a very effective auto-replier that will spam back the sender (and the list btw). You can put this Perl script in you crontab, of run a small bash script in a screen that will execute it every 10 minutes for instance.

The end of the story ?

The administrator contacted me, because I was improperly using the computer resources of my school and I had to shut off my script :(...