Technology in the automotive industry

Take any futuristic movies, pause on a scene where you can see a car and then think about it our cars today… Technologies in cars will become central and there is no doubt about it. But why car’s industry is left behind and don’t keep up integrating new technologies ? Sure we added features to improve the driving comfort but if you look at GPS, phones, etc are integrated in cars since a long time and things are not really evolving… Their is definitely a market for that and we have already technologies and knowledge to do so. Here is the result of a quick brain storming:

Screens: The dash board and a dedicated central console could be screens which means that they can display almost all kind of information or graphics (2D/3D).

Smartphone integration: A special spot can be designed to put your phone. This spot could be equipped with a NFC chip that will automatically request your phone to start bluetooth and connect it to the car (no user interaction required at all). The car will use your smartphone’s data plan to reach Internet (no dedicated connection required for the car, no extra cost). Voice recognition will allow the user to interact with the car and more important with the phone without touching a single button and keeping eyes on the road. Ex: text received during a drive will be first enounced (“You received a text from John”) and then the user can ask to read it (“read it” or “read john’s text” or “what is the content ?”). That’s not revolutionary but not always available in cars

Internet: You car will automatically create a wifi hotspot as soon as a smartphone with a data plan is connected to the car. All devices like kids’ tablet or wifi portable consoles will be able to use Internet. The car can also connect itself to a wifi hotspot when parked, to be more precise after powering off the engine you central screen will display for a few seconds a screen asking “Do you want to connect to wifi blaba” (Only a “connect” button is displayed). Which means that from your parking slot your car can be connected to Internet through your domestic wifi hotspot.

Multimedia: Streaming, cloud and downloading will be a new world open to your car thankfully to your smartphone data plan or wifi. Your smartphone will be an extension of your car and some features will be available only from your smartphone (like queuing a movie to download for your next trip). Why using the smartphone as a complement and why having features only accessible from the smartphone ? Because that kind of features doesn’t make sense for the driver, but it’s interesting for the passenger. So, the idea is to mask then as much as possible for the driver and put then in the passenger pocket. We can imagine a smartphone app to stream, download music to the car, cache streamed movies… And all those heavy data transfer can happen when you car is parked at home and can connect to your home wifi hotspot or a free hotspot like McDonalds, Starbucks, etc… Enhanced GPS: GPS bring us from a point A to B. But when you are traveling you probably miss interesting spots or landscapes. A trip feature can for instance display famous landscapes or touristic attractions in your way or not too far. They will be displayed as a full screen image with a few information (trip delay, price, description) and only displayed when no new GPS instructions are coming in a few seconds/minutes. A gas app will help you to find the cheapeast gas station but will help you also to know the cost of a trip (as we have the gas price and gas consumption we can know a real cost of a trip). For instance after reaching your final destination, you car can give you consumption information (like, your gas cost for the trip from A to B is $xx (x gallons).)

Hardware: The car will feature wifi, bluetooth, nfc, gps, at least 2 screens (dashboard and a central console), sensors (like in smartphones) and conventional car sensors (tire pressure, etc…). Each time you park your car the GPS position is keep in the system (so, next time you jump in the car you are ready to go without waiting on the car GPS to discover your current position). Integrating more sensor will help to improve car experience. For instance, today car increases the autoradio volume accordingly to your current speed, but this make no sense when you are off-road because car vibrations will likely create more noise than wind due to speeding (volume increase is the result of a combination of car vibrations and current speed).

App store, open API: You will be able to install new apps but they will probably need to be pre-approved by the constructor as technologies in cars are very sensitives. To be able to create apps, a SDK/API will be available. This SDK/API will offer information like current fuel tank level, current gas price, speed, car sensors, etc…** **

Script to build Android

After compiling Android all day long you quickly learn a few tricks like “mmm” to do a partial build or “adb sync” to synchronize the device files tree to your compilation output directory. Those tools save you a lot of time, but you are still typing the same list of commands all day long. And here comes my script.

Do you need to compile your Android source ?

$ dt build

Do you need to flash your device with the latest image produced by your compilation ?

 
$ dt flash

Do you need to do a fast partial build and push changed files to your device ?

 
$ dt pbuild -p

Do you need to reinstall a bunch of files and apk to your device ?

$ dt reinstall

Here are a few examples of what you can do:

Download dt

An example of Master Boot Record

Sometimes when your computer refuses to boot, or your partition table is corrupt you have a “beautiful message” on screen saying your hard drive has an issue, a MBR error. Let’s dive inside and decrypt an existing MBR in order to understand what can be found inside it.

Wikipedia, what’s a MBR ?

The master boot record is a type of boot sector very popular (for instance Windows and Grub use it). It contains 512 bytes stored at the first sector of your data storage device (HDD, USB stick).Inside this boot sector can be found:

• the bootstrapping of your operation system (described as “code area” in the table),
• an optional unique if for your data storage device (described as “disk signature” in the table)
• the partition table (described as “Table of primary partitions” in the table).

source : wikipedia

How to extract a Master Boot Record

We can simply use the command dd to copy the raw first 512 bytes of a media

$dd if=/dev/YOUR_DATA_STORAGE_DEVICE of=DESTINATION_FILE bs=512 count=1

An example of Master Boot Record

To provide a readable/hexa version of the MBR, I used an hexadecimal editor but you could use the command hexadump (to display hexa directly from your raw data storage device). And to understand what is displayed I added some sprinkles thanks photoshop =0)

Code area

In this example MBR, the code area contains shellcode and not only zeros padding. So, we can guess that this data storage device contains a bootstrap for an operating system. The goal of this tutorial isn’t to understand how a OS bootstrap works, so nothing more to add… Maybe, we can cheat and discover the string GRUB in the plain text - not a reason to be sure it’s GRUB but still a tips that confirms our supposition -

Disk signature

Yeah, an id…

Null

Too much said in the name

Table of primary partitions

Here we have four 16 bytes entries describing each primary partition. Now, you know why only 4 primary partitions can be defined for a data storage device. If we create bunch of 16 bytes, we have :

• Partition 1 : 80 01 01 00 83 FE 3F 01 3F 00 00 00 43 7D 00 00
• Partition 2 : 00 00 01 02 83 FE 3F 0D 82 7D 00 00 0C F1 02 00
• Partition 3 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
• Partition 4 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Even without knowing the meaning of those bytes we can say that there is only two partitions in the partition table described by this MBR because we have zero padding for the two last 16 bytes entries

MBR signature

It always end by 55 AA. It’s a signature, so by extracting the 512 first bytes of a data storage device you could said if it’s a MBR or something else by reading those two last bytes.

Let’s decrypt a primary partition entry

Partition 1 : 80 01 01 00 83 FE 3F 01 3F 00 00 00 43 7D 00 00

• 80 : it’s the status (80 for a bootable partition, 00 for a non bootable)
• 01 01 00 : Cylinder-head-sector address of the first absolute sector in partition (first byte is the head, 01, the second is “almost the sector” and the last one is the cylinder, 00)
• 83 : partition type in our case 83 means a native Linux file system (Ext2, Ext3 or others) - here to find each type
• FE 3F 01 : Cylinder-head-sector address of the last absolute sector in partition (same format)
• 3F 00 00 00 : Logical block addressing of first absolute sector in the partition
• 43 7D 00 00 : Number of sectors in partition (32067 sectors)

Guess what ?

We have enough information to guess about this data storage device. It contains a bootstrap (GRUB) and two partitions. The first partition is a Linux file system of 32067 sectors (- on a hard drive each sector is 512 bytes -, so 32067512/1024=16mb) and it’s a bootable partition (where the bootstrap, GRUB, will have to read). The second partition is a non bootable partition which contains a Linux file system of 192 780 sectors (192780512/1024=96mb).

The right answer is …

I don’t what to hurt you but there is a beautiful command “file”, and guess what…

$file YOUR_EXTRACTED_MBRE
x86 boot sector;
GRand Unified Bootloader, stage1 version 0x3, stage2 address 0x2000, stage2 segment 0x200;
partition 1: ID=0x83, active, starthead 1, startsector 63, 32067 sectors;
partition 2: ID=0x83, starthead 0, startsector 32130, 192780 sectors, code offset 0x48

Yes, you don’t need to decrypt all by yourself like we did to extract information from the MBR, this command print out everything for you… At least, we guess right about the content of this data storage device =0)

Compiling Linux Kernel modules for Synology devices

Synology NAS are very versatile. They are running a stripped version of Linux with less kernel modules, but we can overcome this by compiling and adding modules (for instance the usbserial module used by usb serial converters).

Requirements:

• a computer (or a virtual machine) running Linux (Debian, Fedora, Ubuntu, etc)
• the tool chains specific to your Synology
• the Synology NAS GPL source specific to your Synology

How to proceed:

• Unzip the tool chains in /usr/local

	computer$ tar -xzf yourToolChains -C /usr/local/

• Unzip the Synology NAS GPL source inside your tool chains

	computer$ tar -xzf yourNASGPLSource -C /usr/local/yourToolChains/

• Before continuing, let’s find out which Linux kernel we are running on the Synology in order to compile for the right version:

computer$ ssh -l root ipOfYourSynology
synology$ uname -a
Linux Syno youLinuxKernelVersion xxxxx yourSynologyArchi

• Open the Synology NAS GPL source folder corresponding to your Synology Linux kernel

computer$ cd /usr/local/yourToolChains/source/linux-youLinuxKernelVersion

• Copy the config file created by Synology to configure the kernel

computer$ cp synoconfigs/yourSynologyArchi .config

• Edit the Makefile to compile for the right architecture and use the right tool chains

computer$ vi Makefile
edit the variable ARCH -> ARCH = yourSynologyAchi
edit the variable CROSS_COMPILE -> CROSS_COMPILE = /usr/local/yourToolChains/bin/yourToolChains-

• Check the config file we just copied

computer$ make oldconfig

• Edit the config file through the user interface to add modules

computer$ make menuconfig

• Compile all modules

computer$ make modules 
# or only a specific module: make M=./drivers/usb/serial

• Find your modules in the corresponding subfolder (in my case drivers/usb/serial/usbserial.ko)

Buffer overflow tutorial

I discovered recently a great video tutorial about buffer overflow. It’s splitted in 5 videos well illustrated and explained. After watching, you will know how to exploit buffer overflow, and giving you ideas about how to avoid them in your code.

• Buffer Overflow Primer Part 1 (Smashing The Stack)
• Buffer Overflow Primer Part 2 (Writing Exit Shellcode)
• Buffer Overflow Primer Part 3 (Executing Shellcode)
• Buffer Overflow Primer Part 4 (Disassembling Execve)
• Buffer Overflow Primer Part 5 (Shellcode For Execve)