 Now, I want to announce the talk of Junde LeGray. He talks about reverse engineering a Qualcomm baseband and the question and answer session is at the end of the talk. So please give a wonderful applause to Guillaume. Hello everyone. So yeah, the topic of this talk is about reverse engineering basebands and especially in this case Qualcomm models So Well, just a few little intro about baseband, the baseband world. Well, for people who don't know what baseband is Well, the baseband processor is So it's a main chipset of your phone responsible for handling telecommunications and Everything over the year, it's interface to hardware and handles the protocol stacks for the telephony protocols So, well, most of the time, well, a lot of people have a smartphone which is capable of running a separate operating system like Windows Mobile, Android, iOS, etc But the baseband, the baseband operating system is most of the time Well, it's always hidden You don't directly interact with it. You don't have the hand on it So, well, the biggest suppliers of Qualcomm of the baseband chips or well, the leader I think is Qualcomm followed by Mediatek and Infinium Well, in fact, I just mentioned a few phones like HTC iPhone, but they are sharing the market across various models of phones So, well, this talk mainly results from an observation which in my opinion, the hacking phones it's something quite hard to reach for multiple reasons Not a lot of people are actually not like on PC, I mean interested in in France Because it's hard to reach. It's quite close industry The phone, I mean, the phone manufacturers don't disclose any specifications Every baseband model is proprietary So, on the system side, you see kind of a black box running like a purifying piece of code and link terrifying protocols Well, if you're just interested in the network side well, you go to the 3GPP.com website and then, well, it's very discouraging to say the least So, there's multiple reasons to look into basebands The main reason would be to understand how a phone really works because everybody is using phone nowadays and everybody has a baseband and, well, it would be kind of cool to know what's really running into your phone Another reason would be for vulnerability research Obviously, because the code base is very real like 20 years or much It's very big, the network protocols are very complicated so it has a good potential for finding vulnerabilities into it into them and also for sim unlocking, for example Well, so CGR has been prior works on baseband exploitation, for example So, one of them has been presented last year at 27C3 by Ralph Philippe Veinman who reported vulnerabilities in Infineon and Qualcomm basebands but there is no much detail actually on what is the environment the code environment of the baseband And in this context, I think exploitation is almost impossible Well, anyone who has done a little bit of exploitation knows that you need to know at least in which architecture you're running what is the operating system, the memory, where you can jump or not, etc. So, in this manner, there is a clear lack of literature about baseband Well, for example, last year there was this presentation about SMSOF where they took all funds, they deployed a nice fuzzing architecture with OpenBTS and they began to fuzz the funds just to see the result and as a matter of fact, well, almost all funds has crashed or break but there was no really exploitation behind this because people who were presenting this talk could not get the end on the system of the funds So, it's very interesting to know that you can find vulnerabilities in this manner but if you can't exploit them, you have to, at the very best, classify them as denial of service, whereas they may be exploitable and that's quite well So, about this talk, I will be presenting what I've done on a USB 3G stick which is a quite common 3G USB stick you can find on eBay or from your phone operator I will describe, so it's a Qualcomm baseband inside and I will describe the operating system running behind this and how it's possible to develop a debugger to do live debugging on the baseband which is quite necessary if you want to reverse the baseband and also find vulnerabilities So, well, maybe I'll need my stick, sorry So, yeah, so this is the stick actually In France, you can find this stick with France Telecom, orange, sorry which is the main operating phone operator in France I'm not sure this stick is actually working on American frequencies but they are closed models So, well, the name is an option stick It's an Icon 225 It's a 3G USB stick with a Qualcomm inside The Qualcomm model is MSM6280 You can find inside an ARM V5 processor and two proprietary DSPs for processing the audio signal and the modem data So, it's not the newest USB stick you find in, for example, on eBay or in a shop It's dating back to 2008 And, well, the kernel which is running inside it has quite evolved since this As far as I know and as I've seen now Rex is the name of the kernel in the baseband and now it's an hybrid kernel which is coupled with OKL4 which is a derivative, a proprietary derivative of the L4 PistaQ So, well, if you plug a new USB stick on your computer, what happens? Well, basically you have this emulated serial port of a USB which allows you to talk to the stick and passing 80 commands So, like, for example, 80 plus CPU equals 1234 to unlock the same And, well, the stick is only supposed to carry data, packet data over 3G In fact, it's only supposed to do this but the manufacturer has just taken the baseband of a full-blown phone and put it into a USB stick So, when you look inside it, it can also do circuit switch operations which means voice and such thing The only difference with a phone is that obviously you have no screen no speakers and no microphone and no GPS and such things Well, if you plug this USB stick in your computer you will see, in fact, three serial ports firing up The first one is used to pass 80 commands to the modem and also packet data if the serial port is multiplexed The second port is only used for packet data when the ports are not multiplexed And the third port, which is interesting, is a channel to a Qualcomm diagnostic task which is something which has been left by Qualcomm engineers to debug the baseband So, how to enable the diagnostic channel? It's very easy because, in fact, on this model it's directly accessible You can directly pass commands to the diagnostic mod And on some phones, I've seen you might need to send a strange AT command like AT or QCDMG to activate the diagnostic mod So, well, it's a serial port so you can pass data into it but there is protocol and the protocol is fairly simple It's not documented, obviously, because it's an engineering protocol from Qualcomm It has been partly reversed in the modem manager, if you look into the source There is a directory named libqcdm where you can find part of the protocol So you have begin and markers, one byte indicating what is the command and the variable parameters, like depending on the command, actually and a CRC So, there is a lot of commands in this diagnostic mod and actually some of them offers direct access to the baseband memory So, for example, the second command reads a byte in memory and the command 5 writes a byte in memory but there are like hundreds of commands So, from this, it's directly possible to byte by byte dump the bootloader at FFFF4.0 which is the entry point in ARM and you can also dump the whole system memory from 0 because it's loaded in memory There is also a second mod which is accessible from the diagnostic mod which is called the downloader mod It's a mod which is specifically designed to write a piece of code into memory and execute it When you enter this mod, you have only two commands available writes data and executes at address You can only write in an artcoded range of memory, which is quite small And, well, to get to this mod, you have to go through the command 58 of the diagnostic mod It's also enabled when the system crashes and on some HTC phones, like the HTC Desire Z, I think You have, when you boot your phone, you can hold volume up, volume down and power During a few seconds and booting, you'll see five vibrations If you plug the USB stick, the USB cable on the phone you'll see a serial port and this serial port offers the downloader mod So you can push data and execute in the baseband It's directly accessible, it's free But, in fact, you do not really need this since you've got unlimited written write access in memory with the diagnostic mod already But if you don't get this mod, you can try the downloader mod So, as I said, you can dump everything in RAM in the baseband So you've got some kind of a live memory snapshot of the memory, which is nice It's not actually a real memory snapshot because each time you call to read a single byte the task which is handling your request will have been scheduled by the operating system So the image you get might not be totally coherent but in practice it's fairly efficient And what is nice is that you can also do this by dumping, for example, a firmware upgrade and pass it into IDA Pro to look inside the system But with dumping the memory of the baseband you also get access to the BSS section, which is empty in a firmware upgrade obviously So you get access to the stacks, you have the backtrace of the stacks You have the heap, you have everything, any global variable in memory which is directly accessible with the write values into them So it's a lot of information actually, and it's very nice So the memory snapshot is 32 MB strong You can find the entry point by reversing the bootloader And it can be directly passed into IDA Pro And well, from this point you can also already see some system characteristics Like all tasks share the same address space You can quickly find where is the page table And see that the first, I think it's 12 MB of memory or marked as read-only Everything is running in ARM supervisor mode And it's presumably compiled with a real view which is the official ARM toolchain for compilation with no stack protection, and ARMv5 does not support the XN bytes which is the same as the NX bytes on the X86 So I'll talk about what I've seen from this operating system and especially the kernel from this memory dump So Qualcomm has developed its own proprietary real-time kernel which is called REX, standing for real-time executive The whole operating system, which means the kernel plus the network stacks and any process is named AMMSS And well, the system is made of approximately 70 tasks running concurrently in the baseband So you have multiple, each task has different purpose There are some tasks for handling the hardware like the USB, the UCM, the DSPs and so on And you've got also one task for each protocol stack at each layer So such as L1, L2 or AMM for WC, DMA and so on So if you want to, in fact it's a tiny kernel but the main, the biggest part of the operating system are the network stacks which are very, very massive But if you want to reverse some tasks randomly, for example, I want to reverse GSML1 You'll need to know what is the API exported by the kernel So you have a minimum understanding of what the code is doing So you need to, well, at least reverse the kernel API the C library also and some built-ins, some compiler built-ins like subfloat or 64 long arithmetic operations So, well, at first, how the system is booting So, well, you've got a primary bootloader which is stored in ROM which is immutable which will read from NAND 12-con secondary bootloader named QCSBL This SBL is supposed to load another SBL named OEM SBL which means the manufacturer of the phone can implement their own bootloader So such as, for example, on HCC phones you've got HBOOT which is the OEM SBL So you have a menu, a splash screen and so on And then it loads the AMSS operating system which is what is really running in the baseband in the end And between each of these transitions, you can have cryptographic signatures for each of the layers On this particular, on this specific model of USB stick you have no OEM SBL So QCSBL is directly loading AMSS And there is no secure boot at all So there is no signature You can reflash, actually, the stick and run your own baseband your own operating system, if you like You've got to write it But, well, for example, it could be possible to run a Smokam BB on this Well, so the RECS tasks So you've got, as I said, you've got a lot of tasks, like 70 I'm just talking here about the core tasks of the operating system Well, you've got the SIP task, which is the idle task, doing nothing DPC task is used, I explain later, what is APCs in the RECS world It's just dispatching APCs across tasks The main task is the first task loaded, the first task created It creates all the system tasks and then under the timer events There is also a task, which is used to verify that critical tasks in the system are still alive And, well, you've got data service tasks, gathering any information from each protocol layer and paces them through pipes to create sockets and so on You've got a task dedicated to code management, so to for secret switch processing and packet switch processing to implementing a TCP AP, for example So, the kernel, so it's a real-time kernel The scheduler, well, it's quite simple Well, you've got, actually, all tasks run in the same address space and in the same state, the same mode of armor, which is a supervisor So, you do not need some complex processing to do task switch You just save the context of the task on the stack and you change the stack pointer and you can by this process switch tasks very quickly There are also, well, there are a lot of fields, I just put in the main fields here Each task has a signal, a set of signals which can be fired or cleared A task can wait for some signals, well, it waits for signals and another task will send a signal for the task to resume and the tasks are also, of course, ordered by a priority So, well, as I said, the context switch is very easy The scheduler also supports critical sections So, the kernel also supports APC, DPC mechanisms I'm not taking this terminology from the Windows world It's really called like this in the strings of the kernel So, well, basically it works in the same way as Windows A nice and pronounced procedural code is just pushing a new context on the stack of a stack on the stack of a task and when the task is resuming because it was in a wait state, for example, it will execute the code and then resume to its original execution So, you've got a task which is dedicated to APCs, which is a DPC task with a high priority and it allows a task to execute some code in the context of another task The operating system also under timers, of course, because it's a real-time operating system So, well, you can set a specific action to occur at regular intervals It's very reused in the kernel because, well, in the RF world, you have to do some processing at various intervals So, timers are only by the main tasks When it has processed the creation of all the tasks It's entering a loop, checking for timers to fire When a timer is triggered, you can, well, whatever, send a signal to a task For example, a signal can, it's just like an event, you see A task can wait for a signal and then another task can send a signal to another task So, it's like an event, you can trigger an event to a task You can execute an APC, and you can also execute a direct hold Which will be directly processed in the context of the main tasks So, tasks, of course, there are 70 tasks running in the base bound each for one protocol layer So, there are some communications between all those tasks So, kernel IPCs are fairly simple also Well, the main method to communicate between tasks is the use of signals Like, for example, a task will have a queue shared between two tasks It will push some data and send a signal for the task to fetch the data And then the overtask can send a signal to CTA, A have acknowledge the data, I've got it I can pop the stack So, the DS task is a data service task It's used to unify all the gathering of protocol stacks at lower layers It will fetch all the data and put them into pipes So that you can see the data as a continuous stream of data, like a network flow So, it's very widely used all across the base bound, all across the system I'm not sure, but I think this is also used for the implementation of sockets on a packet switch services Well, the memory management, you've got an IP, of course There is a global IP in the system, but actually I don't really know why it's not very used In fact, each task implements their own IP, they reuse the same code, of course But they have separate IPs at fixed address, hard-coded address in the code So, the IP structure is very simple Well, the IP metadata will just keep track of what is the first block, what is the last block And for each chunk block, you will see what is the size of the data and is the block free or not So, the next block is just the block after my block plus the size There is no defragmentation process involved or complex things, it's very quick and efficient Well, that's all So, the nice thing that you want to do is to debug the base bound Because, well, I mean, for example, this is just a quick overview of the kernel of the system And the system is made of a lot of tasks You can take an image of the firmware of the base bound and statically reverse each task one by one if you want But, well, first of all, the code is very, very dense, like horrible And the main problem too is that a lot of interactions are involved at runtime between every task So, if you try to look into the base bound, you will see for a task big switches For the handling of signals, sending signals to over tasks and so on And if you just look at it statically, it's almost impossible to understand what's really happening in the base bound So you have to get some to see the system running in live at runtime And eventually, you would want to be able to catch interruptions, for example, if you were able to trigger an overflow or something And you want to single step a task and follow the control flow and so on So how it's possible? Well, for code execution, getting code execution on the base bound, given what I've told before about the diagnostic mode Is very easy, obviously, because you have an arbitrary read and write in RAM So, well, you got the execution is given, it's free Well, you want to upload your code, but you also want to communicate with your code easily So the two main ideas would be to either to hook an IT command or either to hook a diagnostic command I prefer to hook a diagnostic command in my case, because it allows me to debug the IT command Well, if my debugger is running in the context of the diagnostic task, I cannot debug the diagnostic task, obviously So if I inject it in the IT command and learn, it's the same thing Well, optionally, I could create another task in the system and be able to debug every task But it's not very important, because the diagnostic task is not a critical task in the system So I'm basically just reusing the future of the diagnostic task And using its own API to communicate with the payload over USB on the emulated serial port It's possible to quickly get a code execution, because actually only the first 12 megabytes of memory are marked as read-only in the page table But the code section of the binary is 16 megabytes long So there are like 4 megabytes which are writable, and luckily the diagnostic loop and link commands is in this range So you can just rewrite the command table pointer, duplicate the command table pointer elsewhere And get code execution through this, just hooking a command So it's very easy Well, when you get code execution, if you want to write a debugger, next you want to be able to break a task Well, a task should be stopped if you instruct it to do so The debugger tells you to stop this task, or if you eat an exception or a breakpoint So you have to be able to unschedule a task and resume it on demand For this, I just reused the kernel API I've reviewed before So there is a specific function for waiting for a signal for a task So I'm just using, well, I'm just taking a task to wait for this signal And the debugger can resume the task by sending the signal to the task The reason is that the signal is not used in the system in normal conditions Otherwise, you would wake up the task even before you would have told it to So what is done is that I have to execute this piece of code in the context of the task So I could patch the code of the task and redirect the control flow But the kernel directly offers an API to execute code in the context of another task with a DPC So I create a DPC and send it to the task and tell the debugger to wait for this signal So, well, if you want to, I don't know if anybody in this room has developed a debugger for ARM I mean a software debugger But, in fact, it's quite horrible because ARM has no native support for single step It's quite crazy Because if you want to, well, do something as simple as single stepping thread Well, the first way to do it is not like an X86 where you have the trap flag And you will trigger an interrupt at each instruction There is no mechanism in ARM for this So the standard way to do this is to predict the next pointer, the next value of the PC register Set a BP in memory and resume the thread So the obvious problem in this situation is that if you are in a multisread context, like here You can't do this in a safe way Because between the time when you put the breakpoint And the time when you order the task or the thread to continue Another task could have eaten the breakpoint So it would have to check if the breakpoint was meant for this task So it can be done, but for example, if you single step into memcopy It will trigger thousands of interrupts per second You don't want this, it's not reliable So another way would be of course to, you have the context of the thread You emulate the instruction and you update the context of the thread Well, if you need an emulator for this The solution which is offered by GDB in a multisread context Is to use displaced breakpoints So it will use a scratch buffer where it will copy the instruction It will put a breakpoint after the instruction Set PC on the scratch buffer and resume the execution In this way you do not put the breakpoint in memory where the code is relying And so the other task can continue to execute without triggering exceptions In fact, at first, GDB does not support some for this So you have to record it And also you have to, in ARM you can address PC So you have to take care of instruction relocations Like loading a value from PC Or using, if this is a jump for example You would jump out of the buffer and the breakpoint would never have been hit So you have to account for this scenario too And well, it's quite painful to implement If you want something which supports ARM and some You can also, another solution will be to virtualize the address space for each task In this way you just put a breakpoint, use copy and write And follow the page where you put the breakpoint And in this way all those tasks are safe for execution But for this you need to patch the scheduler and implement patch tables for each task And it's quite painful too So my solution for the moment is to use this place breakpoint And standard too So what is the debugger architecture? So, well, you've got the stick, you've got GDB I tried to be a GDB compliant You are communicating over the diagnostic protocol So while you need some kind of a proxy to put the GDB request into your protocol And well, you can also show each task of the operating system as a thread in GDB So this way you can reuse the multi-threading features of GDB to debug the baseband So I think I do a demo of the debugger So, wait a second Okay So at first, well, I'm using the diagnostic mod to push my debugger into the baseband memory And as I said before, rewriting a pointer to get access and cut execution So, well, here it loads the thing It will be finished soon here So, I'm running the proxy Okay, so the proxy is ready So we can communicate with the debugger inside the stick Now I've got a cross-compile GDB for ARM And I'm just connecting the proxy and the GDB client And here it should work So, well, when GDB is connecting to the proxy, it will ask for the list of threads on the target So here GDB is seeing the baseband test of the operating system So, well, you can see the name of the tasks Like, for example, you have the DPC task, the DOC task You have a lot of tasks which are dedicated to network protocols at various layers You've got the main tasks, some hardware tasks like DSP, the vocoder The envirom, and so on So, okay So, when you debug the baseband, actually, you have, as I said before, you have a watchdog task Which is constantly checking whether tasks are alive So if you break a task, for example, with a breakpoint or something, the watchdog will detect it and rebuild the system So you have first to account for this and break the DOC task So I'm going to... Okay, so here I'm getting into the context of the task and interrupting Okay, so the task is interrupted I can check its registers, I can check its code and so on You can also, well, directly inspect anything in the baseband memory, obviously So, for example, if I call rex self Sorry Which is the API in the kernel to get the current task, the current task structure So here I'm calling it So, okay, I get this No, I'm printing it Okay, so as you can see, well, if you can inspect, you can do the same thing for the heap, for example My debugger has a separate heap, so you can inspect the structures very easily You can see that I'm really calling this function in the context of the DOC task You have the name in the field directly in the task structure So, now, for break points and blah, blah, blah Just a second For example, I will... So here it's just an 80 command handler for the SGSN 80 command It's just a command, an 80 command to get the e-mail of the phone and the serial number of the manufacturer, of the mobile So, well, just putting a bit of fun on it I don't see my screen on my computer Here I'm in the 80 channel 80, please, SGSN No, not CGSN What? Okay, so here I've hit the break point If you look at the task, you can see which task, in which context I am It's quite slow because the GDB is doing a lot of useless stuff Well, here it's in the data service task, which is unlink the 80 commands So I'm getting into its context I get access to its registers, I can check its parameters As you can see, this is the right task and I can single step into it Well, it's also nice for catching exceptions So, well, going back to this... I like to use the watchdog task for my experimentations because when it dies, nobody cares So just calling, for example, a function which happens, which happens to have another stack overflow And we use stack overflow into it Just the main copy of the stack Okay, and here you get this So, yeah, you can see that you have rewritten the EIP, get a backtrace Well, the backtrace may not be accurate anyway in GDB because it has no way to distinguish between code and data So I suppose it uses heuristics to find this Well, so if you find... Well, if you use this thing, this debugger and you fill out the USB key You can catch interruptions and see the context, the task in which you are triggering the exception Yeah, and there's also a nice possibility with this way Because when you get code execution on the stack, well, on the stack, code execution on the baseband You can also directly pass commands to the baseband And so you can, instead of deploying a huge... Not huge, but like deploying a BTS and doing a radio frequency fusing on the baseband You can inject data locally on the USB key So possibly, well, it could be possible to fiat the baseband with no BTS at all Just passing commands to the debugger and transferring, making the right function calls Well, you need to know which function you want to fiat, of course So, okay, so in conclusion, well, baseband systems are still massively used and poorly known There is no much literature nowadays for seeing how is the architecture based on the operating system The nice thing about the Icon 2.5 is that it uses an insecure bootloader So you can easily reflash it if you know what you're doing There is also easy code execution achievable, so it's nice for reverse engineering But you have to know that the more recent versions on funds today use an OKL4 REX hybrid kernel So it's not exactly the same thing As far as I've seen, the L4 kernel is just used for the scheduling, but the REX kernel remains for everything else Well, of course, on smartphones today you have a second processor with interactions with the application processor So, well, you can see some related tools, the Ryfee Vaman baseband apocalypse last year Luis Mures talking about baseband playground on an infinite unlocking And, well, on the web you have the various communities, you have a TG World, BB.osmokom.org, for Osmokom BB And many communities like XDA developers and so on Interesting Okay, so, thank you for your time So, thank you for your talk I just want to ask you to please sit down until the questions also are done And if you leave, please leave through the front door and take your trash with you So, questions, here in front So, thank you for your talk and the question regarding the base Have you seen JTAG lines or something? So, for example, if you try to mess around with the flash, you need an emergency exit So, you can, for example, rewrite the flash with a JTAG debugger So, if you, for example, have a closely commercial JTAG debugger that can use the ARM device So, you can obviously flash the device So, if you mess around with the flash, you have a brick device Yeah You mean through JTAG or? Yeah, yeah, have you seen some JTAG lines or have you looked for this? I have not looked for this I know there is a JTAG which is connected directly to the ARM processor But through the flash, I don't know, I have not looked into it Okay, because it would be interesting to do this But you can re-flash the NAND through software calls So, you do not need an underword Yeah, but for example, you can hook up the buggers like from Lauterbach or other companies who make both the buggers And then you can just debug via JTAG You can send the bug to the device via JTAG It's a normal way to debug a device Do you have a trace cell that is connected to JTAG inside the chip And then you can debug with a JTAG debugger Okay And so if you mess up everything, you can just write the flash again Yeah, but I don't know, honestly I have not looked for it I have not tried to re-flash the device for the moment As you saw, I'm just pushing the code in the RAM at runtime I've got two questions via IRC The first one is, is the baseband you analyzed identical to the embedded basebands of Qualcomm's MSM7000 or Snapdragon chipsets? Are they? Sorry Whether the baseband you analyzed is identical to the embedded basebands in the Qualcomm MSM7000 chips or Snapdragon chips? I think in 7000, you have a Rix L4 hybrid kernel So it's not exactly the same thing The system is, you know, they have not rewritten the system from scratch They have just changed the kernel But I think if you find, I don't know, but if you find a vulnerability, for example, on this stick There is some fair chances to find it in other versions Whoever or not, the kernel is different Someone is asking, how long did the whole process of reverse engineering this take? This, honestly, maybe for reversing just a kernel, maybe five days, maybe But just gluing all the things together and testing, developing the thing, two months Could you please put your slides and URLs on the PentaBARF? That would be cool. Thanks Did you have access to any documentation, any papers of Qualcomm? So like user manuals for Rix or something? There is, I know there is some leaked documents from Qualcomm on the internet I've looked into them But the thing is, something interesting is that you have the Rix sources which has been leaked for a very old version of Rix But from what I've seen, what is in this USB stick is much more complicated than what I saw in the sources So it's looking alike, but not the same thing And in the baseband, there are a lot of leaked documents, but I have not gone through all of them So it's good to check on them to see if you are on the right path I have two questions First of all, the agenda was to find out interesting things about the Qualcomm baseband So I'm wondering why you are not using the Qualcomm diagnostics tools that are more or less freely available on the internet Which seem to have leaked from Qualcomm licensees So your work is somewhat different and it's impressive, but why not try this first? And the second question is, are you doing this privately for fun or are you doing this through your company with some agenda? No, I'm working for a company, I'm working at Sogeti, which is a French company But that doesn't meet, I do not work for fun, I mean, I'm doing it for fun also In fact, the first idea I had when I started looking into this was not to find vulnerabilities or developing a debugger But developing more of something to dump the data, like at various network layers Just to see, without deploying BTS and something, just to see what the network data would look like in telephony protocols But I find this interesting to be able to dump data on this key But as a matter of fact, I realized for reverse engineering I needed a debugger, so I first developed a debugger And well, there was two questions, but the first one was... Well, why not use the tools that are available on the internet, like QCM or so, you can find this in several places Sorry, can you repeat? Which attach to the diagnosis board you mentioned Yeah, what is available on the internet, sorry, maybe there is something I haven't seen If you Google it, you will find it Yeah, you mean the diagnostic channel, for example? No, no, no, the tool for it, which is called QXDM Well, maybe, okay, it's not very willing to reverse actually I had a quick question, we noticed some symbol names in the GDB output Are those your symbol names or did you find a symbol table within the binary? Actually, in my GDB script, I'm just loading... Well, my debugger, I include the symbols into the binary of my debugger in ELF and I load it into GDB So it can look into them Okay, so those are your symbol names though, not official ones No, they are my ones Thanks So, are there any other questions here? Oh, there are some... Another question from IRC, do you plan to release the source code or is there a possibility to get the source code tools? Yeah, I have not done it yet, I will upload it to Google code IZAB I think you hinted it, are you actually working on a protocol analyser? Is that what you're actually building? You sort of hinted at it but didn't actually say, were you actually working on a protocol analyser? Was that the sort of initial starting point? Actually, it was Did you have any success in that or is that something you're still sort of working on? In fact, for this, the debugger is not finished Well, it has basic debugging capabilities for the moment But there is a future I need for this It's the implementation of trace points So the ability to not to resume the task immediately after hitting a breakpoint And for this, it's not very evident because you have to displace the instruction And execute it elsewhere, so you have to perform relocations and so on And my relocating motor engine is not completely finished yet So as soon as I get trace points working, I will put trace points on the circuits in the basements And I will try to see what comes out of it So, thank you, Jung We are now at the end of our time and it was a very interesting talk And have a wonderful plause