 Hi everyone. I hope you can hear me. My name is Olexi Rempel. I'm working for Pincotronics. I do open OCD as a hobby, mostly reverse engineering and other funny stuff. So after some long enough experience with open OCD and sitting in IC channels, I decided to share some of my experience. I hope it will help you somehow and maybe you'll be inspired to explore hardware from JPEG point of view and who knows, maybe you will be someday one of a contributor for Open OCD project. As I started to create this presentation, I made some assumptions about you and, well, one of the first things was all of you have some JPEG experience and who knows, maybe you already used Open OCD. So it will be probably great time to check my assumptions and please lift your hands if you already used JPEG somehow with any software. Wow. Almost everyone. Did you use this with Open OCD? Great. I'm wordless. Okay. I do mostly things from wrong way, from wrong point of view. I do it mostly in reverse engineering way. So I'm learning this and so. And my motivation for learning Open OCD was Fryfund project. It is really popular in Germany. And, well, I did mostly reverse engineering of boot loaders or floor level initialization for different MIPS hardware. So this way was built this presentation. I will represent this as a reverse engineering project. With some reverse engineering experience, I made some rules for myself just to help me. What I do first is to investigate everything public, what is possible to investigate. For example, read standards, read available documentation. There is no always documentation. And search for patterns. The reason is why you need patterns is, well, most vendors do not create new things. So if you found somehow some way how some IP core is working, then you probably will be able to apply same rules on new, not documented hardware. And usually as you're working with some black box, then it is good to make some assumptions and then work in this direction to resolve these assumptions. Well, so, starting investigation, reading something about JTAG. Well, it is really old standard. It was started in 1986 as joint European test action group. And 1990, it was already finished. So I found some notes in journal of electronic testing, theory and application in 1991. This is called picture. It explains somehow how JTAG is working. And, well, most of you already know how it is working. And usually if you are working with open CD or JTAG, you are using some of paths in this chain. And most of open CD users using this part. So we are somehow debugging the context, the CPU or whatever. I decided to go other way and use open CD before the core of future of open CD. So we are not using code CD. We are going boundary scan. What is known about boundary scan? Well, it is old standard. It is still used. And at least people with which I communicated was not really knowing boundary scan. There was not much presentation, not much information about this. So I hope it will be interesting for you as well. First time it was documented as part of standard. It was 1994 as extension of standard. And it was added to main documentation in 2001. If you are talking about boundary scan, usually we need some sort of description language. It is boundary scan description language. It looks like this. I took this example from STM32. These files are usually easier to get from many vendors. But it is not always the case. Some days, sometimes some vendors do not provide this information for normal people, like me, hopefully. And I needed to reverse engineer one day one of Broadcom chips. So what if you need to create based data file by yourself, but have no access to it? Well, you learn how other chips are working. And what we can see how it is working well. We have some description for parts, for each part of some chip. Then we have more detailed description for supported TAP of this chip. So, for example, instruction length of this TAP, supported instructions, and ID of the TAP to which this is the L file was created. And, well, most important for these boundary scan work, you will need to somehow control pins. And this part describes each bit of boundary scan register. So, for each pin, we usually have three bits. This one, for example, describes the output for the input state. So you can read what is exactly, in which state is set this bit. You can control the direction of this pin. So you can set the output. And you can provide the output level to which this pin shall be set. Well, to apply all of this information, you still need to get somehow access to the JTEC port. And we'll continue here, from this place, step by step, first, get access to JTEC port. Usually, if you start using OpenOCD, you'll have two states. It's working or not working. On RC or mailing lists, we usually get lots of questions about not working things. I hope this will somehow help you. First, I will describe one of situations where you need some kind of close timings to get the access to your port. For example, most of all venous SSCs multiplex JTEC port with SD card port. So you just can build your kind of SD card adapter and connect it to JTEC adapter. And at some point, after power on, you'll get some short time with available JTEC. So how we can find these not really documented parts at which time after power on this JTEC will appear and how long it will be accessible. I created this setup. First, what you usually need is to somehow remote controllable power supply. This power supply, in this case, was controlled from OpenOCD. Then you'll need JTEC adapter, some logic analyzer. Here in this case, this SD card extender or SNIFA, we've connected to it JTEC adapter. From OpenOCD configuration point of view, you'll still need to apply some settings. For example, set delay after power cycle, how long OpenOCD should wait until it will send first signal, first commands. And in short window, which is available in this case, you'll need somehow squeeze all these commands, so you'll need to properly set the JTEC clock with adapter configuration. And if you have no idea how long it will be available, you still need to see if this pin, for example, in this case, it is test device input pin is configured as input. Because in SD card functionality, it will be output. And in this case, pull up resistors are usually really helpful. Here's the example. You can see, here's some difference. Here's before pull up resistors. Here in this case, all the time, all pins set to zero, and if we pull up, it will be set to one. Here's some of description. Here we get power on, and after some microseconds, we'll get a JTEC. And for this period of time, we have JTEC available. After this, the boot ROM will configure all of these pins to SDMMC functionality. And with pull up resistors, it is good to see. So we have about eight milliseconds to provide some commands. In this case, if you get this, you'll be able to hold CPU and all complete devices under your control. Then another example. In some cases, it looks like open season, you should send some pattern to open, to configure device to some JTECable mode. In this case, microchip provides really good documentation for P32. And in this case, this picture shows how ICSP mode should be enabled. It is kind of like CGTEC or two wire JTEC, which is enabled by this pattern. It means after power on, we should trigger a set, start clocking and provide some pattern. And voila, we have JTEC. Let's assume we are in. And sometimes it looks like this. We have multiple tabs. The days where we had only one tab are mostly away. And each tab has some kind of probably supported instructions. As we clock our data, it will be usually decoded by instruction decoder. And after this, we will go one of these ways. And sometimes we have, in good times, we have ID codes. Sometimes there's boundary scans. Sometimes bypass or whatever. So we need to find what we are seeking. We are seeking right now for boundary scan. And it is not available on every tab. As an example, let's take STM32. So in this case, we will go like this, find the right tab, find the right instruction and find the right bits to do all this boundary scan magic. Lucky me, in this time, we have documentation. And in this documentation, we have, you can see we have two tabs, which is needed. Well, good, it's documented. This is optional tab. It is enabled only in this case. If it's, if it's where the pair is not triggered, then we have, can see only one tab, which is needed for debugging software. But we want to go here. We can find here some information. It is a bit different from this one. It supports five-bit instruction. This one supports four-bit instruction. Well, enough information. We can compare this with one of BSDL files. And here we can see this BSDL file is for five-bit instruction. And if we compare ID register, then we'll hopefully see same ID like in this BSDL file. Usually, software should do this automatically, but we are doing kind of radius engineering. We do it all manually. So we are seeking for instructions which we need to execute to go boundary scan. And for boundary, we need three of these instructions. They all described here. Then we are seeking for the right bits. Let's assume we already can execute some how boundary scan instruction. I decided to take this part because it has already an LED connected on STM32 discovery board. So if we will play with these bits, 142, 143, and 44, then we'll be able to do some bit banging so we can just switch LED on and off from boundary scan and not like we usually do it from GPIO. So let's start with this. Paul provided BSL, the sales script with which it is easier to use or reverse engineer boundary scan register. And the following video, I'll show you how, as a proof of concept, first I will search for floating bits, floating parts, then I will try to do some changes and enable LED on and off, and then find, well, this script provides even a possibility to find correct bits. So if you set pull up or pull down register on particular part, you will be able to find if this script needed bit or bit responsible for this part. So starting, well, power on, starting on a CD, then usually we connect with telnet, with targets, we can, I list here only one configured tab, and up here now I start to configure the second tab, the boundary scan tab, with some of comments, I prepare search for floating parts, which is to avoid getting fast positive information, but they're still getting here. Here I connected the part which I am trying to research to pull up and then to pull down and scan again to see what is changing on this boundary scan register, and usually this script will provide two bits as information, one is which bit should be used to set to some output and which bit should be set to configure this pin. So up here now I start to change the state of this bit, I assume I got all needed information, so LED is now on from boundary scan, so it can change, switch it again to off and on, it's working. Great. What we can do with it? One of my colleagues asked, well, can we use it for testing? For example, if it's possible to configure from software, from, I don't know, bootloader, GPIO or set pins to some state and read it with boundary scan, will it work? Yeah, change accepted. Let's do this. In the next video, I show proof of concept, yes, it is working, at least with STM32. I will start JTAG, configure GPIOs just manually from JTAG, enable clock for GPIO, set GPIO to input and test if it's, if I get proper values from setting pull up or pull down resistor and then use boundary scan to read the value of this particular part. So same procedure like last time, power on, start upon OCD, so now I am working with actual OCD functionality of OCD and here I will write directly some registers, in this case right now I am configuring GPIO and here I am reading the input state of GPIO controller. Right now with pull up resistor, I will get here one bit set and with pull down, this bit will disappear, so there is some difference. It means I found correct controller. Now I will reconfigure GPIO to output state and change LED to enabled. Just one more test to see if it's really working, yes, I can control it. After I enabled it, then it will be time to configure boundary scan tab again, so it's configured and then I will just directly read, I already know which bit I need and here I read bit 142 and see, yes, it's set to one. If it will be set to null, it will get here null as well, so just to reduce some presentation time, I show only one case. Yes, it is possible, at least for some chips. To confirm it on different platforms, different windows, I tested this with peak 32. Well, I was not able to get all parts working right away because it is different. Most of the differences is we have here two tabs, there is a microchip tab and there is extended tab, which is more for MIPS tab. And only this tab is supporting boundary scan and some other features, like flash controller and so on, but this tab is not enabled by default and there is a vendor instruction to switch between these two tabs. So I decided not to spend too much time in this case. Let's assume it is not really working. Maybe yes, I don't know. Same test on MX6. The reason is one of the colleagues asked, well, peak 32 is interesting or stem 32 is interesting as well, but MX6 is relevant somehow for Linux. And no, it didn't work. As soon as I executed boundary scan instruction, the CPU was set to reset state. And this is good because in this case, you can't do anything wrong. I mean, to destroy your hardware by setting different values to the same part. This is also confirmed by documentation. You can see this reset controller is directly connected to boundary scan register. Since this presentation was to inspire you to research more, especially research hardware which we have from GTEC point of view, I want to show you how much to explore from GTEC side. This is MX6 taken from documentation, official documentation. And we have here a GTEC chain. And in this chain, we have system GTEC controller. This is one of the tabs. This is system GTEC controller tab. Then we have SDMA. We have debug access point which is connected to Cortex Online. And we have GTEC access point so we have even more paths to scan. Right now, with OpenSCD, we can do actually only this part. It is supported. All of other paths are not really supported or not upstream. So if someone has some time and want to investigate something new, you are welcome. For MX6 case, this part, for example, is responsible for actual kind of security. If you fuse configuration bit to disable GTEC or to provide here some kind of password, then it will block you from doing all of these interesting paths. Yeah. I hope it provides some information so you can continue with it. I applauded all of documentation and scripts which I use to this repository. Do you have any questions? Yeah. Can you please go here? So for the STM32 demonstration, is the GTEC very comparable to the SWD support? OpenSCD will talk to the SWD controller on those boards as well. In this case, to be able to access under scan tab, you should use GTEC, not SWD. Anyone? So from my experience as an OpenOCD newcomer, it seems it's quite difficult to get patches into OpenOCD upstream. There are some tools which are probably not familiar to some people. Is there anything you would like to improve about OpenOCD tooling to bring in more contributors? I'm not a maintainer to answer this, but I will try to talk with maintainers to improve this somehow. Okay. Thank you.