Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/358 Thanks!
Thanks, everybody, for coming to the talk
and thank you to the Congress
for having us again this year.
We're really pleased to be here
and to share with you some of our latest
work, looking at
some of the sort of the developments
that have been going on in China and
seeing what we can do to try to bridge
the gap between what's happening there
and here.
So before we get into all the technical
details, I wanted to share with you
the provocation, the reason why
we kind of got motivated to do this in
the first place.
There's a lot of people who have done
work in the past and reverse engineering
various based bands of phones and so
forth. But this path,
this whole project started about
two years ago when we were wandering
around in the markets of Shenzhen, China.
If you haven't been there, I highly
recommend it's a super cool place with
lots of I mean, it's a it's a kind of
place where you can go up to shelf and
sort of just by taping real resistor
like you would buy fish or meat at a
store or something like that.
So it's a hardware guys paradise.
And we found a phone there,
a complete GSM phone that can do
calls, broadband, Bluetooth, all that.
And it's twelve dollars, you know, not
a full stop. But this is not with someone
discount counting or subsidizing
or some contract on the back side,
the middleman margin, everything is
there. And we were amazed at
its low price. So of course, we bought
one and took it apart and
looked at what was on the inside and
found that had this two hundred
sixty megahertz, 32 bit CPU,
and it had lots of features built into
it. And we sort of
looked at what sort of was
the thing that the Chinese
entrepreneurs were playing with at the
time and compared it to what we saw, what
most the Western entrepreneurs were
playing with at the time, which was sort
of something closer to an Arduino,
which would be based on the mega with the
eight bit CPU and assisting megahertz
and still costing more in quantity
one as sort of a
reference point. Right.
And so my feeling was, geez,
how come we don't use this
more often? Why isn't why aren't there a
series of talks at places like
this about people building stuff with the
sort of hardware?
And so we say, OK, well, can we have
documentation if
you can?
Read or write a little Chinese or even
use Google Translate and you know how to
use Baidu, which is sort of China's
version of Google, you can actually just
find schematics, reference schematics for
this online.
Right. Which is pretty cool.
And if you dig a little more, you can
actually find downloadable source files.
You can find the CAD
files in an edible form.
You can find the orchid schematic files
just like you can get the cat files for
the Arduino online.
And if you dig even more digging,
you can find, for example, the entire
source code for the OS that runs on these
phones. It's a seven point five gigabyte
source archive.
You can just dump it from Baidu.
And, you know, you could
kind of do what they call the Senzai
thing out there, which is building your
own phone.
The question is, at the end, is it
actually open, right, and the problem,
of course, is that this stuff
is either gray or restricted
or unspecified.
So if you go in, for example, read
carefully, it will be confidential
notices all over the data sheets
or if you look at the schematics and
so forth and don't even have a copyright
notice, they don't they don't have that
sort of notion of it.
But it turns out that China just don't
care. Right.
This technicality does not stop
the Shanghai. In fact, there's sort of
this view if you read some of
the common threads that people have about
various Western innovation and stuff like
that, you'll see people being like
Western IP laws and ethical.
These drug companies are overcharging for
life saving drugs.
This 20 dollar IP burden for mobile
phones or thirty dollars for DVD is
basically rich companies stealing from
the poor. We came and put Reisen on our
table and we worked so hard to
essentially, they call it making Kabbage,
like all this hardware is being cost
reduced and then there's a huge amount of
money going to the IP block.
And so at the end of the day, sort of the
enforcement of laws is kind of subjective
and selective out there.
But it's not like this is caused
a degradation of innovation out
there. In fact, if you go there and you
look around, there's actually this
sort of permissive IP environments
bearing fruit.
This here is sort of a shot of
a typical display case.
And when the mobile phone markets, every
object you see there on the left
is capable of placing a phone call, the
cars have little phones in them.
The little like Apple things have
phones in them that aren't Apple phones.
And on the right hand side is
this example of a guy who just really
like Skeleton's.
And he built this phone in the shape of a
skeleton, complete with like on the
inside, there's like this sort of etched
metal case cases, the skeleton on the
inside. It has a skeleton theme, boot
sequence and all sort of stuff.
And they just build it because they
want to build it. Right. It's so
effortless in that ecosystem
because there's lower barriers for them
to go ahead and rip, mix, burn and create
kind of interesting little things like
this.
Unfortunately, the West does
care, right, you can't build
a business on, quote unquote, stolen
IP, right?
So why not just ask, for example,
mediatheque, that people make these chips
for a license?
And I know people who have tried it and
either you get no response
or you get sort of a demand for a
quarter million dollar prepayment on
potential order volume.
Right. That you have or something like
that. And this is just not practical for
individuals and startups, a huge barrier.
I mean, people out there in China don't
don't have a quarter million dollars to
drop on a potential IP license for
something. They they actually build these
whole phones and get them out for, you
know, tens of thousands of dollars.
Full stop. Right.
And so there's a sort of feeling
you get the sort of sadness is like,
so you're telling me that
the Chinese both get to build our
iPhones and the cool little
weird phones. Right.
And the West gets to focus on
building things are accessories to
our smartphones.
Like we can build the egg minder to tell
us how many eggs are in our fridge that
work with your iPhone.
Or you can have like this tank that's
controlled by iPhones, not included.
Right. That's sort of state of the art
right now that's happening here.
It's sort of just like
why it really blows
my mind. I have to agree with this guy.
Right.
And so our question is
like, can we hack the
system? Right.
And of course, challenge accepted.
So before
walking in, we want to kind of understand
the lay of the land and
we want to know sort of what's at stake.
And so this is where sort of the the
legal sort stuff comes out.
Of course, the standard disclaimer, we're
not lawyers, right?
We're not giving you legal advice.
We're going to show you the set of views.
However, that being said, I want
people to.
Feel that law is like a tool, it's a tool
that if you use it, it can have
potentially life changing consequences,
but it's also a very powerful tool.
Right. And like most people in this
audience, we like tools are extremely
powerful. And so we should learn
the law and we should learn our rights
in the law and exercise our rights
vigorously.
And so the set of laws
that we're sort of looking at in this
case are copyright
issues like the CFA about accessing
the servers and so forth, contract law
patents and so on, so forth.
It's a very complex set of issues that
won't go very deep into them, but sort of
touch on the surface.
If has a great FAQ on this called reverse
engineering fact, there's a link up
there.
If you want to read more, you can check
it out there. But sort of
the very sort of root of what we
look at when we're sort of reading
these Shandi documentation and figuring
out how we can kind of do a clean
translation is a set of
case law out there.
This is an example of one feisty
rule where sort of they was a
lawsuit about phone books being copied
between different people, and they ruled
that you could go ahead and recompile
lists of facts so long
as you did not feature the same selection
arrangement of facts.
Right.
And we feel that, for example,
if you give me a list of registers and
their addresses will be present
in the data sheet, those are kind of like
items in the phone directory.
Those are just facts.
And the address and data pairs
about what each bit does or the measure
is also a fact. So when you say set of
the PLL by writing this data to this
register, that's a fact that's
not copyrighted.
But we can go ahead and understand those
facts and express it in our code
and apply an open license to
it and in that way sort of repatriate
intellectual property from one ecosystem
into another.
So and the basic
idea of this is there's a couple of cases
that were heard that sort of ruled
that we have a fair use, right, to
achieve interoperability.
Our rules of engagement then is that we
only make the copies that we need.
They're absolutely necessary for reverse
engineering.
We read the data sheets, the binaries and
the codes we produce from the facts, and
then we turn them into our own expressive
works that we can apply a license to.
We don't do any copy and paste of code,
including kind of comments.
And we also in order to prevent what we
call subconscious plagiarism, if you're a
coder and you read a code motif,
you can walk away and then almost code it
like verbatim from memory because, you
know, understand everything and it tends
to be the same representation.
Regardless, we actually created a sort
of pseudocode language that will go into
later on that will help us avoid
this. There's a sort of a preview of the
pseudocode language on the left is sort
of what the C code looks like that you
would might find if you were to look
in sort of some of these code databases,
which pages and pages stuff, and we just
turn it into this list of facts is on the
right hand side for, for example, in this
case, initializing the PLO.
A lot of people worry about things like
the DMCA, the good news in
our case is that we didn't have to
circumvent anything.
So DMCA is about circumvention.
So there's probably no DMCA problem
because all the files and bindings were
kind of in Playtex.
There's maybe some shotgun checks, but
that's not an access control.
That's just a verification of the
contents.
There's some question about things like
contracts and CFA search.
So, for example, if we had to
access a server in an unnatural fashion
to go ahead and get these files, there
could be some liability under US law for
doing that. But the good news is all the
stuff we can just sort of do a search
query download from public service.
So I think we're clear there.
And we also these phones came with
no shrinkwrap. There was no cut here.
And we have all your rights.
There's no click here in
terms of use on all these phones.
So basically, we there was no point at
which we could have waived our rights to
reverse engineer as well in this
particular ecosystem.
So that's also good news.
So at the end of the day, OK, is what
we're doing legal?
I don't know. I mean, like we've we did
some research, we asked some lawyers
and we you know, we want to avoid running
afoul of the law, but it's
impossible to be 100 percent sure.
One of the things you just have to do is
you just have to do it right
and you have to put yourself out there.
Maybe you get sued and
maybe you win. And if you win, then
it becomes legal precedent.
Sort of one of the sad part is that
there's no lawsuit and or whatnot.
It doesn't really actually make a
difference, legally speaking, but it does
help sway the community feeling
and reduce the chill around some
of these activities.
But at the end of day, we think we have
fair use rights and we're happy to
exercise it.
There's also an issue around patents that
would be a whole nother talk.
So I'm not going to get too into it.
There's a whole bunch of people who have
patent claims, you know,
but, you know, people here, for example,
watched their movies on their laptops
with codecs that have patents on
them and this whole gray area of who's
responsible for what.
And no one really knows what's happening
there.
But basically, we don't
we don't think there's going to be any
problem in that space.
But maybe maybe someone will have a claim
against us and we'll find that later on.
Now, we're OK with that.
So now that we
feel that we
have,
you know, the rights to do this and the
ability to do this, what are we what are
we trying to do?
We decide we're going to go ahead and try
to access one of these sort of Chinese
microcontrollers as a microcontroller
first. So in other words, if when we were
like groping in the dark and thinking
we're going to build this little project
which we use for at Mega or a.T.M 30
to or should we use like a cornetist,
the six to 60 should be on that list for
us. It shouldn't be one of those things.
We're not going to use it because we
don't know how to use it.
Right. So and at that level,
the level of functionality is not to the
point. We want Bluetooth, the GSM going.
We just want to be able to run an open
source OS, build code for it and use
it like any other microcontroller.
And we also want to create an open
by Western standards, hardware and
software platform that we can share with
everybody so other people can go ahead
and get involved and help develop a legal
methodology and precedent for pulling
IP from the Chinese ecosystem back into
the Western ecosystem.
So one thing is we sort of transition
from the very first flight, I
called out the 60 to 50, we're using 62
60 to future proof
our work a little bit.
These chips do cycle rapidly through the
market, the ground for about one or two
years before they go away.
We figure I'll take about that long for
us to make some progress.
It's got to 364 megahertz CPUs.
It's a little faster and it also has four
megabytes of nonvolatile storage on Chip.
And here's sort of an interesting aside
about the chip.
This chip you can buy for three dollars,
a single quantity.
Like I said, you can do those markets
where they have rules, they cut them off.
You see here, like notan the guys tend
to just walk away with it
has multiple arm cores, eight megabytes
of RAM for megabytes of
Bluetooth, GSM battery charger, audio
codec touchscreen, so and so forth.
How many chips do you think are
pieces of silicon inside this chip for
three dollars? Like who thinks there's
one piece of low cost, right?
Two pieces.
Three more
oh, interesting, I guess maybe I set
it up so he took an x ray of
the chip sort of before
we got really into it, because we
we want to know, for example, we're
getting real chips or fake chips or
what's going on the inside.
And if you if I had a laser pointer,
I could point to this.
If you look at it, you can see the
outlines of bond wires and sort of
these rectangular fashions.
You can see multiple rectangles only.
There's at least four chips inside
this chip. And it's kind of amazing that
for three dollars, they actually build a
multi chip module, bonded all together,
pack it up and sell it to full with arm
core.
And all these bits and pieces is really,
really quite amazing technology.
So
going over that here
is sort of the system diagram.
But what we ended up building
to based our work off of, we built
sort of a base board, a main board
that just sort of has like the art and
speaker battery camera, a USB
micro SD slot, Bluetooth and sort of
Arduino like headers on it.
And when you go ahead and split off the
GSM part, so the GSM
front end so that users have to make a
bonafide choice about which GSM
analog amplifier to use and that
way hopefully get to sidestep
some of the emissions testing issue that
might have later on because it becomes a
user issue.
And also we make the UI stuff
on a separate board as well, like the
keypad SIM card, the touchscreen,
telephone, LCD, because
those things can be laid on a much
simpler to layer PCB that people can
design and eagle whatever favorite tool
they have. And they don't have to deal
with this sort of complex stuff on the
bottom. So it's a little more friendly to
people to hack and play with down
the road.
We originally wanted to sort of build
this to make it compatible
with the spark core ecosystem for those
who don't know spark core spark that is
sort of this Internet of Things module
and they have this twenty four bit pin
gypsum, but we couldn't pack enough
into this footprint.
So the actual implementation and we sort
of show it know with an arduino
to show scale looks like this.
This is the actual mainboard.
The single chip on there you see is the
six you see and it's like one
chip which is great for all that
functionality. It makes it very
low cost and easy to build these things.
And this is what it looks like
when it gets all mounted up
with the expansion
boards. I mentioned. For the other
instance, if it starts to kind of look a
little more like a phone, but you can go
ahead and mod it and do what you want to
do to go ahead and build into it, you
want to build it to be
the design process.
I mean, it is pretty standard
what you expect since we
had sort of some of the documentation
for what the pin out should be, not full
documentation, but we had sort of lists
of ball outs and names
of the balls. At least we could guess
what the functions were, by and large,
what everything was.
We did know copy and paste from the
reference material. So everything was
redrawn from scratch.
And and we kind of built it
together based on experience, educated
guesses, a little reverse engineering
where we had some ambiguities like what
these supplies did.
We busted out the different connectors
and did some comparisons to other
designs we could find on the Internet.
And so this is what the schematics end up
looking like. We have
should have a link live now, publishing
all of the source sources that we have
for this. You can download it and play
with it. This is done in Altium and
we have the circuit board layouts.
Of course, you can go ahead and download
and play with those yourself as
much as you like.
So that's the hardware platform.
And then.
There's a whole question of how do we get
the Fermor on it, we can't go ahead
and just very well say, hey, guys, just
download like the mediatheque
compiler and all the source code to build
it. That would be kind of lame.
So we we, of course, had to do a bunch of
things like, for example, figure the boot
process was, figure out where the things
are. So we always start by pulling
off the ROM and dumping the rum.
We found this little it looks kind of
like an iPhone. It's like little tiny
iPhone size for contrast.
Right.
And it's
it's you know, it's called the MP
for Terminator X.
You take it apart has when these chips on
the inside and we and this one had a
separate spiral, it would just dump
the data out of the little static
analysis, you know, some pretty
obvious sections where bootloader might
be in some recent vector tables and
so and so forth.
Did have been walke found some
stuff that looked like compressed some
zip files. And so the good
news is basically there was very little
encrypted stuff on here, if any.
So it was a it was going to be not
a walk in the park, but certainly
accessible.
Then we want to figure out sort of what
bits were actually run first and how much
was run inside the internal Soucy
Beltrami versus externally.
So we took an afternoon with the tech
scope and sort of figured out
where things are going. This I love the
scope because, for example,
if you see here, you can go ahead and
take a captcha.
You're just we're just popping out and
say, oh, that looks like probably serial
data and that looks like spy data.
And then we can go ahead and later on
say, go ahead and interpret that.
That's analog data as Sirio.
And so you can see how the science is in
it. Done six one.
That's actually what's printing out of
the port. But the scope is telling me
that. And then it actually right after
that, you see the spyware to start
starting. So you know that there's a
there's a bunch of stuff that happens on
an internal bootloader before the spiffed
just happen.
And then it tells you where the addresses
are coming from. So you can see in the
sayan lines here that the address fetches
and the codes are going across the spy.
So with this tool, we're very quickly
able to sort of figure out where the
entry vector is and what's being
done. First
we go ahead and we, of course,
just do some quick mods to
some strings that we find in there.
And if the boot fails, right.
So there's some kind of verification
going on.
And so the next step we do is we go ahead
and we instrument the phone.
So we built the laptop called
Navina, which is actually we're using
the talking right now. We go ahead and we
stick the phone inside a Navina.
There's an FPGA in the Naveena and we
go ahead and we build a ROM
emulator for the Spyro.
Basically, this is
the diagram of it.
There's an FPGA that we go ahead.
We just kind of man in the middle between
the original spiral and the CPU,
the chip select line, take a sixty four
K block of RAM and go ahead map
that into the Linux kernel
just so you can now map to
what would be the code that's running on
the phone itself.
We wire up the power line and now we can
go ahead and just patch data from Linux,
hit the reboot and see what happens.
So now we can go ahead and very rapidly
do live exploration on the
phone without having to decide or do any
sort of stuff. And you do it.
S.H. In the box, you can be traveling and
continuing your reversing work on your
hardware.
So using this regulator, we poked a bunch
of regions, um, did a little stack
and also found some Szechwan constants
and figured that there was a short one
hash appended
to the initial bootloader region
and indeed just going ahead and manually
re computing the hash, sticking it in the
Romney later trying to reboot and change
your screen.
We can tell that, say, hey, yo, food to
your mama, you know, bootloader
finished. Great.
So hand it over to jobs,
talk about some of the things we did
next.
So it's all well and good to
be to manually modify and recompute
the hash every time. But that's that's a
lot of work.
We're lazy. So the first thing we did was
we took Rotary two.
I have no idea how you're supposed to
pronounce that, but it's an open source
kind of eita equivalent that we could
actually compile on the arm CPU that
is on Navina.
So this Biram is a 64
make 64 kilobyte window that is
present within the Naveena CPU space.
So we got Rotary A two.
We've got a plugin that lets us treat
that area as the file that is being
read by the assembler.
And what we did was we
had it load code in and every time
you modify a bite, it would recompute the
signature and
reboot the phone.
And so we're doing this.
We can actually do an assembly dump
and disassembly and see what the
live code is.
And because we've computed the hash,
the phone will actually execute the code
and load it. And based on that, we can
begin a reverse engineering process and
figuring out how to get software
running on the phone now
in our searches from earlier.
Bonnie mentioned that we had some
partial documentation and there were some
blocks that were actually documented in
this. This is a close up of the manual.
You can see we have the keypad scanner,
we have the GPO blocks.
We have the general-purpose timers, which
are going to be necessary for getting a
multitasking operating system going.
And we have the serial yard.
So we have a partial documentation for
some of these blocks.
And based on that, we can start
building a putative memory map
that starts with zero address is
looks appears to be rame address.
One thousand appears to be the spy chip
that we're executing. Our first of all of
our code is going to be referenced to
relative to 1000.
Then there are a lot of question marks.
We know there's data there.
If we wrote to it, sometimes it sticks,
sometimes it's random data that comes
back. Sometimes it's all FS.
We don't really know, but we can
fill in the ones we do know.
For example, the last two lines are the
two units that are actually documented in
the reference manual.
And so based on that, we get
documentation like this.
This is the transmit holding
register.
And you could see it's it's fairly nice
documentation. And I think that they
actually released this because it's a
useful port to be able
to use when you're building Sean's iPhone
like this.
So with this information, we started
developing what we call Fernleigh.
It's our Fernvale command line
environment. It has the basics, it has
pick, it has Polke and
it has hex dump.
And then depending on what we're trying
to look for, it has one off programs that
are so short lived that they don't even
make it in to get to search for various
patterns for various blocks.
Now, the one restriction is that this
bootloader must fit within the
next bootloader, which is
fine because it's fairly small to begin
with.
So first up, we're going to figure out
that you are we're going to try and get
the driver for the work you are working,
it's the same you are is in a bunch of
other mediatheque phones.
It's the same UAT that's used in
reference manuals that are completely
open, that have been released for ancient
phones 10 years ago.
And it's part of the Manfred's manual we
had. And there are drivers for Linux that
we could look at and it doesn't require
any interrupts, which is great.
So based on this, we're able to get put
Caira and get care.
And with that, we can get a whole show
going.
Next up, GPO also
very easy.
You write a value to register a light
turns on, you're happy you go home.
It doesn't require any interrupts
unless you want to get a button, which is
great.
Not very useful at this point, though,
unless you want to turn a light on
after that.
The general purpose timer, you need that
for the periodic tick, for multi
threading multitasking.
And that's also in the reference manual.
The problem is all these three require
one thing that was not in the reference
manual and we could not fix
the thing that we needed.
We need to interrupt,
we couldn't find any way to get
interrupted, so
unarmed, there's one interrupt.
What happens is an interrupt fires.
It jumps to offset twenty four and then
that jumps to your interrupt handler.
That standardized that's standardized
across pretty much all armed ships.
The problem is we had earlier
documentation, but each mediatheque
chip is different.
We had documentation's for the empty 62
zero five and we had documentation
for the six two three five.
That's the one that Osmakac has been
worked on in the past.
And if you look here, first off, you
could see that they don't actually
give you the complete offset.
They say it's at CAQ
plus zero zero one four.
They don't tell you what address CAQ is.
And these two are also very different.
You can see that one of them is sixteen
bits, one of them 32, one of them
that offset fourteen.
The other ones that offset thirty eight.
They're similar enough, but just
completely different.
So we couldn't use these to actually
figure out what the interrupt
and the block looked like.
So we're going to try and analyze what
we have already.
Look at the RAM, the boot room in the
phone and dump it and figure out how the
boot does it.
Try some more in-depth static analysis of
the boot run of the spectrum
that we pulled off of the phone.
Try and analyze that with idea,
because this is a common chip.
You can find ROMs for other phones
online. So see if they did anything
different in theirs.
And also look at phones.
If we can't figure out something from
these manuals for the 60 to 35 or the
sixty two twenty five or six to zero
five, in all of
our static analysis, we did find this
function in RAM.
It's takes an integer,
a pointer to a function and a string.
It's always called if either 30 or
and then a function.
So the first one is where they're calling
it. Actually, this is what's installing
the interrupt handlers.
And this is actually really great because
it lets us map it lets us figure out that
Interrupt 18 is actually the handler.
Let's figure out that interrupt 13 is
actually the spy handler.
It doesn't tell us how it installs this
because there's some interaction that's
going on, but it's actually it's not a
bad first step.
So
let's get back to that file that bunny
mentioned earlier, the empty K
11, B 13, 08,
a great naming scheme.
It's customized to the empty 60 to
60. And it's the source code for the
entire operating system.
And the nice thing is that the AYAKA
exists in source form.
So you could look at this file, this
Syracuse, England, to control
underscore MTIs six
two six zero.
And that contains a list of all the
interrupts, along with a list
of register offsets and addresses
where the various bits are.
But it also gives us a complete memory
map in this header file here under Reg
based INC, which lets us figure it lets
us remove all the question marks that we
had in that memory map that we were
building based on that
limited reference manual we had.
It's not as good as a data sheet, but
it'll do.
And so with this, the Iraqi problem is
solved.
We know how to unmask Arcus, we know how
to acknowledge that they fired, but
one illustration as to how
source code is not as good as a reference
manual. All the Iraqis are off.
They're off by five.
For some reason, the spy interrupts
the hook, number 30, but it's actually
35.
The handler, they hook 18, but it's
actually 23.
I don't know why they do that.
But in our code, we actually use Iraki
23. And that's an important distinction
that we make. You can see that obviously
we're not just copying code, we're
actually interpreting it and making
it better.
So with this, we had enough to put a
basic Nadex, not a BSD
licensed. It's kind of a POSIX type
Alake type thing.
Osmo commissar's it for their phone
thanks to the general purpose timer and
the IQ, we have multitasking support.
One thing to know about this chip, it's a
really weird arm seven.
It's the only rs7 I've ever seen that has
an arm V5 instruction set,
but it doesn't have a core processor 15.
So there's no memory protection, there's
no cache, none of this.
So you can't run full Linux,
for example, but not X has no
problem with this.
And with all this, with an operating
system running with this code goal one,
I think it's basically achieved
so.
So we can run code, we can load code,
we don't have
a lot of features that are missing, we
only have partial LCD support, we don't
have automatic refresh working out.
But with interrupts, we should get that
soon.
We don't have a full spy's
implementation, but we can do things like
query the spy ID and the road
is there to get full spy support.
Audio support requires some DMA
that we're still working on. And there's
a bunch of other things.
Of course, Bluetooth and GSM, they aren't
on here, but they should be possible
to get working naked
under the point where we have all this.
It's great, but
we don't want everyone to have a novena
to use the Fernvale phone.
That just doesn't work.
So we need a better way to do it.
Now, the thing is, these phones are
really cheap and
they have to have a way to get the
software on there on cheap
commodity hardware.
And the solution there is to use the
factory flashing tool.
This is very easy to find.
This is the easiest software
to find just because it's used in every
corner shop to reflash the firmware,
to unlock it, to do whatever.
And it's also used to run this.
This particular tab is a memory test.
So you can test rame, you can test
nor flash, you can test NAND flash in
addition to just writing a new firmware
image to it.
And this basically starts
out the mediatheque default
that this is their boot sequence, it
starts in the ROM.
And if you have a spy attached because
the internal bootloader and then the
external bootloader and then it actually
loads the operating system, or if
you're in that corner shop or you're in a
factory, it goes from the ROM to one
be able to to build over USB
and then other ones master factory.
But we don't want you to have to pirate
and download the mediatheque software.
We think we want this to be completely
open.
So we came up with Fernvale
USB Loader based on
stiffing the traffic and we found a way
to load our own code.
And from that it goes from the ROM
either to the USB download or if you're
going over USB or directly to Fernleigh
and then load Nadex.
But there's a small problem
on you previously.
You end up going through Interpol or one
bill, and the purpose of these is to
set up the clocks
and the RAM because when the ram comes up
and it's calibrated in the RAM doesn't do
that. So we have to do that in
our Fernleigh system.
But the thing is, that's really
complicated proprietary stuff.
And we've never seen any reference
manuals that talk about the calibration
sequence. And I think the only reference
we have for calibrating the memory
and turning on the clocks and powering up
everything is in the source code.
And you can't just release the source
code because that's that's a huge
copyright violation.
So because we don't have reference
manuals with this and we don't want to
ship everyone the internal bootloader,
how can we set up the chip at Bhoot?
And so we ended up coming
up with a solution that Bonnie mentioned
earlier, the scripting language,
it's a very simple command language.
It's kind of similar to the way most
system on ships like your phone when it
turns on, it has to have a set
of scripts that calibrate the particular
RAM ship that's paired with it.
And they have a series of POCs.
They're just polke values in a memory
and script is very similar to that,
except it runs on the CPU after it's been
booted.
And using this, we could just still
Faxton into scripts because there's only
really one way to set up the RAM
and that's a fact.
Scripts are explicitly not Turing
complete. It's just a series of steps to
take. We don't have any if then else
we don't have any jumps or anything like
that. But you can call CI
functions from script scripts.
So in that sense it can be considered
Turing complete.
This is required for the RAM calibration
because it has to keep trying values
until it finds one and then it averages
the two values and it's just
implemented as assembler macros and run
through GTC.
So we have just a few few commands
here.
Read 32, right, 32, 16 that reads
you sleep. That ends up being really
useful.
And this is what the actual
file looks like. This is a script script
that just starts to set up a memory.
You can see it's writing the value to to
remap the memory and then it's writing
some other values to the very end of RAM.
This is a special command sequence that
each leadership has to actually get
included.
But the important thing to note from this
slide is that you can send different
values to the RAM.
This just gives you an idea of how it
works,
a script it can call
functions. I mentioned that earlier.
This is the actual code to calibrate the
ram as well at Pascal's
Calibrate Ram with to return
zero and then continues
on its way.
Another interesting thing here is that
there's commands and
what it will do. It was a wait forever
until that values met and this happens a
lot of time in hardware.
You send a command, you say go do this
and then you wait for it to return
success.
Finally, because it runs through
a compiler, you can use include
files and for things such as the GPS
system where we do have a full manual,
you can actually use that masks and
you could be more explicit in
what you say. So if we have more
information about the chip, then you
get better scripting scripts.
If you have just constants from the code
you're using as a reference,
then you're going to just get constants
like we had before.
So you can use a bit mask's, you can do
or and all that, and you can
assemble it together and it will just
work. So.
Yep.
And so Sean, going
ahead and kind of gave an overview
of sort of what
we had done up to this
point in time and sort of some of
the mechanisms that we had used
to go ahead and address some of the
IP issues that we encountered head on.
So hopefully at this point in time,
we now have a draft process
for translating this sort of Shanghai
China style IP into something that's more
clean, licensed open Western
IP and the basic
processes we get documentation
and other examples from public download
to reverse engineer it out of the
existing code base.
We work within the fair use framework
based upon the rights that are available
to everyone. You know, at least I mean,
I guess it is US law.
So I don't know what is like out here,
but, you know, we hope that it's it's
a it's pretty similar in this in this
area.
And then we go ahead and we create this
framework to help avoid this problem of
sort of subconscious plagiarism, this
problem where, you know, particularly
good coders can go ahead and read a piece
of code essentially committed to memory
and just blotted out exactly the right
way, you know, an hour or two hours a
week later or something like that.
And so by going ahead and
looking at one piece of code, plant the
facts and re re expressing
it in the terms of these assembler
macros, we go ahead and
create a mechanism to go ahead and
discipline ourselves to avoid the
subconscious plagiarism.
And so we're at now is that we have this,
you know, an open platform that's
compliant to sort of the Western
standards. We have the system
that consists of three boards.
We have an example with us up here,
know consists of the main board, the
expansion board, the analog front end
schematics and layout are licensed, you
know, sort of biase
with an Apache rider for the patents.
It's a perfect license.
But, you know, we're continuing to work
on trying to find the right license for
the sort of stuff. But it's an open
license.
We have a custom bootloader flashing
tool. So if you want to go ahead
and develop for this, you don't have to
actually, you could stay completely
within your open framework.
Download are the open source
code for the for the bootloader download
a toolchain which is just Klingner GCSE
and you can also boot your
OS, which is not X.
So this is in contrast to
what the Shandi guys are doing, which is
they're taking the mediatheque IP
directly, copying the reference designs,
tweaking it, running the nucleosomes,
which is from what, mental graphics or
something like that. Right.
And in compiling it, using proprietary
compilers and so and so forth.
So we've managed to go ahead and take
a lot of this IP from this
ecosystem and hopefully bring it into an
area where people who,
you know, don't necessarily want to get
tainted with all of the Chinese stuff can
go ahead and start playing with it and
start developing with it and hopefully
innovating with something that is pretty
interesting and relatively cheap.
If people here are interested in playing
with the hardware and so forth, we
actually have a couple dozen
boards around here that we're willing to
share with people who have a genuine
interest in playing with.
So just come find us.
We're sitting with the failover
group in the back and the
big hall in the back.
And we would love to sort of engage
with people here and try and expand
the project further.
And also, we'd like to extend a special
thanks to much for enabling
our research again this year.
We appreciate that.
And thanks for your attention.
We'll take questions.
And if you want to play along with those
our Twitter handles, you can find us
typically through there.
Thanks.
We talk fast.
Wow, that was awesome.
Great talk, guys, thanks.
Great work.
Um, are there any
questions either from
insights from the Web?
So you are first, please go
ahead.
Since Linux can run on emulous
systems. So what is still missing for
running Linux on that device?
Question is what is missing from Linux?
I actually do have Linux.
You see build going.
There are a few things that are missing.
One is it's an ARM seven with
an RMV five instruction set and that is
the kind of thing that in general isn't
supported.
So you need to build
it with an RMV five type
build without any of the core processor
stuff. So that's doable.
The problem is the kernel was about
a megabyte and for whatever reason, the
loader that I had just died after about
800 K, so
eventually it should work.
Anything from the Web?
Yeah, so the I.R.S.
is asking, is this only for the
empty 60 to 60?
How well does your works for a similar
MEDITECH chip, for example, empty
six to twenty seven?
OK, the question is, is this specific
to the six to 16?
Does it apply to other mediatheque chips?
So there's
two parallel paths we're exploring here.
One is, of course, the specific instance
and the other is a methodology that we're
using to try and reverse engineer.
The methodology, of course we apply is
not just the phones, but broadly to other
things you might want to try and look at
from these ecosystems.
The port itself is, of course, specific
to this hardware. But as we had noted,
there's lots of docks and a lot of shared
IP between the blocks.
So it probably targeting another system
would just be a matter of rewriting
the few drivers of change, particularly
the interrupt controller and maybe a
couple of addresses. But it should be
read targetable to other platforms.
A little bit of work.
Number four, please.
I was wondering if you have any comments
about contributors to the project
or similar projects
about maintaining the reverse engineering
methodology when you're getting patches
and things like that?
Yeah, I mean, I think that.
So he's asking about what?
About contributors to the project and so
forth. Probably is as if people start
contributing.
We're going to have to do a review to
make sure people aren't doing copy and
paste if they happen to find a code
that is they're not adhering
to methodology generally.
We think that by putting this cryptic
method in there and sort of saying, OK,
if you give us a C function for doing
the initialization, there's a lot of risk
of of some sort of arrangement.
But if you go ahead and recode it into
this sort of macro language, I
think it helps with it.
So we will do a bit of review to try and
make sure things are fairly clean.
But that is that is an issue we're going
to have to address as the community grows
around it. Thanks.
Number six, please.
Hello. OK, first
I want to say thank you for your Novita
project because this is probably getting
me started in hardware hacking.
So, OK, and the second
question is, how does
this Chinese ecosystem
actually work? I mean, if you have a
layer chip like that, how
does the development process go
for building a three dollar chip like
that?
He had it. He had a question, General,
about how does the Chinese ecosystem
work? And that's almost another
entire talk in itself that
we probably had time to go into the more
of it. But
it's it's interesting that so
the Western ecosystem tends to have this
what I call a broadcast view of IP.
We have strictly.
Can you speak a little bit louder,
please? I'm sorry.
The Western kind of IP
ecosystem has a view of
what I call broadcast view of IP,
where you have clearly defined
holders of the IP who then broadcast
it to the world and then you pay a
royalty back to me or obey my license.
And the Chinese ecosystem
is a little more what I call a network
based system where you have
contributor's, but they all have to rely
upon each other and so they all tend
to trade IP back
and forth. So it'd be like I have
a specialty and circuit board design.
You have a specialty in plastics
and tooling. You have a specialty in
the OS stack and
as favors to each other, we go ahead and
just trade it IP back and forth
and this sort of propagates all the way
into the supply chain and getting the
bits and pieces. So when a new platform
comes out, typically there's actually
the best I can tell. It seems there's
people from the inside who
kind of look the other way and see the
ecosystem with some references.
Those people get into the network and
trade favors with other people and they
eventually build a whole phone together
for relatively low cost and
a very rapid development cycle.
OK, so it's actually more effective,
Eco-System, you could say, yeah, I mean,
it would be as if everyone here didn't
have to worry about the IP laws
and we just talk to each other honestly
without having to be like, well, you
know, I'm under NDA and this is really
cool tool. I can't tell you.
But, you know, whatever that kind of
thing, it's like we'll just tell you this
stuff and we'll work on it together.
Right. That's kind of what it is.
So Christian answer.
Yeah. OK, thanks.
Anything from the web.
Yeah. So another question from the IFC
is if MEDITECH is using Linux,
shouldn't they share the sources?
So the question from the Web is that if
mediatheque is using Linux, shouldn't
they share the sources maybe to be clear
for those low end chips?
They aren't using Linux, they're using
a proprietary OS called nuclease.
And so because it's proprietary, you
don't have to share the source.
Some of their Android phones do use
Linux, for example, but those
are shared.
And actually a lot of their Android
CPU's do use the same IP
blocks as these mobile phones.
And so the Linux
source code can be a source of
documentation, just like the MTA
11 B source code that we got.
So you can use Linux drivers as a
reference when you don't have access
to the original PDF docs.
So I have another issue here.
Could you please be more quiet,
walk less around, be more
quiet because they do an awesome job.
They did a lot of research and
a lot of interesting questions.
And it's very difficult for for the other
ones who want to to learn something
to to attract.
Um,
also.
Number one, please, how
would you recommend sourcing hardware
for projects like this, I mean,
immediately, can we find a
lot on Alibaba to order
to the US?
But long term, how can we get
the vendors to actually sell hardware
into our market, into the market?
Right.
That's that's an interesting question and
something that we'll need to be
played out. He is asking basically, how
do people out here get access
to the hardware?
So, of course, there's an entire
ecosystem in China for handling this
because people build not only
development runs iPhones, but like one
hundred thousand million unit runs on
their phones. These mediatheque chips are
selling at a rate of like a million a
month or something ridiculous like that.
Right.
The vendor that I went to, I
just walked around in the kind of open
air market there, and I was like, hey,
can I get one?
You know, the chips, like, no problem.
Can I buy ten thousand chips?
Like, no problem. Just give me like a few
hours to go to the warehouse and grab it
for you. Right.
And so
the ecosystem is kind of different from
this key lead time
world.
It it's not flawless.
Like for example, in the fourth quarter,
the demand is very high for the chip.
And so I couldn't find anyone who could
sell me spare chips in the last
couple of months, except for some people
who are selling. Some seemed to be some
rebound chips from taking off of other
phones and so forth.
So I think I think that as
we move forward, we can probably find
some vendors who are willing to sell it
and kind of we can share the information
and maybe find a way to get more of
it into the hands of people here.
But that's you know, that's something we
need to figure out for sure.
So it worked for five seconds.
Please, everyone who comes in,
I know you want to hear the next talk.
Please be quiet, move
quiet and everyone will be happy.
You say no to peace.
No question about this cryptic
language.
I got that right. You made that a
interpreted language instead of computer
language.
Why is that so?
And interpreted language instead of a
compiled language.
The idea was that it
would be easy.
Well, it's not quite interpreted
either. It's interpreted simply
macros like could compile.
Yes, go ahead. But it's a bitstream.
Yeah. And it could
could have been one way or the other.
It just happened to work out that it
seemed to be more it
seemed to lend itself more to a
interpreted language than a compiled
language. So it just happened to to end
up that way. Also a lot of
the CPU's that we were kind of
trying to emulate, when they do
boot time initialization, they tend to
also have a kind of an interpreted
language. So if they're doing it for
that, it seems like it's a good thing to
also try to emulate.
Thanks.
Yeah, another
thing, the angels at the Doors, could
you please limit the the stream
of people if it's too loud,
it's too noisy, it's too much walking
around. We still have ten minutes left
for this talk.
There will be a break after this talk.
Then you can move, you can move freely.
But now for this talk, please
be a bit more quiet.
So I think
number four,
thank you very much.
I have one question.
You're the guy that
built a laptop for himself, the
movie, not OK.
I was interested in one particular
part of that laptop, namely the battery
controller, and
yes, sure,
sure.
Actually, I
tried to build a laptop myself,
kind of succeeded on.
The worst part
right now is the USB power pack,
which sucks.
You can't use it and charge
it at the same time.
Yeah.
So I would like to have a replacement
for that. And I know that there are cheap
chips that do that because that's one
in every laptop, but you can't
get those.
So my question for you
is when when you made
the Nubeena parts and those
kits available, why didn't you
include an option to just
buy the battery board?
OK.
He's talking about the way that
I think the short answer to that is we
didn't actually think anyone wanted it.
That was his idea.
Yeah.
And after we had launched the
campaign, you just can't change.
We couldn't change the pledge levels and
whatnot. And so probably
I mean, this this will come out later on
in backor updates and stuff, but probably
will we we'll figure out a way to address
the community needs and and
also, of course, everything's open.
And so there's actually people who are
like building their own boards and maybe
they'll start selling them to you as
well. I mean, like, there's a lot of it's
open. Right. So I think the community
will figure out the demand or
hopefully figure out the demand is
necessary. But we also try to meet that
as well.
Also, yeah, here's
a battery controller as well.
This will do three point seven single
cell. So that's another thing that you
can use this for, for three dollars.
So, well, not only for your
laptop, but if you need one cell, right.
Yeah. It's also pretty good to get better
controller for three bucks.
Yeah.
Anything from the web.
Yeah. So another question from the I.R.S.
is, is a Paul Airport really
Nida's are two layers enough for a basic
functionality since you won't need
to throw out the extent of the RAM.
Um yeah if you wanted
to.
I think you're talking about the base for
it here.
If you wanted to build a really, really
basic version of this mediatheque
Chip, I've seen
people who got really cheap and got away
with two layers, but you might have some
power integrity, signal integrity issues
and also you would have to use a design
rule, geometry that's so thin
to root, you know, traces between the
balls in some areas and the drill size to
be so small that it actually will offset
the cost.
It turns out for layer boards are so
cheap that at least
in the world that we operate in, there's
like almost no reason not to use more
layers in a
design. It just makes makes things
easier, more better yielding.
So
great.
We have so we have
the two, we have the one.
And number six is
someone saying sending at the six,
please audience.
Be quiet in the background.
It's very annoying.
Thank you.
Number one, please.
Yes.
I thought you showed a little bit about
the multichip package and there were
actually four days in there.
Do you know a little bit more about those
individual dyes are already coming from
several manufacturers or several
styles?
Yeah.
So I would
if I can find that slide and pull it back
up again,
it's actually kind of kind of pretty neat
thing that I didn't know if I had enough
time to walk to talk through
Jesus.
Anyways, I have to go all the way back to
it's like basically the
if you look at the outlines of it and you
count the number of bond wires going
between different chips, you can actually
call out which one's the DRAM chip,
which one's the CPU chip, which one's the
analog front end and which one is like
the spy EPROM by kind of counting the
number of wires going between chips.
So you get a sense that they're the
reason why they broke it up as they broke
it up on the basis of the number of mass
players involved in.
Oh, thanks. Thanks, John.
So, yeah, if you if you look here, for
example, on the bottom, you see a bunch
of bond wires going into a rectangle
on the bottom. If you count it, you can
actually see a sixteen bit bus going
through in the bond wire and say that
must be the DEVAM chip in the bottom, the
little ones, the CPU, the top ones, the
analog front end and the lower right hand
corner seems to be some double
EPROM chip in there.
Right. And and every time
there's a trend lately of putting
everything on one chip and in order to
do so, if you build really good
transistors for CPU's, it turns out
they're not great for analog.
If you build really good transistors for
DRAM, it turns out the bad for everything
else. And so what you end up doing is
multiple diffusion and multiple
transistor types and that cost really
adds up. And the other thing that you
really want to do in these chips is
because the models change very rapid.
You want to be a celebration with more
delaminate for a rÃªve
or something like this, and you don't
have to pay for a whole Masset.
So essentially what Mediatheque has done
is developed this competency in
wire bonding and doing it extremely
cheaply and sourcing all these
separate components from different
vendors and essentially
pushing them down to a specialty supply
chain and then wrapping together into a
single system. So if you look at some of
the other developments, like there's a
there's a chip called the
empty K twenty five or two, which is used
to link at one, it looks very,
very similar to this one in terms of spec
wise with a couple of the features,
probably same courtships,
different wire bond, different package.
They can just do SKU variants all day
long. So
it just takes place.
You mentioned that there are
some chipsets for GSM
and Bluetooth in there.
Those tend to utilize some
firmware.
What do you know about these
when you take that one?
I've only just begun looking at
Bluetooth and the GSM stuff.
So the question is, what do we know about
the Bluetooth and GSM stacks?
I do know that there is a function that
is called Gorm
Empty six two six zero and
it which appears to initialize the
Bluetooth stack. I haven't found
what where that function is located and
what it does.
So there does appear to be some sort of
firmware that gets loaded onto this
separate arm core that drives the
Bluetooth.
That'll be interesting to see what
how extensive that firmware is and
what is needed for it.
As far as the GSM stuff,
I've seen the controls for the layer one
stuff, the layer one control.
And that's not terribly complicated.
As far as the layer two and layer three,
I haven't found that. I haven't looked
for it.
We don't know at this point.
We just don't know how difficult
it will be to get GSM working on this in
a manner that is complementary
to the open source ecosystem.
Right.
And number two, please.
My question is regarding the catalysts.
I understand that you tend to use term
for obvious reasons.
It's it's more appropriate
for things like the Nubeena.
But how do you see
using the collaboration between
people who might not have access
to to Altium and may use kickout or
can you go?
Well, I'd actually love to answer this.
One of the guys in our forums has
actually written a series of Perl scripts
that convert from Altium to Kickett.
And so it actually we have
this working with the Navina, and I've
done it with our battery board as well.
I'm sure it would work with Fernvale as
well. It actually does a pretty good job
of converting the schematic files and the
PCB files.
And right now, who's working on doing the
3D files, using the free card?
So there is it is possible
to open up the files that he
produces in Altium on
the arm Navina in cokehead
and view the nets and you can actually
get the schematics. And it's really
useful for me who
uses a Naveena.
And sometimes I need to probe a
particular net to now with this tool,
I can actually do
that, highlight the net and figure out
where to probe it. So Kickout is
definitely possible with the Nubeena
files these days.
OK, thank you, Craig.
We have one and a half minutes left.
Is there something from from the net?
So there's another question from the IAC.
Do you plan to kick start or something
similar for developing off the boards?
What do we kick start or are we
going to kick start something?
I don't know. That's that was an
interesting question that we we
we toyed with the idea.
I guess the question is really,
are people really interested in this sort
of stuff? We we did it because we're
personally very interested in it and
we're presenting it here.
And I guess will, based upon
the coming days and the feedback we get,
if if there isn't a lot of developer
interest, we'll make it, you know, like,
for example, do a Kickstarter
crowdfunding campaign around it.
But if it's still just a smaller group of
people and we can sort of manage
just by, you know, just seeding
the community with boards and stuff that
may be a cleaner and easier way to
proceed. We already have like two
campaigns right now, so we don't want
a third one at this very minute.
Great. Thank you very much for listening.
A big applause for the two guys
for the great Rivers's.