Today's Deep-Dive: thingino

Welcome to the Deep Dive.

We're the show that tackles those dense tech docs,

research notes, all that complex stuff,

and basically gives you the shortcut to understanding it.

Today, we're digging into a really fascinating corner

of consumer tech.

What happens when you decide you want real control,

open source control, over hardware you already own?

Specifically, IP cameras.

Yeah, it's a great topic, taking back control.

Exactly.

We're focusing on Thangino, that's T-H-I-N-G-I-N-O,

an open source firmware project.

And before we jump right in, I have a quick shout out

to Safe Server for supporting this deep dive.

Safe Server handles hosting for projects like this

and can support you in your digital transformation.

Check them out at www.safeserver.de.

Good support is crucial for this kind of thing.

Absolutely.

So our mission today, to break down Thangino for you,

especially if you're new to this,

we want to give you the clear entry points,

but also, crucially, the big warnings,

straight from the project's own sources, like their GitHub.

Yeah, the warnings are important here.

OK, let's unpack this.

Right, so first things first.

Let's make sure everyone's on the same page about firmware.

What is it?

Good point.

Go ahead.

Well, think of firmware as basically the operating

system for your camera.

It's the core software that tells it

how to record video, connect to your Wi-Fi, all that stuff.

OK, makes sense.

Like Windows, but for a camera.

Sort of, yeah.

A very specialized OS.

And Thangino, it's a replacement for the software

the camera came with.

It's open source, built by the community.

So you're swapping out the company's code

for community code.

But it won't work on just any camera, right?

What's the target?

No, definitely not.

It's highly specialized.

The Gino targets IP cameras that are

built around a specific family of chips.

Ingenic system on chips or Socus.

Ingenic, like the T31X or T23N chips the docs mentioned.

Exactly those.

They're super common.

You find them in tons of cameras, both generic ones

and big brands.

By focusing just on these Ingenic chips,

then Gino can offer something really robust, customizable,

and importantly, more private without manufacturer backdoors

or limitations.

And looking at the sources, this isn't some weekend project.

It looks pretty serious.

Oh yeah, it's active.

The GitHub repository shows that clearly.

We're talking an MIT license, which

is great for open source, and the numbers.

Wow, over 1,100 stars, 138 forks, 66 contributors.

That's significant community backing.

That kind of support is essential, honestly,

given how complex firmware can be.

And something else interesting from the source

is the breakdown of programming languages used.

Right, I saw that.

Mostly shell, like almost 50%, and make file at 36%.

What does that tell us?

It doesn't sound like typical app development.

It tells you this is fundamentally

about building the environment.

It's less about writing a fancy user interface

and more about controlling the whole build process.

Shell scripts and make files are perfect for automating

the compilation of the Linux kernel, all the tools,

the drivers, everything needed for these slightly

different Ingenix chips.

Oh, OK.

So it's the scaffolding that lets

them build the actual firmware for all those different camera

models they support.

Precisely.

It's the backbone.

It makes the whole thing manageable for the community.

That makes a lot more sense.

And for anyone wanting to explore or needing help,

the project seems well set up.

The source is mentioned, a project website, a wiki,

even a Discord and a Telegram group.

Yeah, it's a proper ecosystem.

You're not left on your own.

Which is good because, well, here's work

it's really interesting, maybe a bit tricky.

We have to talk about what supported camera actually

means.

It's not straightforward.

This is probably the biggest hurdle for anyone starting out.

The documentation is very clear, very blunt about this.

Just because your camera's model name,

say a TP-Link Tapo C110 or a Wyze Cam 3 is on their list,

that doesn't guarantee thingy know will work.

Wait, hold on.

Why not?

If I buy a specific model, shouldn't the insides

be the same?

You'd think so, wouldn't you?

But unfortunately, especially with mass market electronics,

it's common for manufacturers to swap out

internal components between different batches

of the exact same model.

Really?

Why would they do that?

Usually cost.

Or maybe a specific chip becomes hard to get.

So they find a replacement part that, from the outside,

does the same basic job.

They don't change the model number on the box,

because it still records video.

But for something like Thingino, which needs to talk directly

to the hardware, a different chip inside

could break everything.

Exactly.

It completely breaks compatibility

at that low level.

So if you want to solve Thingino,

you basically have to become a hardware detective.

You need to verify four specific internal components

in your specific camera unit.

Four components.

OK, that sounds intense.

Walk us through them.

What do you need to check?

Number one, the most critical, the SoC, the main chip.

As we said, it must be a compatible Ingenic one,

like a T31X or similar.

All right, got it.

Second, the image sensor, that's the part that actually

captures the picture, like a GC4653 or an SC2336,

the Dock's List specific ones.

OK, SoC sensor.

Third, the Wi-Fi module, the chip that

handles the wireless connection.

Again, specific models matter, like an ATBM6031 or RTL189FTV.

OK, and the last one.

And finally, the flash chip size, the little chip

that stores the firmware itself.

Did your camera have an 8-millibee chip,

16-milli, 32-milli?

That needs to match the supported combination, too.

Wow.

SoC, image sensor, Wi-Fi module, and flash size.

If even one of those doesn't match the exact combination

listed for your model in the Thinggeno Docks,

it might not work, or worse.

Or worse, yeah.

You could potentially break it.

That's why the hardware list is so detailed, listing models

like the Wi-Fi E220 or Wyze Cam Floodlight,

but always with footnotes about the specific internal combo

required.

So the name on the box is almost irrelevant.

It's the silicon inside that counts.

In the world of firmware, the hardware combination

is the real model number.

That's the key takeaway.

OK.

Now, for listeners who are maybe a bit more technical,

curious about how to actually build this firmware,

the sources give instructions, right?

But it's not just downloading a file.

Not at all.

You had to compile the entire operating system yourself.

This involves something called cross compilation,

meaning you use your regular computer, probably

a Linux machine or maybe a virtual machine,

to build software that runs on a totally different type

of processor, the little nginic chip in the camera.

The project uses tools like Buildroot,

which the source has mentioned, to manage

this whole complex setup.

Right.

Buildroot handles the environment.

So let's quickly go through the main steps,

not just reading the commands, but what they do.

Sure.

It usually starts with get clone recurse submodules.

That command grabs the thinggino code,

but the recurse submodules part is crucial.

It also pulls down all the other necessary code libraries,

gets to the Linux kernel, Buildroot itself,

specific drivers, everything needed.

So it's downloading a whole development kit, essentially.

Pretty much, yeah.

It can be quite large, gigabytes even, and take a while.

You're getting the whole ecosystem.

OK, so you've cloned the ecosystem.

Then you navigate into the folder,

usually CD-Thingino firmware, and the main command, make.

Just make.

It's just make.

That one command triggers the whole automated process

we talked about earlier, using all those shell scripts

and make files.

It configures the kernel, compiles all the software

parts, links the right drivers for your specific hardware

combo, those four components, and finally,

packages it all up into a firmware image file

that you can then flash onto the camera.

And that make process isn't instant, I assume.

Oh, no.

Depending on your computer, it could easily take 20 minutes,

maybe longer, especially the first time.

It's doing a lot of work.

OK, that really drives home that this

is a serious hands-on process.

You're building something custom for your specific camera's guts.

So let's say you've done your homework.

You've identified your four components.

You've managed to build the firmware.

Now what?

Before you actually try to install it,

the sources highlight two really big warnings,

two major hurdles.

Yes.

And these carry significant risk.

The first, and honestly the most dangerous one, is secure boot.

Secure boot.

I've heard of that.

How does it apply here?

Well, the sources talk about conditionally supported hardware.

Often, that condition is whether secure boot

is turned on in that specific camera unit.

Basically, secure boot is a security feature

built into the chip itself.

Some manufacturers, during production,

read a secret digital key into a special part of the SoZ

called the OTP area.

OTP, one-time programmable.

Exactly, one time.

Once they write that key and blow the fuse, so to speak,

it's permanent.

It cannot be changed or erased.

Like etching something in stone.

Pretty much.

Yeah.

And the chip is then programmed to only boot software firmware

that's been digitally signed with the matching secret key held

by the manufacturer.

OK, so I see where this is going.

The Nino, being open source and community built,

isn't signed with the manufacturer's secret key.

Correct.

It can't be.

So if you try to flash the Nino onto a camera where

a secure boot has been permanently

enabled in that OTP area.

What happens?

The camera's initial bootloader checks the signature,

sees it doesn't match the key locked in the OTP,

and just stops.

It refuses to boot.

And the result, the source is very clear, is catastrophic.

The camera is permanently bricked, unusable.

Bricked means it's just a plastic box, no fixing it.

No fixing it.

Unless you physically de-solder and replace the entire sock

chip, which is not practical for most people, it's dead.

Wow.

That's a huge risk.

It's like the camera actively rejects the transplant.

And the docs mentioned specific models, right?

Like some Roku or Wyze cameras tested

were found to have it enabled.

Yes.

The community tries to track which specific batches

or versions of models are known to have secure boot enabled,

often using color codes or other identifiers mentioned

in the wiki.

But it's always a risk with conditionally supported

hardware.

You have to check carefully before flashing.

Extreme caution needed.

OK, what's the second big hurdle?

Something about mystery box hardware.

Right, this is more about the unpredictability

of the supply chain, especially if you buy cameras from, say,

AliExpress or similar large online marketplaces.

What's the issue there?

Even if the camera looks identical to a supported model,

has the same sticker on it, sometimes the manufacturer

has put completely different hardware inside.

The sources specifically warn that sometimes these clones

might contain an unsupported ARM processor instead

of the required Ingenix Solve.

So even if you thought you had the right model,

the actual brain inside is totally wrong for Thinggino.

Exactly.

The outside looks right.

Maybe even some of the other ships match.

But the core processor architecture is incompatible.

So Thinggino just won't run.

It reinforces that idea.

You need to verify everything, especially the SoC type.

Got it.

And quickly, are there types of cameras

that are just flat out unsupported?

Yes.

The sources mentioned that battery-powered cameras,

particularly those using something called the ZeraTool

platform, are currently unsupported.

They have different power-saving needs

that Thinggino isn't designed for right now.

OK, so summing this up, this deep dive

really highlights that classic tech tension, doesn't it?

Thinggino offers this incredible open source freedom,

real control over your camera, getting away

from proprietary cloud stuff.

Which is very appealing for privacy and customization.

Totally.

But that freedom comes bundled with some serious

responsibility.

You absolutely must do that deep hardware check,

understand the components, and you

face that potentially fatal risk of secure boot turning

your camera into a paperweight.

And that risk leads to a really interesting final thought

for you, the listener, to ponder.

If security features that are meant to protect users,

like secure boot verifying firmware,

are locked down so tightly with these permanent hardware keys,

does the convenience and, let's face it,

the warranty back simplicity of just using the manufacturer's

pre-signed firmware maybe outweigh the absolute

customization you get with the Ingenio?

Especially for something like a security camera,

where does that balance lie for you between total control

and guaranteed, albeit potentially restricted,

functionality?

That's a great question.

Control versus safety, openness versus locked down security,

definitely something to think about regarding

the devices in your own home.

A big thank you again to our supporter, Safe Server,

for making this exploration possible.

Remember to check them out at www.safeserver.de

for hosting and digital transformation support.

So whether you decide to venture into custom firmware

or stick with what came in the box,

now you've got a much clearer picture of the internals,

the risks, and the power involved with your IP camera.

Go explore these ideas further.

We'll catch you on the next Deep Dive.

We'll catch you on the next Deep Dive.