Category Archives: Virtual Reality

ScrewX2 and the Insta360 WiFi security hole.

See also: my previous article.

Over on REDDIT, the subject of the gaping Insta360 WiFi security hole has come up again. User K1N6P1X3l linked to this recent article that summarizes the issue’s history:

https://petapixel.com/2022/08/29/vulnerability-in-insta360-cameras-lets-anyone-download-your-photos/

Of course, the majority of users simply will not care. “It’s very unlikely to happen to me,” they say. “And if it does, so what, they get my photos.”

In other words, this is just like any other security issue out there. Some folks treat them seriously and take steps to avoid the problems, and others just don’t care. If it were not for the “don’t care” crowd, we wouldn’t have such great malware, viruses and ransomware :)

The exploit allows anyone within WiFi range the ability to connect to your camera and do “stuff.” According to the PetaPixel article, Insta360 has already plugged some of this:

Currently the list_directory has already been terminated and it is no longer possible to access the camera content through the browser.

– Insta360 response, per PetaPixel article

Unfortunately, this is not true. Using the current available firmware, v1.0.59_build1, on my ONE X2 I see it appear on WiFi as expected:

…and if I select this interface, and then open the URL in a browser, I find all my files are indeed able to be listed:

I can then click on one of the .insv video files and play it (or save off a copy):

“And it’s just that easy!”

With this camera, there is no privacy because the camera is broadcasting itself to any WiFi devices around it, and allowing any of them to connect without authentication and then browse and view/download anything on the microSD card.

What’s worse is you can also telnet in to the device. I tried that to see if it still worked:

You will notice it did not ask for a password here, either.

Both of these screenshots (web browser and telnet) were done on my iPad.

WHILE I was connected to my X2 via the iPad, I then connected a Windows PC. Using the default password of “88888888” I was now connected from two devices (which for some reason folks think isn’t possible). Both my Windows PC and my iPad were connected and able to access the files from a web browser.

At least two firmware updates have come out since this first appeared on REDDIT, and it does not appear anything has changed.

ScrewX2: The proof-of-concept that a script kiddie could have written

Shortly after this exploit was first mentioned, someone could have easily created a script that would look for WiFi hotspots following the name “ONE X2 xxxxx” and connect to them. The script could then issue http GET commands to retrieve files on the memory card, or telnet in to delete things, potentially bricking the camera.

Worse, the script could deliver a payload of malware, and if the user ever mounted that memory card in a computer, the malware could have been ran accidentally. Hopefully most of us will never run some random executable or installer found on a camera memory card, but it would be tempting to try to find out what “360VIEWER.EXE” does, or “Insta360MacConverter.dmg” is.

I will not link to any such “screwx2” script, and will delete any links to such posted in the comments here. The cat is firmly out of the bag, with the default WiFi password known, and NO password on the web interface or telnet, so all we can do is hope that Insta360 addresses this issue eventually.

To be continued…

Insta360 ONE X2 .insv file format

Updates:

  • 2022-06-09 – Added link to ExifTool source code that parses these sections. ExifTool command line example. Updated output of parser showing the MakerNotes fields. Adding crappy brute force C test code. Added hex dump screen shots of the sections.

*** WORK-IN-PROGRESS ***

I am posting this now in case it helps someone else who is trying to figure this out. My goal is to be able to modify a video recorded in Bullet Time mode to appear as a normal 360 video file. I just need to figure out what bytes to zap in the file…


Over in the Insta360 REDDIT forum, user SalsaGreen pointed me to this Github repository:

https://github.com/nivim/Insta360toBlackBoxCSV

It contains a Python script that parses the .insv files to export accelerometer and exposure data. This gave me a good starting point for exploring the .insv file format.

From there, searches led me to the ExifTool by Phil Harvey, which has support for parsing .insv files. Here is the parsing code:

https://github.com/exiftool/exiftool/blob/master/lib/Image/ExifTool/QuickTimeStream.pl

Magic Phrase

The last 32-bytes of the file will be this special string of characters:

8db42d694ccc418790edff439fe026bf
.insv file contents.

If those characters exist, parsing can begin.

The end of the file looks like this, with offsets being bytes from the end of the file:

Offset   Length   Description
------   ------   -----------
-78      42?      Trailer
-36      4?       ?
-32      32       Magic phrase '8db42d694ccc418790edff439fe026bf'
 0       0        End of File

Trailer

The trailer is a series of (up to seven?) entries containing a 2-byte ID followed by a 4-byte offset. I am unsure if the entries are fixed, or if they can be terminated by 0x0000 / 0x00000000 entries if not all segments appear.

.insv file contents.

Segments defined in the Github Python script include:

  • 0x0101 – “.insv maker notes” (serial number, firmware version, etc.)
  • 0x0300 – accelerometer data
  • 0x0400 – exposure data
  • 0x0600 – timestamps
  • 0x0700 – GPS data
  • …and may also have 0x0900 and 0x0a00 (in comments, no code).

This makes the end of the file look like this:

Offset   Length   Description
------   ------   -----------
-78      2        Trailer entry #1 - ID
-76      4        Trailer entry #1 - Size
-72      2        Trailer entry #2 - ID
-70      4        Trailer entry #2 - Size
-66      2        Trailer entry #3 - ID
-64      4        Trailer entry #3 - Size
-60      2        Trailer entry #4 - ID
-58      4        Trailer entry #4 - Size
-54      2        Trailer entry #5 - ID
-52      4        Trailer entry #5 - Size
-48      2        Trailer entry #6 - ID
-46      4        Trailer entry #6 - Size
-44      2        Trailer entry #7 - ID
-40      4        Trailer entry #7 - Size
-36      4?       ?
-32      32       Magic phrase '8db42d694ccc418790edff439fe026bf'
 0       0        End of File

Parsing begins at offset -78 by reading the 2-byte ID and 4-byte Size. The data for that ID will be located Size bytes earlier in the file. Data parsers for each segment seek there and begin parsing.

ExifTool

I have now found that ExifTool can be used to display these items. It does not show the Trailer information by default, but here is a command that displays it in .json format:

exiftool -ee -G -s -b -j -a -T filename.insv

Maker Notes – ID 0x0101

WORK-IN-PROGRESS: The “maker notes” section appears to use a byte for the type of data, then a byte for the length of that data segment. Some of the bytes appear to be (QuickTime::INSV_MakerNotes)

Hex    Dec   Description
---    ---   -----------
0x0A   10    Serial Number ("IXSE42xxxxxxxx")
0x12   18    Camera Model ("Insta260 ONE X2")
0x1A   26    Firmware Version ("v1.0.51_build1")
0x2A   42    ? Parameters ?

NOTE: It appears that this section (0x0101) may be hard-coded to only have four entries, and the parser just reads four entries and stops. I was expecting some kind of record size or end of record marker, but looking at the ExifTool source shows it just does a for/next loop of 0-3.

Serial Number

Model

Firmware

Parameters

A simple parser I wrote in C can parse out some of these, then it gets lost at the binary data, so there is more to it than just that:

Magic Phrase: 8db42d694ccc418790edff439fe026bf
Good file.
0x0101 0x0000073a - Maker Notes
-------------------------------------------------------------------------------
Maker Notes - offset -1928
-------------------------------------------------------------------------------
  Type: 0x0a (10) - SerialNumber
Length: 0x0e (14)
  Data: 49 58 53 45 34 32 xx xx xx xx xx xx xx xx (edited out)
  Text: IXSE42xxxxxxxx (edited out)

  Type: 0x12 (18) - Model
Length: 0x0f (15)
  Data: 49 6e 73 74 61 33 36 30 20 4f 4e 45 20 58 32
  Text: Insta360 ONE X2

  Type: 0x1a (26) - Firmware
Length: 0x0e (14)
  Data: 76 31 2e 30 2e 35 31 5f 62 75 69 6c 64 31
  Text: v1.0.51_build12

  Type: 0x2a (42) - Parameters
Length: 0x71 (113)
  Data: 32 5f 31 34 37 33 2e 36 38 30 5f 31 35 32 32 2e
        39 39 30 5f 31 35 34 34 2e 35 36 30 5f 30 2e 30
        33 32 5f 2d 31 2e 30 39 33 5f 2d 31 37 38 2e 30
        31 30 5f 31 34 37 35 2e 34 35 30 5f 34 35 35 34
        2e 30 39 30 5f 31 35 30 33 2e 36 32 30 5f 2d 30
        2e 30 32 39 5f 2d 31 2e 32 39 37 5f 2d 30 2e 37
        36 38 5f 36 30 38 30 5f 33 30 34 30 5f 33 31 31
        33
  Text: 2_1473.680_1522.990_1544.560_0.032_-1.093_-178.010_1475.450_4554.090_1503.620_-0.029_-1.297_-0.768_6080_3040_3113

0x0000 0x00000000 - Unknown
0x0000 0x00000000 - Unknown
0x0000 0x00000000 - Unknown
0x0000 0x00000000 - Unknown
0x0000 0x00000000 - Unknown
0x0000 0x000f16f4 - Unknown

More work to be done on this part…

Accelerometer Data – ID 0x0300

TODO

Exposure Data – ID 0x0400

TODO

Timestamps – ID 0x0600

TODO

GPS Data – ID 0x0700

TODO

To be continued…


Crappy Brute-Force C Parsing Test Code

/*--------------------------------------------------------------------------*/
// .insv parser test.
//
// 2022-06-08 0.00 allenh - Initial brute-force version.
// 2022-06-09 0.01 allenh - Code cleanup, more defines.
/*--------------------------------------------------------------------------*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h> // for memset()
#include <stdint.h>
#include <stdbool.h>

#define FILENAME "VID_20220607_102410_00_322.insv"
//#define FILENAME "VID_20220607_104109_00_323.insv"


/*--------------------------------------------------------------------------*/
// Defines / Constants / Enums
/*--------------------------------------------------------------------------*/
#define TRAILER_OFFSET      -78
#define TRAILER_SIZE        42

#define MAGIC_PHRASE_OFFSET -32
#define MAGIC_PHRASE_SIZE   32
#define MAGIC_PHRASE_STRING "8db42d694ccc418790edff439fe026bf"

enum
{
    HID_MAKER_NOTES     = 0x0101,
    HID_ACCELEROMETER   = 0x0300,
    HID_EXPOSURE        = 0x0400,
    HID_TIMESTAMPS      = 0x0600,
    HID_GPS             = 0x0700
} HidEnum;

enum
{
    MAKER_NOTES_SERIALNUMBER = 0x0a,
    MAKER_NOTES_MODEL        = 0x12,
    MAKER_NOTES_FIRMWARE     = 0x1a,
    MAKER_NOTES_PARAMTERS    = 0x2a
} MakeNotesEnum;


/*--------------------------------------------------------------------------*/
// Prototypes
/*--------------------------------------------------------------------------*/
bool checkForMagicPhrase (FILE *fp);

bool parseTrailer (FILE *fp);
bool parseMakerNotes (FILE *fp, long int offset);

const char *getHidString (unsigned int hid);
const char *getMakerNotesString (unsigned int id);

uint32_t freadU32 (FILE *fp);
uint16_t freadU16 (FILE *fp);
uint8_t freadU8 (FILE *fp);
void  hexDump (void *ptr, size_t size);


/*--------------------------------------------------------------------------*/
// Main
/*--------------------------------------------------------------------------*/
int main (int argc, char **argv)
{
    (void)argc;
    (void)argv;

    FILE    *fp = NULL;

    fp = fopen (FILENAME, "rb");

    if (fp != NULL)
    {
        if (checkForMagicPhrase (fp) == true)
        {
            printf ("Good file.\n");

            parseTrailer (fp);
        }
    }
    else
    {
        perror ("Unable to open");
    }

    fclose (fp);

    return errno;
}


/*--------------------------------------------------------------------------*/
// Functions
/*--------------------------------------------------------------------------*/

/*--------------------------------------------------------------------------*/
// Check for the 32-byte magic phrase at the end of the file.
/*--------------------------------------------------------------------------*/
bool checkForMagicPhrase (FILE *fp)
{
    bool    status = false;

    if (fp != NULL)
    {
        int retVal = 0;

        retVal = fseek (fp, MAGIC_PHRASE_OFFSET, SEEK_END);

        if (retVal == 0) // If successful, the function returns zero.
        {
            size_t  bytesRead = 0;
            char    buffer[MAGIC_PHRASE_SIZE+1];

            memset (buffer, 0x0, sizeof(buffer));

            bytesRead = fread (buffer, sizeof(buffer[0]), MAGIC_PHRASE_SIZE, fp);

            if (bytesRead == MAGIC_PHRASE_SIZE)
            {
                if (strncmp (buffer, MAGIC_PHRASE_STRING, sizeof(buffer)) == 0)
                {
                    // Match.
                    printf ("Magic Phrase: %s\n", buffer);

                    status = true;
                }
            }
        }
    }

    return status;
}


/*--------------------------------------------------------------------------*/
// Parse Trailer.
/*--------------------------------------------------------------------------*/
bool parseTrailer (FILE *fp)
{
    bool    status = false;

    if (fp != NULL)
    {
        int retVal = 0;
        long int offset = 0;

        offset = TRAILER_OFFSET;

        while (offset < TRAILER_OFFSET+TRAILER_SIZE)
        {
            retVal = fseek (fp, offset, SEEK_END);

            if (retVal == 0)
            {
                uint16_t hid = 0;
                uint32_t size = 0;

                hid = freadU16 (fp);
                size = freadU32 (fp);

                printf ("0x%04x 0x%08x - %s\n", hid, size, getHidString (hid));

                switch (hid)
                {
                    case HID_MAKER_NOTES:
                        parseMakerNotes (fp, offset-size);
                        break;
                }

                offset = offset + sizeof(uint16_t) + sizeof(uint32_t);
            }
        }
    }

    return status;
}


/*--------------------------------------------------------------------------*/
// Parse INSV_MakerNotes section.
/*--------------------------------------------------------------------------*/
bool parseMakerNotes (FILE *fp, long int offset)
{
    bool status = false;
    uint8_t type = 0;
    uint8_t length = 0;
    size_t bytesRead = 0;
    uint8_t buffer[255];

    printf ("-------------------------------------------------------------------------------\n");
    printf ("Maker Notes - offset %ld\n", offset);
    printf ("-------------------------------------------------------------------------------\n");

    // There can be only four?
    for (int entryNumber=0; entryNumber < 4; entryNumber++)
    {
        if (offset >= TRAILER_OFFSET) // Hack.
        {
            break;
        }

        fseek (fp, offset, SEEK_END);

        type = freadU8 (fp);
        length = freadU8 (fp);

        printf ("  Type: 0x%02x (%u) - %s\n", type, type, getMakerNotesString (type));
        printf ("Length: 0x%02x (%u)\n", length, length);

        bytesRead = fread (buffer, sizeof(uint8_t), length, fp);
        if (bytesRead == length)
        {
            printf ("  Data: ");
            hexDump (buffer, length);

            printf ("  Text: %s\n", buffer);
        }

        offset = offset + length + sizeof(uint8_t) + sizeof(uint8_t);

        printf ("\n");
    }

    return status;
}


/*--------------------------------------------------------------------------*/
// Return pointer to string for Hid.
/*--------------------------------------------------------------------------*/
const char *getHidString (unsigned int hid)
{
    const char *ptr = "Unknown";

    switch (hid)
    {
    case HID_MAKER_NOTES:
        ptr = "Maker Notes";
        break;

    case HID_ACCELEROMETER:
        ptr = "Accelerometer";
        break;

    case HID_EXPOSURE:
        ptr = "Exposure";
        break;

    case HID_TIMESTAMPS:
        ptr = "Timestamps";
        break;

    case HID_GPS:
        ptr = "GPS";
        break;
    }

    return ptr;
}

/*--------------------------------------------------------------------------*/
// Return pointer to string for MakerNotes ID.
/*--------------------------------------------------------------------------*/
const char *getMakerNotesString (unsigned int id)
{
    const char *ptr = "Unknown";

    switch (id)
    {
        case MAKER_NOTES_SERIALNUMBER:
            ptr = "SerialNumber";
            break;

        case MAKER_NOTES_MODEL:
            ptr = "Model";
            break;

        case MAKER_NOTES_FIRMWARE:
            ptr = "Firmware";
            break;

        case MAKER_NOTES_PARAMTERS:
            ptr = "Parameters";
            break;
    }

    return ptr;
}


/*--------------------------------------------------------------------------*/
// Read U32, convert and return.
/*--------------------------------------------------------------------------*/
uint32_t freadU32 (FILE *fp)
{
    uint32_t val = 0;
    uint8_t a,b,c,d;

    a = freadU8 (fp);
    b = freadU8 (fp);
    c = freadU8 (fp);
    d = freadU8 (fp);

    val = (a) | (b << 8) | (c << 16) | (d << 24);

    return val;
}


/*--------------------------------------------------------------------------*/
// Read U16, convert and return.
/*--------------------------------------------------------------------------*/
uint16_t freadU16 (FILE *fp)
{
    uint16_t val = 0;
    uint8_t msb = 0;
    uint8_t lsb = 0;

    msb = freadU8 (fp);
    lsb = freadU8 (fp);

    val = (msb << 8) | (lsb);

    return val;
}


/*--------------------------------------------------------------------------*/
// Read U8.
/*--------------------------------------------------------------------------*/
uint8_t freadU8 (FILE *fp)
{
    uint8_t val = 0;

    val = fgetc (fp);

    return val;
}


/*--------------------------------------------------------------------------*/
// Dump bytes as HEX, with a tab at the start of lines after the first.
/*--------------------------------------------------------------------------*/
void     hexDump (void *ptr, size_t size)
{
    int col = 1;
    if (ptr != NULL)
    {
        for (int idx=0; idx<size; idx++)
        {
            printf ("%02x ", ((uint8_t*)ptr)[idx]);

            if ((col % 16) == 0)
            {
                printf ("\n\t");
                col = 0;
            }
            col++;
        }

        printf ("\n");
    }
}

// End of main.c

Looking for Insta360 .insp and .insv file formats.

I am posting this in case someone else is doing the same searches I am.

I am trying to find details on the Insta360 ONE X2 file formats for photos (.insp) and videos (.insv). They contain meta-data I’d like to be able and parse to determine what kind of files they are. Going by filename is not enough.Th

This came up again today when someone contacted me with a ONE X2 video that was recorded in Bullet Time mode. It was not meant to be, but because the file is saved that way, the Insta360 Studio program will not allow reframing/editing the video.

Insta360 support (via app chat) has an auto responder if you ask about changing Bullet Time files to normal videos, so they have a way to do it — if you send them the files.

In the case of Bullet Time, is is recorded at 100 fps in 3K mode. It stores both lens videos in the same file. This is the same format used when recording normal 360 video at 3K / 100 fps. It appears only the meta-data is making the file appear one way or the other.

To be continued…

Insta360 ONE X2 firmware bug list

Updates:

  • 2022-09-25 – open WiFi.

If you have found any bugs, please leave a comment with the version and details and I will add them to this list. As workarounds are discovered, I will update this list.

As a new version of firmware is released, these bugs will be re-tested. When they work for some, and not for others, a note will be added to that effect.

ONE X2

2022-04-26 – v1.0.51

  • Open WiFi – a poorly implemented WiFi system has the camera broadcast itself as a WiFi hotspot to anyone within range, and allows users that know the default WiFi password all X2 cameras have to access and download any files on the memory card from a web browser… or worse. (Suggested by commenter, yt)
  • Screen Auto Sleep – 5s timeout regardless of settings. Sometimes “1min” and “Never” appear to work, but screen keeps reverting back to around 5s before going black. (Originally reported in 1.0.41_build1)
  • USB-c connection to iPad Pro unstable. Currently is not allowing files to be downloaded. Tested with an iPad Pro (11-inch) (3rd generation). (Reported in 1.0.51)

GPS Smart Remote

1.0.8.2

  • “Camera’s remaining battery” always shows empty, regardless of charge level of camera. Battery indicator for GPS Smart Remote seems to be working.

Insta360 ONE X2 photo and video modes and filenames

Updates:

  • 2022-04-06 – Initial work-in-progress document.
  • 2022-04-12 – Added preview photos of image examples.
  • 2022-04-14 – Updated TODO list.
  • 2022-04-22 – Here is a great page covering this: https://insta.pk360.de/#insta360_tech_fileTypes/
  • 2023-05-07 – I do plan to document the X3 files. They are slightly different, including a “.insp.gyro” file that I never saw on the X2. They also add an “.lrv” extension (so you have a file that starts with “LRV_” and ends in “.lrv”). If you have found any documentation on the changes, please let me know in the comments.

WORK-IN-PROGRESS

This is a work-in-progress document with much more to be added. There are probably mistakes in it, currently. Please comment with any corrections you may have.

TODO:

  • Table showing all the various photo and image combinations (HDR, fps settings, PRO/BASIC, etc.)
  • Example files to download.
  • Conversion tips for .insp to jpeg and PRO to video files.
  • .insprj project file info (from Insta360 Studio desktop app)
  • …and more…

The Insta360 ONE X2 camera can take photos and videos in a variety of formats:

X2 Photo Formats (Standard, HDR, Burst, Interval or Night Shot)

  • 360 (using both lenses)
  • Panorama (using one lens)
  • 150-degree (using one lens)
FormatModeResolution16:91:19:163:12:1
360Standardx
360HDRx
360Burstx
360Intervalx
360Night Shotx
PanoramaStandardx
PanoramaHDRx
150Standardxxx

Google Sheet: https://docs.google.com/spreadsheets/d/11FQjS861Hn8RZJ2KkpioXR5pWu5hoFivXcBVIdNekBU/edit?usp=sharing

X2 Video Formats (Standard, HDR, Timelapse, TimeShift and Bullet Time)

  • 360 (using both lenses) – 5.7K (30, 25 of 24 fps), 4K (30 or 50 fps), and 3K (100 fps)
  • 150-degree (using one lens) – Vertical (portrait) or Horizontal (landscape)
    • BASIC: 1440P (30 or 50 fps) and 1080P (30 or 50 fps)
    • PRO: 1440P (30 or 50 fps) and 1080P (30, 50 or 120 fps).
  • NOTE: Not all qualities/fps are available in all modes.

Files are saved as .mp4 video files (150-degree videos, BASIC mode), .insv files (PRO or 360 videos), and .insp (photos).

FormatModeResolution12010050302524
360Standard5.7Kxxx
360HDR5.7Kxx
360Timelapse5.7Kx
360TimeShift5.7Kxxx
360Bullet Time3Kx
360Standard4Kxx
360Standard3Kx
150 BASICStandard1440Pxx
150 BASICHDR1440Pxx
150 BASICTimelapse1440Px
150 BASICTimeShift1440Px
150 BASICStandard1080Pxx
150 BASICHDR1080Pxx
150 PROStandard1440Pxx
150 PROStandard1080Pxxx

Google Sheet: https://docs.google.com/spreadsheets/d/1TGSu1tFUbds-aMb3VNb86Rl29h0Rlqfi3TzXUzv9sWA/edit?usp=sharing

Filename Format:

  • PRE_yyyymmdd_hhmmss_xx_nnn.EXT
    • yyyy = four-digit year (2022)
    • mm = two-digit month (01-12)
    • dd = two-digit day (01-31)
    • hh = two-digit 24-hour (00-23)
    • mm = two-digit minute (00-59)
    • ss = two-digit second (00-59)
    • xx = camera
      • 00 – back camera (.dng, .insp, .insv, VID .mp4) or both cameras (.dng and .insp)
      • 01 – back camera (LRV .mp4)
      • 10 – front camera (.dng, .isnp, .insv, VID .mp4)
      • 11 – front camera (LRV .mp4)
    • nnn = sequence number (000-999)

Prefixes:

  • IMG_ – photo (ending in .dng or .insp)
  • LRV_ – low-resolution preview video (ending in .mp4 or .insv)
  • PRO_LRV_ – low-resolution preview video shot in PRO mode (ending in .mp4 or .insv).
  • PRO_VID_ – video show in PRO mode (ending in .mp4 or .insv) –
  • VID_ – video (ending in .mp4 or .insv)

Extensions:

  • .dng = RAW photo
    • xx of 00 (back) or 01 (front) – one circular image.
      • Examples:
        IMG_20220322_223414_00_211.dng (back camera)
        IMG_20220322_223405_10_210.dng (front camera)
    • Or, xx of 00 – two circular images (front and back cameras)
      • Example:
        IMG_20220322_223429_00_212.dng (both cameras)
  • .insp = 150-degree or 360-degree photo
    • xx of 00 (back) or 10 (front) – 150-degree image (single camera)
      • Example:
        IMG_20220322_223414_00_211.insp (back camera)
        IMG_20220322_223405_10_210.insp (front camera)
    • Or, xx of 00 – 360 image (both cameras)
      • Examples:
        IMG_20220322_223429_00_212.insp (front and back cameras)
    • HDR images will have three files with the same yyyymmdd_hhmmss name, xx of 00, and sequential sequence numbers.
      • Examples:
        IMG_20220211_094002_00_065.insp (back camera)
        IMG_20220211_094002_00_066.insp (back camera)
        IMG_20220211_094002_00_066.insp (back camera)
  • .insv = 360-degree video
    • LRV_ – 360 low res version of the video. xx will be 11:
      • Example:
        LRV_20220212_070353_11_003.insv (front and back cameras)
    • VID_ – 360-degree full size video. Two files with same yyyymmdd_hhmmss name and xx of 00 for back camera video and 10 for front camera video.
      • Examples:
        VID_20220212_070353_00_003.insv (back camera) VID_20220212_070353_10_003.insv (front camera)
  • .mp4 = 150-degree video
    • LRV_ – low res version of the video (vertical or horizontal orientation).
      • Example:
        LRV_20220212_112510_01_054.mp4 (back camera)
        LRV_20220211_153548_11_074.mp4 (front camera)
    • VID_ – full size video (vertical or horizontal orientation).
      • Example:
        VID_20220212_112510_00_054.mp4 (back camera)
        VID_20220211_153548_10_074.mp4 (front camera)

The filename and extension alone cannot be used to determine the type of file. Here is a table of the possible combinations:

Insta360 X2 Filenames

IMG_LRV_PRO_LRV_VID_PRO_VID_00011011
.dngxback / bothfront
.inspxback / bothfront
.insvxxbackfrontLRV both
.mp4xxxxbackbackfrontLRV front

Google Sheet: https://docs.google.com/spreadsheets/d/1Gn9V-no2CSrjV274G4RkZcRgDIFD41GCWQSvPhoFoEQ/edit?usp=sharing

You can see that .dng raw files and .insp image files use the same “00” code for single back lens images and 360 images that use both lenses. Insta360 has suggested using the file size to know if the image contains just one back lens image or both lens images.

360 Image File Examples (.insv)

NOTE: You can preview a .insv file by adding the extension “.mp4” to the end. In this example, I took all my .insv files and renamed them to “filename.insv.mp4” (so I could preserve the original extension in the filename). That allowed me to preview them in GraphicsConverter on the Mac.

You will see there should be an “LRV_yyyymmdd_hhmmss_xx_nnn.insv” file which is a low res preview movie containing both the front and back camera, then two “VID_” files with the same date/time and number, with one having 00 for the back camera and the other having 10 for the front camera:

Insat360 360-Degree .insv video (LRV low-res both cameras, VID back and front cameras).

The LRV_ files are only used by the Insta360 Studio program.

Timelapse 360 Example (.insv)

However, a time-lapse .insv recording will not have a LRV_ version. Here are two .insv time-lapse files for the same recording. 00 for the back camera, and 10 for the front camera:

Insta360 360-Degree .insv video (VID back and front camera).

150-degree Example (.mp4)

The camera will save two files: a low resolution LRV_ file with 01 if it used the back camera or 11 if it used the front, and a full size VID_ file with 00 for the back camera or 10 for the front:

Insta360 150-Degree .mp4 Timelapse video (LRV low-res, and VID full size).

360 Image Example (.insp)

The camera will record one .insp file which contains both the front and back camera images.

Insta360 360-Degree .insp photo.

150-Degree Image Example (.insp)

The camera will record one .insp file which contains either the front camera image (10) or back camera image (00):

Insta360 150-Degree .insp photo.

…More to come…

Insta360 ONE X2: default WiFi password and telnet root access?

Updates:

  • 2022-1-28 – Additional details.
  • 2022-1-31 – Added link to YouTube video discussion.

Over on REDDIT I found a troubling post about the 360 camera I am currently reviewing:

Doing a bit of searching led me to more information elsewhere in a forum post from 3/6/2021:

https://www.goprawn.com/forum/ambarella-cams/19528-insta360-one-x2-runs-on-amba

How can a popular consumer product have a hard-coded WiFi password that gives access to all your photos and videos? Even worse, how can it have a non-encrypted telnet server (which even Windows and macOS have removed) that lets one log in as the root user without needing a password?

Since this information has been public for at least almost a year, and the problem remains in the most recent firmware update (dated 1/22/2022 as of this writing), either Insta360 is unaware of the problem or doesn’t think it is a problem.

Either way, I think I’m going to change the root password on mine, and a REDDIT reply says you can change the WiFi password if you don’t mind manually connecting WiFi to the camera each time.

Baby steps.

Until next time…

Additional Details

WiFi password is reportedly generated by Bluetooth, and ends up in a temporary file created each time:

/tmp/wpa_supplicant.conf

The script that generates this file is in /usr/local/share/script/

There, I see places where AP_PASSWD is set, overwriting a default of 1234567890 listed in wifi.conf/wifi.ap.conf.

ap_start.sh may be the one (AP = access point).

I will share details on if there is any easy way to alter the password from the default, assuming the Insta360 app allows that. My thought is generating a new file on startup and making it read-only so the app cannot overwrite it.

Shared Security Show on YouTube

Discussed at the 14:40 mark.

The many, many Insta360 Selfie Sticks

Updates:

  • 1/18/2022 – Page created.
  • 2/17/2022 – Added some Bullet Time Bundle details.
  • 4/26/2022 – Added the new Power Selfie Stick.

Why are there so many? What are the differences? Let’s find out…

The first problem is that the official insta360.com online store does not currently give any specifications of these accessories. Only two mention a length in their product name. You can find their full accessory list here:

https://store.insta360.com/accessory

The following table will contain information as I obtain it.

Summary

Product
Collapsed LengthExtended LengthWeightBuilt-In Tripod?PriceNotes
2-in-1 Invisible Selfie Stick + Tripod24 cm / 9.4 in105 cm / 41.3 cmYes$25
70cm Invisible Selfie Stick15 cm / 6 in70 cm / 27.5 in$19.99
120cm Invisible Selfie Stick23.5 cm / 9.25 in120 cm / 47.4 in$16
All-Purpose TripodYes$34.90
Bullet Time Accessory (2022 bundle)120 cm / 47.2 inIncludes Handle (Tripod)$55
Bullet Time Handle (Tripod)16.9 cm / 6.6 inN/AYes$40
Extended Edition Selfie Stick (new version)36 cm / 14 in3 m / 9.8 ft$99.99
Extended Edition Selfie Stick (old version)55.8 cm / 22 in304.8 cm / 10 ft
Power Selfie Stick33 cm / 13 in100 cm / 39.3 in$69.994500 mAh battery and power/shutter buttons. Cannot get wet.

120cm Invisible Selfie Stick

  • Possibly the one included with the special Apple Store X2 kit.

2-in-1 Invisible Selfie Stick + Tripod

  • Larger selfie stick (in thickness) with a fold-out tripod at the end of the handle.

70cm Invisible Selfie Stick

  • Possibly the stick being included with the Bullet Time accessory.

All-Purpose Tripod

  • A tiny tripod base that the selfie sticks can screw in to.

Bullet Time Accessory

  • Includes a special tripod base with a spinning top. The top can be locked so it will not spin. A selfie stick can be attached at the top to use this as a tripod, or on the side, to use a bullet time accessory. (Kit shipping in 2022 includes a 120cm selfie stick, but the packaging had a spot that was designed to hold a taller collapsed stick — no details on what that one was.)

Extended Edition Selfie Stick (new)

  • No details yet.

Extended Edition Selfie Stick (old)

  • No details yet.

Power Selfie Stick

  • Contains a 4500 mAh battery to double the shooting time of the camera. (The battery included with the X2, for example, is about 1600 mAh).
  • Contains buttons to start/stop the camera so you can use it like a remote control.
  • 100 cm extending length. (This makes it a selfie stick with the battery, different than things like the LUME power handle, which is just a handle with a battery).

Giroptic announces new 360 camera for iOS devices

If you have an iPhone or iPad, and want to take 360 photos like the Ricoh Theta does, you may soon be able to do so with a $249 add-on from Giroptic:

https://www.giroptic.com/us/en/giroptic-io

This Giroptic IO connects via the Lightning port and has two lenses. It allows the recording of 360 photos or video which can then be uploaded via the iPhone or iPad.

The device has its own rechargeable battery (charged by a second port).

It’s an interesting product, though it seems it would be easier to just carry a Ricoh Theta with you instead of a clip on camera. It also does not look like it would connect to phones in thick protective cases.

But, it’s still neat… I’d love to get one to do a review of.

360 photos in 2005

I bought my first digital camera in 1996. Back then, no one knew what the term “digital camera” meant, so I would have to call it a “computer camera” for people to understand it was some kind of camera you hooked up to a computer.

I originally wanted it so I could take and post photos during visits to Disneyland and Walt Disney World. Over the years, I created a massive archive of theme park photos at my site DisneyFans.com and Renaissance festival photos at AtTheFaire.com. Between my various photo archive websites and personal photos, I expect I have easily taken several hundred thousand digital photos.

And I still don’t claim to know a thing about photography. I just point and click.

I also got involved with video editing back in the early 1980s using my dad’s VHS editing equipment. I bought my first digital camcorder in 1999, as well as an iMac DV to do digital video editing.

Over the years, I have experimented with many types of photography and videography.

Around 2004, I purchased a NuView 3-D adapter for my camcorder, and records many hours of 3-D video at Disneyland and a local Renaissance Faire.

I was also interested in Apple’s QuickTime VR, where you could have a photo that enabled you to look all around (and sometimes up and down). Taking such photos was labor intensive (requiring taking dozens of photos in different angles and “stitching” them together with special, and expensive, computer software). But, there were some “one shot” solutions being offered that involved shooting against a circular mirror that would capture a panoramic image 360 degrees around.

Back around 2004-2005, I had a web page listing the various lens systems I had found:

http://os9al.com/oneshot360/index.shtml

The mirror system I wanted cost almost $1000, so I never bought one, but I did purchase a cheap knockoff called SurroundPhoto. It was a plastic lens with marginal optic quality, but at least I could afford it. I picked one up for around $130, and then picked up a Nikon Coolpix 5400 camera to use with it.

I took the 360 setup with me on a trip to Disneyland during  a trip in December 2005. I wanted to take 360 photos of Main Street and create an update to an old 1996 virtual tour I created using normal photos.

I also took the camera to the Kansas City Renaissance Faire, and to the future construction site of the Des Moines Renaissance Faire.

Beyond posting a few sample photos, I never did anything else with the device.

I recently discovered the photos I took, and thought I’d share a look at what 360 photography was like back in 2005.

The camera shot upwards, pointing to a circular curved mirror. The raw photos looked like this:

360 Disneyland in 2005.
360 Disneyland in 2005.

Special software for Mac or Windows could then convert this circular image in to a panorama:

Panorama of Disneyland  2005
Panorama of Disneyland 2005

Special viewing software could then be used to pan around in this image, with a tiny bit of up and down.

Today, this type of image would be taken with a single 180 degree wide angle lens (like the Kodak PIXPRO SP360) or with multiple lenses like the RICOH THETA or Giroptic 360cam.

One of my winter projects is going to be to finally build this Disneyland 2005 panoramic tour. The picture quality is pretty horrible by today’s standards, so I present it mostly as a look back at the humble origins to 360/VR photography that is so common today that even Facebook natively supports it.

More to come…

Giroptic 360cam review by a Ricoh Theta owner

Updates:

  • 2016/07/20 – more commentary.

[vrview img=”https://subethasoftware.com/wp-content/uploads/2016/07/360_0027.jpg” ]

I have been following 360-degree (sometimes called VR) images for many years. I even had an old webpage dedicated to one-shot VR style devices like the 0-360 mirror device.

The whole concept of a VR-style picture, where you could move the image and look in all different directions, was pioneered in 1994 by Apple QuickTime VR. In those days, you had to mount a camera on a tripod and take a bunch of photos then have them stitched together using special software. The viewer (QuickTime) then allowed the user to look left and right in the image.

As time progressed, other methods of doing these types of images were developed, including a process where you used a 150-degree fisheye lens and took only two photos and stitched them together. These spherical images allowed you to also look up and down.

0-360.com's one-shot VR lens attachment.
0-360.com’s one-shot VR lens attachment.

The easiest solutions were one-shot devices that used a mirror. The camera would point up towards the mirror and create a donut-like image that could then be turned in to a VR image without any stitching. I always wanted the 0-360 device (about $600), but ended up with a much cheaper one called SurroundPhoto ($250). It produced poor quality images, but you get what you pay for.

In recent years, special multi-lens cameras have been introduced that are substantially cheaper than a camera+lens mirror system, and can offer greater field-of-view (up and down).

The Giroptic 360cam was the first such camera I became aware of when it was announced as a Kickstarter project in 2014. It a three-lens camera that can take a 360 VR-style picture with one shot.

I signed up to get one at the half-price early bird level, and at the time they hoped to ship before the end of the year. A year later, the camera was nowhere to be found. During this delay, other similar devices from established companies  entered the market at a much lower price point, including:

  • Kodak SP360 – I saw the one advertised at RadioShack for under $300. It used one lens with a huge fisheye pointing up, so it couldn’t get full VR images, but it could create a circular panorama. It could be mounted on a bike or helmet so it was more of a 360 GoPro type device.
  • Ricoh Theta – This $350 two-camera came out with a first model, then the m15 improved model (which added video!) . It could instantly create full 360 images with one click. I had the m15 model.
  • …and likely many others by now.

The Theta m15 and it was amazing. It was small enough to carry with you at all times, and as fast as a regular digital camera at taking the images. There was an iOS and Android app to download and post photos and videos from the device and share them immediately. The resolution was not great. Photos and video could be especially grainy in lower light situations.

In July 2016, the 360cam finally shipped to all of it’s original 2014 backers. Today I want to quickly review how the 360cam stacks up. To save you some time, I’ll present the conclusion first:

CONCLUSION:

This camera is way too slow to be useful. I believe if you are looking in to a device like this, you should probably get something like the Theta S (now available at Best Buy). It is substantial cheaper, easier to use, and much easier to carry around. If there is any advantage to the 360cam’s three-lens setup, I feel most users will not benefit from it.

DETAILS:

The 360cam is neat, and had I obtained it two years ago (before owning a Theta), I would have raved about it. But today, it feels like a dinosaur.

CONS:

  • Heavy. The 360cam is much heavier than the candy-bar style Theta.
  • Bulky. It is the shape of a smaller pear, and therefore cannot be carried in a pocket. After lugging mine around, I find I have to carry a fanny pack or other type of pouch with me because there’s just no convenient way to attach something like this to a belt. (The Theta came with a belt strap padded carrier.)
  • SLOW! Oh my gosh. This thing is stone-age slow! When you turn it on, it takes about 25 seconds to boot up! This is ridiculous. Forget any concept of pulling out the 360cam and taking a quick photo. You have to plan ahead. Also, switching between video and photo mode is also frustratingly slow. My device spins a little animated mustache graphic for about 28 seconds while it goes from one mode to the next! (And right now, the display is showing me “E801” so I guess I have to go look up what went wrong. A quick look at their support site shows five codes, including the 801, that could mean “Something might be wrong with the camera last firmware update. You can restore your camera to factory settings, and try to update the camera again.” Great.) It also does not take pictures quickly. I have mine set for a 3 second countdown, and it will often display a little animated graphic for a few seconds before it even gets to the countdown! Useless!
  • iOS iPad App only works in Portrait Mode. In this modern era, why are any iPad apps still not supporting device rotation? The VR images rotate just fine, but all the menus are set for portrait mode, which seems odd for a world where video and modern digital images are 16×9 landscape.
  • More Seams. Three lenses means you will have three seams in your images, rather than just two with a two lens system. With the Theta, you just pointed it at your subject and hit the button. With this thing, you have to make sure one of the three lenses is pointing there to prevent a theme down it. Frustrating, but once you get used to this, it will become second-nature.
  • No Bottom View. Since the base of the camera is large, there are no straight down views offered. Instead, a large circular graphic is placed there (just like old VR images had, to hide where the tripod was). The Theta has no problem with straight down.
  • SHORT Battery Life! It seems with the unit on (WiFi and GPS enabled), you will be out of juice in 30-60 minutes just having it “on” and barely using it. I am watching the battery drain as I type this. I doubt I could ever fill up my 16GB memory card with only one (or maybe even two) batteries. I managed to completely drain the battery after recording a 9 minute video, and about 30 images. Do not expect to take this with you all day without stocking up on a ton of extra batteries.
  • App Required to Change Basic Settings! Why do I need the use my phone and WiFi to change between one picture and self timer mode? By the time I toggle through 360cam menus to turn on WiFi, then connect to the camera. then run the app … I’ve forgotten what I was trying to take a picture of.
  • Awful User Interface. The built in color display (big pixels) is neat, but the user interface of two buttons is very sluggish and cumbersome. At least it’s better than having to remember what button to hold down to change modes (like the display-less Theta does; they fixed that with the new S model). Once you learn how to navigate, it becomes easier, but it it still time consuming to dig through a half dozen or more displays to make a simple change.
  • SLOW!!! Did I mention how slow this thing is? It’s ridiculous.

That said, let’s look at the PROS:

  • Three lenses! This should mean better resolution for video and photos. But does it? I do not have a Theta S to compare side-by-side, so I will leave that to other reviewers. I will say the images from the 360cam look very nice and it handles low light better than my Theta m15 did.
  • GPS. The 360cam has GPS built in so images can be geotagged without requiring linking to a phone. That’s nice (but it will drain the battery quicker).
  • Removable battery. My Kickstarter package came with two batteries, so I can charge them up and swap them out during the day. Unfortunately, you have to pop open three connectors on each side and remove the base (and not lose the microSD card that seems to pop out easily). It’s a “stop walking to do this” operation.
  • Nice iOS and Desktop Software. The app and desktop software are nice, and probably on-par with the Ricoh software. They allow remotely operating the camera, changing modes and limited sharing. You will need to link your 360cam to an iOS/Android device if you want to change modes (one photo, self timer, timelapse, etc.). That is frustrating but at least the modes are there.
  • “Patch”. Many 360 image systems allow you to put a special graphic at the bottom of the image where the tripod would go. Giroptic refers to this as the “patch” (I’d call it a logo). You can customize your own logo, which is a nice touch. The last Ricoh I used had no such option.
  • NO HUGE FINGERS!  Since you can hold the 360cam by the base and take a picture using the self timer, you can voice the HUGE THUMBS problem all the Ricoh Theta selfies seem to have. This is very nice.

I personally plan to get rid of the 360cam and replace it with a Theta S soon. I’m quite disappointed. While I might be able to get used to the pear-shape, the slowness of this device is absolutely unacceptable. “Hey, let me take a cool picture. Everyone wait a minute while I boot up and switch from video mode to picture mode.”

Great attempt, Giroptic, but competition has rendered your device obsolete except for those who may benefit from the three-lens setup. I would have to see a side-by-side comparison to see if the 360cam even has that advantaged.

Just get a Ricoh Theta S and use the heck out of it :) They are $350, versus $499 for the 360cam.