Xipiter
  • Home
  • Training
    • Practical ARM Exploitation
    • Software Exploitation Via Hardware Exploitation
    • Practical Android Exploitation
    • Training Testimonials
    • 2018 Public Training Info
    • 2017 Public Training Info
    • 2016 EU Public Training Info
    • 2015 EU Public Training Info
  • Research
  • Products
    • Int3.cc
    • SyncStop / USB Condom
    • Tally / Osprey
  • Blog
  • Contact
  • About

Using the Shikra to Attack Embedded Systems: Getting Started

12/26/2014

 

Why "the Shikra"?

Since we've started teaching SexViaHex, many people (not just our students) have asked me (Joe Fitzpatrick) for equipment recommendations for doing their own hardware hacking. I own and use several tools with duplicate and overlapping purposes, since there's usually a 'best' tool for any given job. In the process of assembling the equipment and content forSexViaHex, I had a hard time whittling it down. The first answer to 'what should I buy first?' is and will likely continue to be the BusPirate (with a Saleae in close second). No single tool speaks so many protocols, and only a handful of tools provide lots of the diagnostic and passive sniffing features of the BusPirate. 
Picture
Purchase a Shikra here at INT3.CC
Once you've identified all your pin-outs, protocols, data rates, and device addresses, It's usually best to move on to more robust single-purpose tools. (Techniques and tricks for doing this we focus on quite a bit in our SexViaHex course.). We had a hard time choosing which tools to include in the class since there are so many choices and limited time in our class, and limited space in our Student Kits. 
Picture
FTDI's FT232H chip is the more powerful older brother to FT232R USB to UART adapter. The "-H" model of chips are widely used in JTAG adapters but also support several different serial protocols, plus the ability to bit-bang custom ones. The Shikra is Xipiter's nice, dead-simple FT232H device that allows you to use all these different modes. (FYI: Keeping with the "accipiter" theme at Xipiter, Shikra was also named after a bird of prey.) 

So what practical things can you do with it? Here's a few things I've done with it so far. 

The shikra for uart:

The bus pirate has several UART features like passive sniffing, baud detection, and a transparent passthrough mode. It should let you do most of what you need to over UART. Usually once i've figured out my pinout and baud rate, i switch to a simple USB TTL Serial cable to free up my bus pirate for better things. On the access-point/router shown below, UBOOT runs at 120kbps while the kernel (which loads after) boots at slower 115.2. The bus pirate tends to be very picky and fails if the baud rate is only slightly off, while a dedicated cable usually has a wider tolerance and can read both with no settings change. The Shikra had no problem with this.
Picture
The Shikra case.
"So hold on a second" (you might be thinking) "First things first! How to we wire this Shikra up to stuff?"
It's really simple, the Shikra much like the BusPirate just has headers which you can use to jumper to your target. The pinouts of the Shikra are viewable in the documentation for it. 

Picture
Pinouts for the Shikra (the "back" is mirrored)
According to the diagram to the above,  UART, the Shikra's pinouts are as follows:

TX: 1
RX: 2
GND: 18
Once wired up, the following command (from a *nix) machine will connect you through the Shikra to whatever you're targeting:

$ screen /dev/ttyUSB0 115200

Protip: I never worry about getting TX and RX right, since somewhere along the way they get mixed up, and it's usually easier to swap them once to get things to work than it is to make sure they're right in the first place.
Picture
The Shikra acting as UART adapter to attack a router/access point.

The Shikra for JTAG:

Picture
The Shikra in a 3D printed version of its case .
JTAG adapters run $10 to $20,000 - but in the end they're all speaking the same protocol. For SexViaHex, we needed to use JTAG at the same time as UART so we knew we needed a second device. We tried using EZ-USB FX2 boards, but had trouble reliably sourcing them. The first time we taught the class, we used the Bus Pirate since it is well supported by OpenOCD - however it's incredibly slow, and required frequent reconnecting for hardware reset.
We needed something different so we switched to a different FT232H-based board that worked well, but has had a very high failure rate (they'd burn up easily or stop working inexplicably).  We needed something more reliable. So after all that we decided to design something and the Shikra eventually replaced these tools.  The Shikra was equally as easy to get wired up for JTAG and use with OpenOCD:

Shikra JTAG Pinout:
TCK: 1
TDI: 2
TDO: 3
TMS: 4
GND: 18

OpenOCD Config File for the Shikra:
#shikra.cfg
interface ftdi
ftdi_vid_pid 0x0403 0x6014

ftdi_layout_init 0x0c08 0x0f1b
adapter_khz 2000
#end shikra.cfg

Picture
The Shikra as a JTAG adapter to attack a router/access point.
I've also been looking for a reliable JTAG adapter for FPGA configuration for the WTFPGA workshop I've been doing at some conferences. Thanks to some open source developers, there's an alternative to the pricey Xilinx Platform Cables that works with the native configuration tool. I followed the same process that Colin O'Flynn did for the older FT2232D:

The Shikra for SPI:

Embedded devices can add a few bytes to a few megabytes of storage for under a dollar with a tiny 8-pin SPI flash chip. There are also SPI network adapters, A/D converters, and all sorts of other devices, but the firmware on SPI flash chips is usually what's most interesting.(For more interesting devices that SPI can be found in, see the Xipiter talk "Hardware Hacking for Software People").  
Where the BusPirate took ~30 minutes to extract a 4MB firmware image from a device, the Shikra took less than a minute!
Picture
A DediProg SF-100 Flash Programmer in the Xipiter lab.
One exercise we have in SexViaHex is to pull off the full firmware image from an embedded device. We use a clip like a Pomona 5250to directly contact the 8-pin SOIC chip's pins without having to desolder, and then we use the bus pirate and Flashrom to 'quickly' dump a 4MB firmware in 20 minutes - if it works the first time. Specialized devices like a Dediprog SF100 (pictured to the left) would be much quicker, but are a bit to large and expensive for us to buy 30 to put into our student kits for SexViaHex. Luckily Shikra supports SPI, and flashrom supports a generic FT2232 interface, allowing firmware dumps in less than a minute.
Shikra SPI Pinout:
SCK -1
SDI - 2
SDO -3
*CS - 4
GND - 18

To dump an SPI flash with the Shikra we simply:
$ flashrom -p ft2232_spi:type=232H -r spidump.bin
Picture
The Shikra "un-bricking" a tablet by overwriting firmware via SPI using a 8-pin SOIC clip. The SOIC clip made this "unobtrusive" not requiring the chip to be desoldered!
Of course, Shikra is not just for work. I recently got a Teclast Air II tablet (same panel as an ipad retina, but with an intel bay trail SOC and andriod/win8). I wanted to update it to a dual-boot bios, but accidentally bricked it because i flashed a bios file for the older Teclast Air 3G. Luckily i was able to resurrect it by using the Shikra + Pomona SOIC + Flashrom to directly flash the chip when it wouldn't boot otherwise.

In summary, I was pretty excited to get my hands on Shikra, and I'm looking forward to showing participants in our future SexViaHex classes how to use it to reverse engineer and hack up hardware devices!


You can purchase a shikra here!


shikra_documentation.pdf
File Size: 462 kb
File Type: pdf
Download File

Download a pdf of the shikra pinouts to the left!

The Insecurity of Things: Part Two

10/23/2014

7 Comments

 
When we last left off, we were setting the stage for sharing what the Interns found in a handful of "IOT" or internet connected devices they purchased. So we'll be starting with a simple one. One that only required simple techniques to compromise it. This first device is a "Smart"-Home Controller. For a bit of background on what's going on here, please see "Part One" of this series otherwise we're going to jump right in but first a disclaimer:

disclaimer:

The following information is released FOR ACADEMIC RESEARCH PURPOSES ONLY. Xipiter staff did not at any time access the external or supportive infrastructure of any of the products mentioned herein. Furthermore, as a information security firm, Xipiter does not condone or encourage the use of the following material for the purpose of attacking or exploiting the devices of others. The purpose of this blog series is to raise awareness about the security risk posed by this new class of "IOT" or "Internet Of Things" devices.

Su    casa   es   mi    casa

Picture
This first device is billed as the "most flexible, powerful and affordable home controller on the market today. No monthly fees!" Neat. 
Now let's see how secure it is.
The product descriptions and marketing material surrounding it also give us as "security researchers" a glimpse at the capabilities of the devices and to estimate attack surface:  Lots of connectivity.

the setup and the Teardown

Picture
Now that we have a general idea of attack surface, let's set it up the way a normal user would.  And in the process get more information by opening it up and seeing what we can see.

The marketing material was right, setup was very simple. It consisted of you just plugging the device into your local internet router via Ethernet. You then went to a predefined web page (out on the internet) and entered the MAC Address and Serial Number of your device. But before we do this, we'll want to see what it does.
So now that we know this thing is going to be talking to the internet for first configuration, the first thing was to intercept all of it's communication with the outside world. Ben, set up a router on his Raspberry Pi to do this so that all traffic could be intercepted and watched in real time. The RaspberryPis are ideal for this kinda stuff because they are cheap enough to buy a handful of, they run Linux, they support've got built in support for a handful of USB Ethernet and Wifi Adapters, and they can be packed away [as is] for easy reuse on other projects without rebuilding. Other tools like WiFi Pineapple are slow and frankly too "abstracted".) 
RaspberryPi Router.
Tearing down the device
Wiresharking the pcaps
Keep a handful of RaspberryPis around.
Ben at work in the lab.
Our target.
Picture
The Raspberry Pis had a few useful tools installed on them: 
  • MITMProxy 
  • tcpdump
  • SSLStrip
The SSL tools are just-in-case the device decides to try to "call home" to it's servers over SSL. If it is poorly implemented it would allow us Man In The Middle his connection and peek at what he's doing (more on this later as it is a recurring theme in many of these devices).
Ben stepped through all the configuration steps as the device specified, but noticed something (by watching the network traffic intercepts).

In Step 4 of the configuration manual, it instructs you to connect to the manufacturer's website and enter the serial number and MAC address that is printed on underside label of the device. This presumably is to "pair" your user account with the hardware you purchased.  Ben noticed from the pcaps (from tcpdump) that immediately after entering this information, his web-browser was redirected to the local IP address of the device. It looked as though he was connected to the manufacturer's website, but there was an IFRAME actually pointing him at the device within the lab network. So the device is running a webserver.

"Secure mode"

Ben also noticed that the device could run in "Secure Mode" which (after a little digging) Ben discovered disabled all the daemons (like the web server) running on the device's "network facing" IP. 
Unauthenticated Firmware Upload/Download page.
"Secure Mode"
Instead, when in "Secure Mode" the device spawned all of the daemons on 127.0.0.1 and SSH port forwarded them from the device through the manufacturers servers out on the internet.  This would allow you to access the device INSIDE your home network from out on the internet. (More on this "Secure Mode" later, because it is ironically the very feature that makes these devices open to potential remote attack.)
Ok so now that the device is set up and on the network, the interns opened the physical hardware it to see what they could see. As standard a procedure at Xipiter, everything is photographed through the lab scope right when it's opened so that serial numbers and model numbers can be recorded to download specification sheets (and so you don't have to remember to do it later for report writing). In the end, it'll turn out that none of the specification sheets were needed to compromise the device.
Ben and the Lab Scope
The guts of the device.
DRAM
NIce! maybe we use our www.rfcat.com ;-)
Ethernet controller
UART...rootshell!?
The first glaringly obvious thing is that the device is running an RALink core which we know from experience is a common MIPS based System On Chip popular with OpenWRT (We'll be validated shortly when we see in fact what it is running.)

In subsequent blogposts (in this series) and in our "Software Exploitation Via Hardware Exploitation" course we have to deal with using diagnostic tools and techniques to reach buried pins or discover which pins are responsible for what. But here, not only does thePCB Silkscreen clearly call out the pins but there are also headers soldered on. Clearly this manufacturer didn't iterate on the hardware design. These are all indications that the "development" and "release" revisions are the same hardware. 
For this device,  we just simply handed the interns a UART USB cable plucked from one of the SexViaHex Student kits . (No Shikra needed for this one). With a little quick help from one of the Appendices of the SexViaHex Lab Manual (for the pinouts of the UART cable) the interns were connected to the device using screen (yea, it can do serial too ;-).
Connected..
Connecting UART
Connecting UART
Rootshell!
Rootshell!
Ben at work
Picture
It took a few guesses at baud rate but  just like that, the interns had a rootshell over UART. (We have an entire unit in SexViaHex about how you calculate baud rates using a Logic Analyzer to gain interactive control of a device. We'll also demonstrate this technique on two other devices in subsequent "The Insecurity Of Things" posts). 

now the we got a rootshell, let's find a remote vulnerability

The next step was to take a look around the filesystem...our goal is to find remotes so we want to find out what daemons are currently listening and which may be spawned by the system. 
Picture
After searching through the filesystem a bit for other references to the daemons in that process listing, it was determined that there was a light http daemon is used for service and setting files on the filesystem. 
Picture
The immediate next progression is to read the embedded HTTP config which revealed that this device has http configs that forward incoming requests to specific "endpoints" or web paths....So of course, some basic directory traversal stuff was tried. And eventually the interns landed on this:
Picture
So this is great. We are getting closer, we can get the password file unauthed remotely. BUT, one other thing to note is that the filesystem of the actual device is immutable including /etc/passwd (because it is distributed in the device as Mask ROM). To get around this and fake "mutable" parts of the filesystem, this manufacturer uses Non-volatile FLASH storage to basically store everything so that it can persist after reboot. 
Picture
This is a common technique used by hardware vendors. So to "fake" a mutable filesystem they have a custom binary on the filesystem called "nvget" that fetches from NVRAM using a "key/value" scheme. Here is an example of it in use in their boot scripts.
They even use it to retrieve the root passwords stored in NVRAM ;-)
Picture
Ok, so let's review what we have so far:
  • The device is using dropbear ssh daemon
  • The device is using lighthttp with custom configs to serve files from the filesystem. There is an unauth'd directory traversal vuln here.
  • We can fetch configuration values from NVRAM via the root console.
  • The device has embedded SSH private keys on THE IMMUTABLE sections of the firmware image so we know that all these devices have the same embedded ssh key. It uses that key to access the manufacturers backend and set up ssh port forwards.
So at this point we need a tool to capture all of the "exploits" for these vulnerabilities.

So now we need an "exploitation" tool: 
id-iot-ic

So we now there is a need for a place to keep and release all vulnerabilities for these "Insecurity Of Things" posts. A place to keep them all bundled with easy access.....So we wrote a simple "modular" tool called idIOTic. 
with this tool, 0wning your own device is "point and click" simple. And we'll just keep adding exploit modules as we go.
It has full interactivity and "point and click" simplicity to exploit the simple (and not so simple) vulnerabilities in the devices we'll be discussing in this blog series. It is modular (uses some simple python interpreter "monkey patching" to make it so new commands/functionality can be added by just dropping files in to the "modules directory"). 

animated   gif   of   idiotic   0wning   the   device

idIOTic 0wning the device.
Animated Gif of idIOTic 0wning the device.
idIOTic interactive help and IOS style subcommand menus.
idIOTic interactive commands to 0wn this device several different ways.

Conclusions

Picture
With some really dead-simple techniques this device was easily compromised. Furthermore not only can you attack your own device, but an attacker could (without purchasing a device) potentially just download the firmware image from the manufacturer (as linked from the manufacturer's wiki), extract the filesystem image using binwalk and unsquashfs, and navigate to the right directories on the filesystem to retrieve the ssh private keys used to access the manufacturers backend.
From there potentially (if SSH works the way we think it does),  this key can be used to access ALL THE OTHER devices like it in the world currently connected to the internet. It should be noted that as the interns discovered these vulnerabilities in this device, they found "prior art" vulnerabilities found by D. Crowley (then of Trustwave Spider Labs) although there was no explicit mention of the ability to potentially access all the other devices via the manufacturer's servers (via the hardcoded SSH keys).

While this a simple little device, the ability to attack it on the local network and potentially reach it THROUGH the manufacturers own servers as a beachhead to other computers on your home network is a reminder of why devices like this need to be understood better. 


 this extracted SSH key can potentially be used to access ALL THE OTHER devices like it in the world currently connected to the internet, through the manufacturer's backend no less.

Our next targets :

This device was a very simple example, it didn't even require any of the fun stuff like "binary exploitation" to completely compromise the device and others like it. 

In the subsequent blogposts we'll go deeper and share more techniques from our SexViaHex class: 
  • What if you cant easily access UART? 
  • What if the firmware updates are signed or not easily downloadable?
  • How can we use JTAG to pull firmware and analyze the firmware for vulns? 
  • What if the embedded "webserver" is just some compiled C app servicing HTTP requests?
  • What if there isn't a "full operating system" but just a RTOS?

We'll discuss all of this in more depth as we catalog what the interns found in a NAS, Access Point, and a Smart Thermostat (in the next post). With each post we'll also include PoC "exploit" modules for idIOTic.
7 Comments

The Insecurity of Things : Part One

10/8/2014

2 Comments

 
Everyday we read about some newfangled internet connected device being released. Things we use everyday are being made "smart" with some rushed-to-production software embedded in a cheap micro-controller. Fitness trackers, smoke alarms, televisions, cars, wall-outlets, even water-bottles. Internet connected-water bottles? What a time to be alive!

Some think this "Internet of Things" (IOT) and embedded system explosion is driven by gadget hungry consumers. Perhaps it is, but most of this absurdity is side-effect of us technologically transitioning from a world built around ASICs  to a world powered by cheap general purpose  SOCs (with FPGAs and CPLDs filling in the gaps). 
We'll be releasing our findings in about ten internet connected devices..."
The old ASIC world required electrical engineers to team up with software engineers to make anything of significance. Back then, everything was bespoke: from the hardware up through stack to the "business logic" software that was embedded. These days, this is less common because of the proliferation of multi-purpose SoCs and cheap solid-state storage powerful enough to run full operating systems. These days,  your average C programmer can make hardware do useful things using generic multipurpose micro-controllers.

And as we all know this means new places for security problems. 

hack all the things?

Some of the vulnerabilities we will be releasing are  'remotely accessible'...some even allow an attacker to access the manufacturer's backend and spread to ALL devices from there...

So to further celebrate this brave new world of newly connected devices we at Xipiter will (over the next few weeks) be releasing our findings in about  ten connected devices that many people (according to Amazon) have in their homes. Some of these vulnerabilities are remote, meaning they can allow a remote attacker access to the hardware.

In some cases these vulnerabilities are serious enough that anyone can buy the hardware and not only remotely attack other devices but also attack the manufacturer's backend infrastructure and spread from there.

We aren't much for the "CVEs-as-resume-material" or the "CVEs-as-company-marketing" mentality that plagues our industry. We also don't want to do a "Yet Another 'Thing' Hacking" talk about this stuff.  (We prefer to be head down, make hardware and software and find cool bugs.) So, we are going to simply release our findings here and walk you through how we found them with LOTS of photos and screenshots along the way. We'll share some PoC code and maybe even share some IDB files, firmware images, and other stuff.

If after all this if you want to learn more or get hands on, there are a few seats left for our public course in November in the D.C. Area. In this class we will do all of the above and talk in greater detail about these techniques.

The interns did it...

So in short, here is what we did at Xipiter:
  1. We put our interns through our courses ("Software Exploitation Via Hardware Exploitation" and "Practical ARM Exploitation"). 
  2. Then we gave them a budget of  about $2500 to buy any devices they wanted to investigate.
  3. Then we let them loose to bang  on all the devices they purchased.

When the interns got stuck with lab hardware or lab tools, we'd help them.  When they got as far as they could go with that stuff (which was generally pretty far), we showed them (deeper stuff) like how to extract and reverse engineer binaries and firmware, write simple exploits for binaries on the targets (although many of these targets sadly didn't require too much fun binary exploitation).  They got to learn a lot. 

Picture
Ben and Mohini debug compiler errors for the firmware of their ARM microcontroller.
They approached their targets from the outside (sniffing traffic, accessing network services, intercepting firmware updates), then if required, they went deeper (opening the hardware, findings interface points, using diagnostic hardware) and finally accessed and interfaced with the devices at a hardware level with the intent to discover some remotely exploitable vulnerability. From web directory traversal down to MIPS/ARM disassembly with tools like IDA and Capstone Engine. They got to do it all.
It is also worth noting that the interns spent no time researching "prior art" vulnerabilities on each target (although they stumbled upon some). Based on what was found, Xipiter has not yet reported any of the  vulnerabilities . (At Xipiter we generally strictly adhere to our "Responsible Disclosure" policy, but we are deviating from that for this kind of hardware work by releasing everything here for academic research purposes only.) 

The targets

The interns basically combed Amazon for the more popular "smart" or "IOT" (Internet of Things) devices and purchased those. They also looked around on Craigslist and found some stuff that they thought would be neat to investigate. So here is what they purchased:
  • A "smart" smoke alarm
  • A used ATM
  • A  "standalone" webcam (A webcam not requiring a computer).
  • A "smart home" hub
  • Another "smart home" hub
  • A "smart" thermostat
  • Another "smart" thermostat
  • A home router/access point
  • A home Networked Area Storage (NAS)
  • A "smart" networked wall outlet
  • A "game console"
  • A Point of Sales System
  • and an Android tablet
Picture
Ben builds a router out of his Raspberry Pi to do SSL MITM of one of the devices...
We'll start dumping next week with some pretty devastating vulnerabilities in:
  • A "Smart Home" Hub
  • A home Access Point
  • A home NAS

Some more thoughtful words ...

At Xipiter, we do all the standard "boutique information security firm" stuff. We do source code audits, reverse engineering of mobile and desktop software but we also do quite a bit of embedded systems security work.

For some strange reason, however within the information security world there is a severe lack of knowledge in this realm. This ultimately stems from the  "hardware/software divide": Hardware guys dont understand software and software guys (even the "low level" ones) don't really understand hardware.

But in this uncanny valley there be gold. 

Attackers these days need to spend spend months/years of man hours finding and weaponizing exploits and building post-exploitation toolkits for operating systems cluttered by Anti-Virus, software updates, Intrusion Detection, Endpoint Detection, etc. Why do all this when he could just find some 90's-style bugs and hang out on your router, access point, NAS, mobile phone, "smart home" appliance, set-top box, or television? There is no protection on these things there like there is on the endpoint. These devices often have infrequent updates or updates that are trivially disabled. Even if an attacker were detected, very few of the "industry leaders" in forensics and incident response actively address non-PC hardware.

Most of the research on "embedded device" security is boring and irrelevant which leads fed-up security folks like Dave Aitel to scoff at it.  And rightfully so. Most of the people publishing the embedded security research "miss the point": How threatening is an "attack" that requires you to physically go to the location of your target to do something?  If you're the one deploying the attack it increases your costs and risk. 

But again, it is all about scope: A vulnerability found with a Facedancer in the USB stack of a "Smart Thermostat" is not as valuable a "button pressing" vulnerability found in the firmware of a Casino machine or Video Poker. But both of them are found with similar techniques. So it is the techniques that are worth mentioning.

Most "embedded device" security talks either "miss the point" and talk about irrelevant bugs or
(on the other end of the spectrum) are innovative "Hardware Security" talks that are so heavily steeped in hardware that the software guys seem overlook their importance. 

This is unfortunate because as software security people we somehow miss the significance of things like: the existence of  "CPU cheat codes" that effectively give software in userland access to all of system memory. Or overlook the significance of "memory mapped IO" that gives software direct access to peripherals that can be used for rootkit persistence. As software security people we somehow miss that there are "shadow registers" or "magic values" that can unlock other functionality in the CPU or leak back values of privileged memory.  We miss great work by folks like Felix Domke showing us that random peripherals (with software vulns) often have hidden functionality that have DMA to privileged memory regions. Why should we spend our time weaponizing vulns and building toolchains when we can just execute a few magic instructions (or get a magic value into the right register at the right time) to unlock "debug" functionality left in by the CPU manufacturer? Why should we waste time on the endpoint that can be spent finding "operationally" valuable things on devices NEAR the endpoint or that route internet traffic for the endpoint?

This is real stuff. 
Not fantasy. 
We'll show you.

We'll start dumping next week...


2 Comments

    other news

    Read Xipiter Newsletters

    RSS Feed


    upcoming training

    Practical Android Exploitation

    ​Blackhat, Las Vegas 2018
    SOLD OUT
    ​
    2019 - TBA
    ​
    Software Exploitation Via Hardware Exploitation

    Blackhat, Las Vegas 2018
    SOLD OUT

    2019 - TBA

    Practical ARM Exploitation

    2019 - TBA

    HackAWebcam Workshop

    2019 - TBA

    blog  Categories

    All
    Embedded Devices
    Exploitation
    INT.CC
    Iot
    Research
    The Insecurity Of Things


    elsewhere...

For up-to-date news on Xipiter register for our newsletters or download them. 
toll-free: 1.855.XIP.ITER main: 1.646.783.3999 fax: 1.917.746.9832 email: info (@) xipiter (dot.) com 
© Xipiter 2010-2020