 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 the engineering various base bands, 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. It's a super cool place with lots of... I mean, it's a kind of place where you can go up to a shelf and sort of just buy tape and real resistor, like you would buy fish or meat at a store or something like that, so it's a hardware guy's paradise. And we found a phone there, a complete GSM phone that can do calls, called Band, Bluetooth, OLED, and it's $12, you know, full stop. This is not with someone discounting or subsidizing or some contract on the backside. 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 it had this 260 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, you know, 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 80 mega with the 8-bit CPU running at 16 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 aren't there series of talks at places like this about people building stuff with this sort of hardware? And so we say, okay, 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, you know, find the CAD files in an editable form. You can find the ORCAD schematic files, just like you can get the CAD 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 in these phones. It's a 7.5 gigabyte source archive. You can just download from Baidu and, you know, you could kind of do what they call the Shanzai thing out there, which is building your own phone. The question is at the end of the day, 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 and, for example, read carefully, there'll be confidential notices all over the data sheets, or if you look at the schematics and so forth, a lot of them don't even have a copyright notice. 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 Shanzai. In fact, there's sort of this view, if you read some of the comment threads that people have about various Western innovations and stuff like that, you'll see people being like Western IP law is unethical, these drug companies are overcharging for life-saving drugs. This $20 IP burden for mobile phones or $30 for DVD is basically rich companies stealing from the poor. We came and put rice on our table, and we worked so hard to essentially, they call it making cabbage, 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, the enforcement of laws is kind of subjective and selective out there. But it's not like this has 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 environment is 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 liked skeletons, 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. It's a skeleton on the inside. It has a skeleton-themed 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, MediaTek 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. It's a huge barrier. I mean, people out there in China don't have a quarter million dollars to drop on a potential IP license for something. 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, right? 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 that are accessories to our smartphones. You 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, but iPhone's not included, right? That's sort of state-of-the-art right now that's happening over 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 legal stuff comes out. Of course, the standard disclaimer, we're not lawyers, right? We're not giving you legal advice. We're going to share 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 that 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 CFAA, about accessing servers and so forth, contract law, patents and so on and so forth. It's a very complex innovation. It won't go very deep into them, but sort of touch on the surface. It has a great fact on this called the 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 Shanzai 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, FICE v. Rule, where sort of they was a suit 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, like that will be presented in the datasheet, 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 with the registers are also facts. So when you say set of the PLL by writing this data to this register, that's a fact. That's not copyrightable. We can go ahead and understand those facts and re-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 datasheets, the binaries and the codes. We reduce them to 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 we'll go into later on that will help us avoid this. This is sort of a preview of the pseudocode language. On the left is sort of what the C code looks like that you might find if you were to look in sort of some of these code databases, pages and pages of stuff and we just turn it into this list of facts that is on the right-hand side for example in this case initializing the PLL. 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 binaries were kind of in play text, there's maybe some SHA-1 checks but that's not an access control, that's just a verification of the context. There's some question about things like contracts and CFA, 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 in the U.S. law for doing that but the good news is all the stuff you can just sort of do a search query, download from public servers, so I think we're clear there and we also, these phones came with no shrink wrap, there was no like cut here and wave all your rights, there was no like click here and okay to accept terms of use on all these phones so basically there was no point at which we could have waved our rights to reverse engineer as well in this particular ecosystem so that's also good news. So at the end of the day, is what we're doing legal, I don't know, I mean like we did some research, we asked some lawyers and we want to avoid running a file of the law but it's impossible to be 100% 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 parts is that if there's no lawsuit 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 the 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, but people here for example watch their movies or their laptops with codecs that have patents on them and this is a whole gray area of who's responsible for what and no one really knows what's happening there. But basically we don't think there's going to be any problem in that space but maybe someone will have a claim against us and we'll find it later on. And we're okay with that. So now that we feel that we have the rights to do this and the ability to do this 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're like groping in the dark and thinking we're going to build this little project which we use, should we use an AppMega or an STM32 or should we use like a Kinetis, the 6260 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. And at that level the level of bar of functionality is not to the point where we want Bluetooth and GSM going and 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, a hard run 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 6250 or using 6260 to future proof our work a little bit. These chips do cycle rapidly through the market. They're around for about one or two years before they go away. We figure it'll take about that long for us to make some progress. It's got 364 megahertz CPU so it's a little faster and it also has 4 megabytes of nonvolta storage on chip. And here's sort of an interesting aside about the chip. This chip you can buy for $3, a single quantity. Like I said, you can go to those markets where they have reels and they say, hey, I'd like, you know, 10. Give them money and just walk away with it. It has multiple ARM cores, 8 megabytes of RAM, 4 megabytes of WEPROM, Bluetooth GSM, battery charger, audio codec, touch screen, so on and so forth. How many chips do you think are pieces of silicon are inside this chip for $3? Like who thinks there's one piece? Slow cost, right? Two pieces, three, more. Interesting. Well, I guess maybe I set it up. So we took an x-ray of the chip sort of before we got really into it because we want to know, for example, we're getting real chips or fake chips or what's going on the inside. And if I had a laser pointer, I could go ahead and point to this. If you look at it, you can see the outlines of bond wires in 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 $3, they actually build a multi-chip module, bond it all together, pack it up and sell it to you, full-width ARM core and all these bits and pieces. It's really quite amazing technology. So, gone over that. Here is sort of the system diagram of what we ended up building to base our work off of. We built sort of a baseboard, a mainboard that just sort of has the UART and speaker, battery, camera, USB, microSD slot, Bluetooth, and sort of Arduino-like headers on it. And we go ahead and split off the GSM part, so the GSM front end, so that users have to make a bona fide choice about which GSM analog amplifier to use. And that way, hopefully, get the sidestep some of the emissions testing issue that you 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, the SIM card, the touchscreen hub from the LCD, because those things can be laid out in a much simpler two-layer PCB that people can design in Eagle, or 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.io is sort of this Internet of Things module. And they have this 24-bit pin-dip-sum, but we couldn't pack enough IO into this footprint. So the actual implementation, and we sort of show it with an Arduino to show scale looks like this. This is the actual main board. The single chip on there you see is the 6U60, 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 UI and so on. So it kind of looks 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 what you want to build it to be. The design process, I mean, was pretty standard for 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 of what everything was. We did no copy and paste from the reference material, so everything was redrawn from scratch. 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 buzzed it out to different connectors and did some comparisons to other designs we could find on the internets. And so this is what the schematics end up looking like. We should have a link live now publishing all of the 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'd like. So that's the hardware platform. And then there's a whole question of how do we get the firmware on it? We can't go ahead and just very well say, how do we get the size just to download like the MediaTek compiler and all the source code and build it, that would be kind of lame. So we, of course, had to do a bunch of things like, for example, figure out what the boot process was, figure out where the things are. So we always start by pulling off the ROM and dumping the ROM. We found this little, it looks kind of like an iPhone. It's like a little tiny iPhone, size for contrast. Right? It's called the MP4 Terminator X. You take it apart. It has one of these chips on the inside. And this one had a separate spy ROM. It could just dump the data out of. The little static analysis. Some pretty obvious sections where boot loaders might be and some reset vector tables and so on and so forth. Did a bin walk. Found some stuff that looked like compressed 7-zip files. So the good news is basically there's very little stuff on here, if any. So it was going to be, not a walk in a park, but certainly accessible. Then we wanted to figure out sort of what bits were actually run first and how much was run inside the internal SoC boot ROM versus externally. So we took an afternoon with a tech scope and sort of figured out where things are going. I love the scope because, for example, if you see here, you can go ahead and take a capture. We're just pulling on and say, oh, that looks like probably spy data and that looks like spy data. And then we can go ahead and later on say, go ahead and interpret that analog data as serial. And so you can see in the science is in it done, OX 619, that's actually what's printing out of the port. But the scope is telling me that. And then actually right after you see the spy data start starting. So you know that there's a bunch of stuff that happens on the internal boot loader before the spy fetches happen. And then it tells you where the addresses are coming from. So you can see in the science lines here that the address fetches and the codes are going across the spy bus. So with this tool, we're very quickly able to sort of figure out where the entry vector is and what's being run 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. 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 a laptop called Novena, which is actually what we're using to give the talk on right now. We go ahead and we stick the phone inside our Novena. There's an FPGA in the Novena. And we go ahead and we build a ROM emulator for the spy ROM. Basically, this is the diagram of it. There's an FPGA. Then we go ahead, we just kind of man in the middle between the original spy ROM and the CPU, cut out the chip select line, take a 64K block of RAM, and go ahead and map that into the Linux kernel. So you can now M-map to what would be the code that's running on the live 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 desolder or do any sort of stuff. You do it in the sH in the box. You can be traveling and continue your reversing work on your hardware. So using this ROM emulator, we poked a bunch of regions, did a little static analysis of IDA, found some SHA-1 constants, and figured that there was a SHA-1 hash appended to the initial bootloader region. And indeed, just going ahead and manually recomputing the hash, sticking it in the ROM emulator, telling it to reboot and changing the screen, we can tell it, you know, say, hey, yo, food to yo mama. You know, bootloader finished, great. So handed over to Zobz to talk about some of the things we did next. So it's all well and good to manually modify and recompute the hash every time, but that's a lot of work. We're lazy, so the first thing we did was we took Rateray 2. I have no idea how you're supposed to pronounce that, but it's an open source kind of IDA equivalent that we could actually compile on the ARM CPU that is on Novena. So the Spy ROM is a 64 kilobyte window that is present within the Novena CPU space. So we got Rateray 2. We wrote a plug-in that lets us treat that area as the file that is being read by the disassembler. And what we did was we had it load code in, and every time you modify a byte, it would recompute the signature and reboot the phone. And so when we're doing this, we can actually do an assembly dump and disassembly and see what the live code is. And because we've recomputed the hash, the phone will actually execute the code and load it, and based on that, we can begin a reverse engineering process in figuring out how to get software running on the phone. Now, in our searches from earlier, Bunny 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 could see we have the keypad scanner, we have the GPIO blocks, we have the general-purpose timers, which are going to be necessary for the system going, and we have the serial UART. 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 at the zero address is, looks appears to be RAM, address 1,000 appears to be the spy chip that we're executing off of, so all of our code is going to be referenced to relative to 1,000. Then there are a lot of question marks. We know there's data there. If we write 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 there are the two UARTs 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 fairly nice documentation. And I think that they actually release this because it's a useful port to use when you're building Sean's iPhone like this. So with this information, we start developing what we call fernling. It's our fernvale command line environment. It has the basics, it has peak, it has poke, 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 into git to search for various patterns for various blocks. Now the one restriction is that this bootloader must fit the EXT bootloader, which is fine because it's fairly small to begin with. So first up, we're going to figure out the UART. We're going to try and get the driver for the UART working. It's the same UART that is in a bunch of other media tech phones. It's the same UART 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 reference manual we had. And there were drivers for Linux that we could look at. It doesn't require any interrupts, which is great. So based on this, we're able to get put care on git care, and with that we can get a whole shell going. Next up, GPIO. Also very easy. You write a value to a register, a light turns on, you're happy you go home. It doesn't require any interrupts unless you want to get a GPIO button, which is great. Not very useful at this point, though, unless you want to turn the light on. That GPT, the general purpose timer, you need that for the periodic tick for multi-threading, multi-tasking, 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 needed interrupts. We couldn't find any way to get interrupted. So on ARM, there's one interrupt. What happens is an interrupt fires, it jumps to offset 24, it jumps to interrupt handler. That's standardized. That's standardized across pretty much all ARM chips. The problem is we had earlier documentation, but each VDT chip is different. We had documentation for the MT6205 and we had documentation for the 6235. That's the one that Osmocom has been worked on in the past. And if you look here, first off, you can see that they don't actually give you the complete offset. CIRQ plus 0014. They don't tell you what address CIRQ is. And these two are also very different. You can see that one of them is 16 bits, one of them is 32, one of them is at offset 14, the other one is at offset 38. They're similar enough, but they're completely different. So we couldn't use these to actually figure out what the interrupt block looked like. So we're going to try and analyze what we have already. Locate the boot ROM in the phone and dump it and figure out how the boot ROM does it. Try some more in-depth static analysis of the spy ROM that we pulled off of the phone. Try and analyze that with IDA. 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 to see if we can't figure out something from these manuals for the 6235 to the 6225 or the 6205. In all of our static analysis, we did find this function in ROM. It takes an integer, a pointer to a function, and a string. It's always called the 30 and then a function. So the first one is where they're calling actually this is what's installing the interrupt handlers. And this is actually really great because it lets us figure out how the mtk13 is actually the spy handler. It doesn't tell us how it installs this because there's some indirection that's going on, but it's actually not a bad first step. So let's get back to that file that Bunny mentioned earlier, the mtk11b.1308. It's a great naming scheme. It's customized to the mt6262 and it's the source code for the entire operating system. And the nice thing is that the IRQ exists in the source form. So you could look at this file, this cirq.inc.interctl underscore mt6260 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 regbase.inc which lets us figure out it lets us remove all the question marks that we had in that memory map that we were building based on the limited reference manual we had. It's not as good as a data sheet but, yeah, it'll do. And so with this, the IRQ problem is solved. We know how to unmask IRQs, we know how to acknowledge that they've fired, but one illustration as to how source code is not as good as the reference manual, all the IRQs are off. They're off by five. For some reason the SPI interrupt, they hook number 30, but it's actually 35. The GPT handler, they hook number 13, but it's actually 23. I don't know why they do that, but in our code, we actually use IRQ 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 port a basic NutX. NutX is a BSD licensed. It's kind of a POSIX-type, like-type thing. Osmo Commis is it for their phone. The IRQ, we have multi-tasking support. One thing to know about this chip, it's this really weird ARM 7. It's the only ARM 7 I've ever seen that has an ARM v5 instruction set, but it doesn't have a co-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 NutX has no problem with this. And with all this, with an operating system running with this code, it's basically achieved. So... So we can run code, we can load code. We don't have... There's a lot of features that are missing. We only have partial LCD support, we don't have automatic refresh working yet, but with interrupts, we should get that soon. We don't have a full-spice implementation, but we can do things like query the spy ID and the road is there to get full-spice support. Audio support requires some DMA that we're still working on, of course Bluetooth and GSM, they aren't on here, but they should be possible to get working. Now you get onto the point where we have all this, it's great, but... We don't want everyone to have a Novena to use a 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 particular tab is a memory test. So you can test RAM, 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, this is the media tech default, this is their boot sequence. It starts in the ROM, and if you have a spy attached, it goes to the internal boot loader, and then the external boot loader, 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 1BL to 2BL over USB, and then either runs memtaster factory. But we don't want you to have to pirate and download the media tech 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 downloader, if you're going over USB, or directly to Fernley, and then loads nutX. But there's a small problem. On previously, you end up going through intBL or 1BL, and the purpose of these is to set up the clocks and the RAM, because when the RAM comes up and needs to be calibrated, and the ROM doesn't do that. So we have to do that in our Fernley system. But the thing is, that's really complicated and proprietary stuff, and we've never seen any reference manuals that talk about the calibration sequence, anything. The only reference we have for calibrating the memory and turning on the clocks and powering up everything is in this source code. And you can't just release the source code, because that's a huge copyright violation. So 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 boot? And so we ended up coming up with a solution that Bunny mentioned earlier, the scriptic language. It's a very simple command language. It's kind of similar to the way most system monitors ships, like your phone when it turns on, it has to have a set of scripts that calibrate the particular RAM chip that's paired with it, and then it just pokes, that just poke values into memory, and scriptic is very similar to that, except it runs on the CPU after it's been booted. And using this, we could just still fax down 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. 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 GCC. So we have just a few commands here, read32, write32, 16-bit reads, useLeap, that ends up being really useful. And this is what the actual file looks like. It just starts to set up memory. You can see it's writing the value 2 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 DDR chip has to actually get booted. 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. Script it can call functions. I mentioned that earlier. It can also call code to calibrate the PSRAM as well. It pat calls calibrate PSRAM, waits for it to return 0, and then continues on its way. Another interesting thing here is that there's read commands, and what it will do is wait forever until that value is met. 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 lot of different files, you can include files, and for things such as the GPIO system where we do have a full manual, you can actually use bitmasks, and you can be more explicit than what you say. If we have more information about the chip, then you get better scripted 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. You can use bitmasks, you can do OR, so. So, Sean went ahead and kind of gave an overview of what we had done up to this point in time, and some of the mechanisms that we had used to go ahead and address some of the IP issues that we encountered head-on. Hopefully, at this point in time, we now have a draft process for translating this sort of Shanzai China-style IP with a more clean, licensed, open Western IP. And the basic processes, we get documentation and other examples from public download or reverse engineer it out of existing codebase. We work within the fair use framework based upon the rights that are available to everyone, at least, I mean, I guess it was the U.S. law. So I don't know what it is like out here, but we hope that it's pretty similar 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 commit it to memory and just blot it 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, point out the facts and 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 what we're at now is that we have this you know, an open platform that's compliant to sort of the Western IP standards. We have the system that consists of three boards. We have an example with us up here. You know, it consists of the main board, the expansion board, the analog front end, the schematics and layout are licensed, you know, sort of CC by SA with an Apache writer for the patents. It's not a perfect license, but we're continuing to work on trying to find the right license for this sort of stuff, but it's an open license. We have a custom bootloader and flashing tool, so if you want to go ahead and develop for this, you don't have to actually, you could stay complete within the open framework, download our, you know, the open source code for the bootloader, download a tool chain, which is just Cleaner GCC, and you can also boot your outOS, which is not X. So this is in contrast to what the Shanzai guys are doing, which is they're taking the MediaTek IP directly, copying the reference designs, tweaking it, running the Nucleus OS, which is from what, Mentor Graphics or something like that, right? And compiling it using proprietary compilers and so on 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 us, 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 Mudge for enabling our research yet again this year. We really appreciate that. And thanks for your attention. We'll take questions and if you want to follow up later on, those are our Twitter handles. You can find us typically through there. Thanks. We talked fast. Wow, that was awesome. Great talk, guys. Thanks. Great work. Are there any questions either from inside from the web? So, if you are first, please go ahead. Since Linux can run on MMU system, so what is still missing for running Linux on that device? Questions, what is missing from Linux? I actually do have a Linux program you see build going. There are a few things that are missing. One is it's an ARM 7 with an ARM v5 instruction set and that is the kind of thing that in general isn't supported. So you need to build it with an ARM v5 type build without any of the coprocessor 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 was about 800K. So eventually it should work. Great. Anything from the web? Yeah, so the IRC is asking is this only for the MT6260? How well does your tool work for a similar media tech chip? For example, MT62 27. The question is, is this specific to the 6U60 and does it apply to other media tech chips? 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 replies not just to 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 have noted there's lots of docs and a lot of shared IP between the blocks. So probably targeting another system would just be a matter of rewriting a few drivers that change, particularly the interrupt controller and maybe a couple of addresses but it should be retargetable to other platforms with a little bit of work. Great. 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 he's asking about what about contributors to the project and so forth. Probably as 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 code that is, you know, they're not adhering to methodology. Generally we think that by putting the scriptic method in there and sort of saying okay if you give us a C function for doing the initialization there's a lot of risk of some sort of infringement 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 an issue we're going to have to address as the community grows around it. Thanks. Number six please. Hello, okay. First I want to say thank you for your Novena project because this is probably getting me started in hardware hacking. So okay 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 $3 chip like that? Okay he had a question in general about how does a Chinese ecosystem work and that's almost another entire talk in itself that we probably had time to go into a little more of it but it's interesting that so the western ecosystem tends to have this what I call a broadcast view of IP where you have strictly Can you speak a little bit louder please? Oh sorry. The western kind of IP ecosystem has a view of what I call a 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 contributors but they all have to rely upon each other and so they will tend to trade IP back and forth so it'll be like I have a specialty in 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 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 looked the other way and seed 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 in a very rapid development cycle Okay so it's actually more effective ecosystem 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 Christian answer Oh yeah okay thanks Anything from the web? Yeah so another question from the IRC is if made a tech is using Linux shouldn't they share the sources So the question from the web is that media tech 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 Nucleus and so because it's proprietary they don't have to share the source some of their android phones do use Linux for example but those are shared Actually a lot of their android CPUs 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 MTK 11b 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 round be more quiet because they do an awesome job they did a lot of research and they have a lot of interesting questions and it's very difficult for the other ones who want to learn something to it works awesome 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 right that's an interesting question and something that will need to be played out he was asking basically how do people out here get access to the hardware so of course there is an entire ecosystem in China for handling this because people build not only development runs of phones but like 100,000 million user runs of your phones these MediaTek chips are selling at a rate of like a million a month or something ridiculous like that right the vendor that I went to found in the kind of open-air market there and I was like hey can I get one unit of the chip she's like no problem can I buy 10,000 chips she's like no problem just give me like a few hours to go to the warehouse and grab it for you right and so that ecosystem is kind of different from this Digikey lead time world 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 it seemed to be some re-balled chips from taking off of other phones and so forth so 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 out here but that's something we need to figure out for sure so it worked for five seconds please everyone who comes in now you want to hear the next talk please be quiet move quiet and everyone will be happy number two please question about the scriptic language if I got that right you made that an interpreted language instead of a compiled language why is that sorry an 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 it's a bit stream it could have been one way or the other it just happened to work out that it seemed to be it seemed to lend itself more to an interpreted language than a compiled language it just happened to end up that way also a lot of the APUs 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 another thing the angels at the doors could you please limit the in stream of people 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 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 are the guy that built a laptop for himself I was interested in one particular part of that laptop namely the battery controller and yes actually I tried to build the laptop myself I kind of succeeded and the worst part right now is the USB power pack which sucks you can't use it and charge it at the same time so I would like to have a replacement for that and I know that there are cheap chips that do that because there's one in every laptop but you can't get those so my question for you is when you made the novena parts and those kits available why didn't you include an option to just buy the battery board ah ok he's talking about the way I think the short answer to that is we didn't actually think everyone wanted it please I do and after we had launched the campaign we couldn't change the pledge levels and so this will all come out later on in backer updates we'll figure out a way to address the community needs and also of course everything is open there's actually people who are building their own boards and also it's open so I think the community will figure out the demand hopefully figure out the demand is necessary but we'll also try to meet that as well also here's a battery controller as well this will do 3.7 single cell that's another thing you can use it for for $3 not quite for a laptop but if you need one cell it's also pretty good to get a battery controller yeah so another question from DRC is is a four layer board really needed are two layers enough for a basic functionality since you won't need to route the external RAM um yeah if you wanted to I think you're talking about the base board here if you wanted to build a really really basic version of this Mediatek chip I've seen people who got really cheap and got away with two layers some power integrity, signal integrity issues and also you would have to use a design real geometry that's so thin to route the traces between the balls in some areas and the drill size would be so small that it actually will offset the cost it turns out four 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 things easier more better yielding so great we have so we have the two, we have the one and number six is someone selling at the six please audience be quiet in the background it's very annoying thank you number one please you showed a little bit about the Mediatek chip package and there were actually four dies in there do you know a little bit more about those individual dies that are already coming from several manufacturers or several synthesis tools so if I can find that slide and pull it back up again it's actually a kind of pretty neat thing that I didn't know if I had enough time to talk through anyways I have to go all the way back to the slide basically 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 is the DRAM chip which one is the CPU chip which one is the analog front end and which one is like the SPI EEPROM by kind of counting the number of wires going between chips so you get a sense that the reason why they broke it up is they broke it up on the basis of the number of mask layers involved in oh thanks, thanks Sean so yeah 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 16-bit bus going through in the bond wires and say that must be the DRAM chip in the bottom this little one is the CPU, the top one is the analog front end and in the lower right hand corner there seems to be some double EEPROM chip in there and every time there's this trend lately of putting everything in one chip in order to do so if you build really good transistors for CPUs it turns out they're not great for analog if you build really good transistors for DRAM it turns out they're bad for everything else and so what you end up doing is multiple diffusions of transistors types and that cost really adds up and the other thing that you really want to be able to do in these chips is because the models change very rapidly you want to be able to sell a version with more DRAM in it for a rev or something like this and you don't have to pay for a whole mask set so essentially what media tech has done is they've developed this competency in wire bonding and doing it extremely cheaply and sourcing all these separate components from different vendors and then wrapping them together into a single system so if you look at some of the other developments like there's a chip called the MTK2502 which is using the link at one it looks very very similar to this one in terms of spec-wise of a couple other features probably same core chips different wire bond, different package they can just do skew variants all day long number six please you mentioned that there are some chip sets for GSM and Bluetooth in there those tend to utilize some proprietary firmware what do you know about these? I've only just begun looking at Bluetooth and the GSM stuff so the question was what do we know about the Bluetooth and GSM stacks I do know that there is a function that is called Gorm MT6260 in it which appears to initialize the Bluetooth stack I haven't found 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 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 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 hi my question is regarding the CAD tools I understand that you tend to use Altium for obvious reasons it's more appropriate for things like the Novena but how do you see easing the collaboration between people who might not have access to Altium and may use CAD or Eagle 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 CAD and so it actually we have this working with the Novena 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 he's working on doing the 3D files using free CAD so it is possible to open up the files that he produces in Altium on the ARM Novena in CAD CAD and view the nets and you can actually view the schematics that are useful for me who uses a Novena and sometimes I need to probe a particular net and now with this tool I can actually do that, highlight the net and figure out where to probe it so CAD CAD is definitely possible with the Novena files these days okay thank you great we have one and a half minutes left is there something from the net so there's another question from the IRC do you plan to kickstart or something similar for developing of the boards do we kickstart something I don't know that's that was an interesting question that we we toyed with the idea I guess the question is really are people really interested in this sort of stuff we did it because we're personally very interested in it and we're presenting it here and I guess we'll base upon the coming days and the feedback we get if there's a lot of developer interest we'll make it for example do a kickstart or crowdfunding campaign around it but if it's still just a smaller group of people and we can sort of manage just by just seeding the community with boards and stuff that may be a cleaner and easier way to proceed we already have like two campaigns that we're running 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 reverses