Embedded devices reverse engineering
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
Titel |
| |
Serientitel | ||
Teil | 9 | |
Anzahl der Teile | 20 | |
Autor | ||
Lizenz | CC-Namensnennung 4.0 International: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
Identifikatoren | 10.5446/32385 (DOI) | |
Herausgeber | ||
Erscheinungsjahr | ||
Sprache | ||
Produktionsort | Brüssel |
Inhaltliche Metadaten
Fachgebiet | ||
Genre | ||
Abstract |
|
3
4
7
8
17
18
00:00
Physikalische TheorieStrategisches SpielComputersicherheitÜberlagerung <Mathematik>BitInverser LimesModelltheorieSichtenkonzeptSoftwaretestFlächeninhaltDifferenteForcingOrtsoperatorSelbstrepräsentationComputeranimationJSON
01:12
Nichtlinearer OperatorProjektive EbeneFensterfunktionComputerarchitekturRechenschieberOrtsoperatorElektronische PublikationBlackboxE-MailSoftwareLesen <Datenverarbeitung>MultiplikationsoperatorFirmwareSpeicherabzugComputersicherheitFreewareHardwareSoftwaretestNebenbedingungSpeicher <Informatik>SummierbarkeitComputeranimationVorlesung/Konferenz
02:57
MikrocontrollerFlächeninhaltSpeicher <Informatik>SoftwareDifferenteBlackboxPhysikalisches SystemProgrammbibliothekAbstraktionsebeneMAPSchreiben <Datenverarbeitung>EinfügungsdämpfungKugelkappeAuswahlaxiomHardwareTrennschärfe <Statistik>Peripheres GerätKartesische KoordinatenFamilie <Mathematik>ComputerarchitekturZentraleinheitFirmwareARM <Computerarchitektur>BetriebssystemVorlesung/Konferenz
05:08
ProgrammfehlerBitSpeicher <Informatik>GrundraumAutorisierungInterface <Schaltung>TelekommunikationQuick-SortInformationEntscheidungsmodellDateiverwaltungFamilie <Mathematik>DefaultZustandsdichteElektronische PublikationSystemplattformEchtzeitsystemExogene VariableTermInverser LimesVersionsverwaltungGeradeEigentliche AbbildungGruppenoperationPhysikalisches SystemDifferenteSchaltnetzComputerarchitekturHalbleiterspeicherKommunikationsprotokollArithmetisches MittelComputersicherheitMobiles EndgerätFunktionalDatenstrukturFrequenzMultiplikationBetriebssystemLie-GruppeMultiplikationsoperatorCASE <Informatik>Open SourceFramework <Informatik>Peripheres GerätDatenverarbeitungssystemGamecontrollerZentraleinheitHardwarePlastikkarteLoginSoftwareBootenFirmwareProzess <Informatik>FehlermeldungNebenbedingungCodierungSoftwareentwicklerATMBimodulThumbnailWeb SiteFreewareArithmetische FolgeComputeranimation
11:19
SemaphorProzess <Informatik>InformationPrioritätswarteschlangeTelekommunikationKoroutineProgrammKomponente <Software>FreewareFunktion <Mathematik>p-BlockGamecontrollerDatensatzZeiger <Informatik>Mailing-ListeBildschirmmaskeDatenstrukturCASE <Informatik>BefehlsprozessorTaskMultiplikationEnthalpieSpeicherschutzProgrammbibliothekBetriebssystemComputersicherheitEchtzeitsystemKeller <Informatik>PortscannerMultiplikationsoperatorComputerarchitekturSchedulingQuellencodierungOpen SourceBenutzerfreundlichkeitNummerungBitPlug inDreiecksfreier GraphWechselseitiger AusschlussSichtenkonzeptBinärcodeMAPRechenwerkDifferenteSoftwareschwachstelleGrenzschichtablösungLaufzeitsystemSensitivitätsanalyseProdukt <Mathematik>CodierungPunktErwartungswertSpannweite <Stochastik>ATMPufferüberlaufSpeicherabzugKartesische KoordinatenTwitter <Softwareplattform>InterprozesskommunikationFunktionalWeb SiteInterrupt <Informatik>HalbleiterspeicherHardwareGeradeElektronische PublikationStochastische AbhängigkeitForcingZentraleinheitSoundverarbeitungSpeicher <Informatik>Schwach besetzte MatrixFlächentheorieFlächeninhaltUmwandlungsenthalpieMessage-PassingWasserdampftafelOffene MengeStandardabweichungMathematikMixed RealityNichtlinearer OperatorPerspektiveProgrammverifikationComputeranimation
21:00
CodierungFirmwareSpeicheradressePersönliche IdentifikationsnummerHalbleiterspeicherBetriebssystemEchtzeitsystemBootenDefaultFunktion <Mathematik>Interrupt <Informatik>Physikalisches SystemComputerarchitekturAnalysisOrdnung <Mathematik>Reverse EngineeringNormaler OperatorTaskInformationSkriptspracheMAPSpezialrechnerTabelleArray <Informatik>Peripheres GerätSystemaufrufGamecontrollerNichtlinearer OperatorZeiger <Informatik>FunktionalPlug inCASE <Informatik>MinimumInstantiierungMultiplikationsoperatorBildschirmmaskeCompilerLaufzeitfehlerPunktGruppenoperationSchedulingFreewareDeskriptive StatistikZeichenketteEin-AusgabeKartesische KoordinatenSichtenkonzeptGeradeSemaphorAbstraktionsebeneSpannweite <Stochastik>Lesen <Datenverarbeitung>ARM <Computerarchitektur>Open SourceSpeicherabzugSpeicher <Informatik>ProgrammSampler <Musikinstrument>HardwareMetrisches SystemEreignishorizontSpieltheorieDatenfeldBridge <Kommunikationstechnik>Softwaretestp-BlockKonstanteRechter WinkelPlotterComputerspielAggregatzustandFehlermeldungSchätzfunktionComputeranimation
30:41
SpeicherabzugDifferenteFunktion <Mathematik>Interrupt <Informatik>CASE <Informatik>p-BlockOpen SourceARM <Computerarchitektur>FreewareSchreib-Lese-KopfInstantiierungKartesische KoordinatenGruppenoperationGarbentheorieFunktionalCodierungBefehlsprozessorPlug inZentraleinheitPersönliche IdentifikationsnummerMailing-ListeMultiplikationBitEinsExt-FunktorPeripheres GerätFlash-SpeicherComputerarchitekturEchtzeitsystemKernel <Informatik>Reverse EngineeringArray <Informatik>FirmwareTaskGamecontrollerLoopMultiplikationsoperatorDienst <Informatik>SystemidentifikationHeuristikTabellePunktRechenschieberHardwareSpezialrechnerMinimumTypentheorieHeegaard-ZerlegungQuick-SortKreisbogenSchlüsselverwaltungKonfigurationsraumKonfigurationsdatenbankEreignishorizontGüte der AnpassungTopologieSystemzusammenbruchDreiecksfreier GraphComputeranimation
40:22
MultiplikationsoperatorHierarchische StrukturMAPInterrupt <Informatik>TaskCodierungKernel <Informatik>EchtzeitsystemSpeicherabzugSoftwaretestComputerunterstützte ÜbersetzungVorlesung/Konferenz
41:54
Computeranimation
Transkript: Englisch(automatisch erzeugt)
00:09
Brussels 2017. Hi everyone so I'm Vitor Ventura and well first of all we have
00:30
some disclaimer these are it's our own view so it's not there's not necessarily represent IBM position on this so I'm Vitor Ventura I work for IBM X force
00:40
red well blah blah blah blah blah blah I don't really think that this really matters what I what I am or what I have so well done yep thank you so a little bit about me I work for the same team as Vitor it is IBM X force red team we cover EMEA region and we have a lot of work you know in
01:03
different areas of security covering a be the devices reverse engineering and penetration testing so why are we going to speak today about this topic very recently we had interesting project testing one device which might
01:20
be used in automotive industry and it was based on free RTOS and ARM cores and we had some interesting findings during the during this project and also we discovered that there are not too much resources about security on the free RTOS so that was the big problem on the one side and the other
01:42
side there we had some issues actually reversing the embedded firmware for the device when we get to it so after a lot of time spent reading documentation reading header files we decided it might be interesting for some of you which might come into this a similar position to share with you some of our
02:02
findings so how many of you did some embedded development oh we have some hands excellent so that's good so for you this couple of slides will not be interesting so I'm going to show you how a different mindset is needed when
02:22
you are working on a be the device we are all used to desktop stuff we have developing software we have reversing it we have analyzing it and that is something that is common we know that there we have mostly two architectures sick both based on the Intel most common stuff are running on Windows so we are very aware of all constraints and there is a lot of
02:44
resources about that also hardware is very much hidden from us there are some drivers which might or might not be the interesting to us but usually hard there is already predefined and we access it as a black box operating system provides a black box so level of abstraction of the hardware to the
03:05
software world so that is the main purpose of all drivers in the operating system and that is very much different in the immediate world we have small CPU micro CPU usually there are a lot of choices today when I started there
03:20
was only one or two choices Intel or Motorola now we have a lot of different architectures and very common and very powerful devices coming for arm usually cortex m03 and then for devices because they are of the family which is made for embedded devices so you have a family of farm which is for
03:43
application purposes and then which is for embedded devices and they came into a lot of peripheral solar integrated in it and problem is when you're developing for embedded stuff you need to be aware of both hardware and software so you cannot just sit and develop software for device that
04:02
you never saw before because it will not work and we'll pick it off and be the device is because today we we we see that maybe devices are everywhere today it is much cheaper to put a microcontroller on something than
04:20
simple transistor before so you have it everywhere from the cups for a coffee which already have some indicators about temperature and stuff until the small toys to big toys to cars so even our car is one big embedded system with wheels on it and it's driving and it's becoming very interesting target
04:44
for different attacks so tools of choice are more or less similar for from both sides so we used to work usually with the IDA or radar or whatever on the desktop and we can use the same on the mobile as long as it supports our
05:01
target architecture but problem is for example our favorite tool is IDA Pro of course but it has some quirks for example to load this example firmware that we are going to show you later we needed to set numerous places to heavy decode correctly so it is a little bit complicated setup and it is
05:23
very useful something that you are not going to show you today because this is still work in progress is to use structures dynamically created in memory so this is why we are going to speak a little bit about architecture of free rtOS to help us discover functions so when we are talking about free rtOS it
05:46
will be a little bit cleaner so we saw problems with if any of this is not properly set up we will have problem with mode instructions so if you don't set up this segment default register value to T to 1 it will not
06:01
decode thumb instructions properly for example or you will have to manually switch each line to thumb mode as any embedded devices we always said they are everywhere most popular and be the devices are currently running on Mars so imagine designing something and to put it millions of kilometers away
06:22
and to try to fix it debug it and maintain it it is big problem and developers need to be aware of the they have limited amount of memory and resources they must be aware that power consumption must be control they must take care of real-time responses and device must be
06:41
self-sustainable and resilient what does it mean about 200 days after the Mars rover landed on Mars there was an issue it has two computers in it for resilience and they are designed in case the primary computer has any problems to shut down and hand over to the secondary computer problem was
07:02
device started to stop to responding to any commands why because primary computer was stuck and device was unable to switch to secondary computer luckily there was a third communication device which was independent of all this and it was enabled that control from the earth sent commands to shut
07:21
down primary computer and switch over to secondary computer so it is very very important about resilience and self-sustainability of these devices what are we seeing is that first problems are coming from the hardware side so you have data in your ports available so you are able to connect
07:42
and debug device of course in case of Mars rover if somebody sit and start debugging your device we will have much serious issues than security of the device at this point but for the earthbound device this is a big issue we have exposed buses so you are able to just tap into the wires on device and
08:02
to read all protocols that are running there if you can decode it of course then we have unprotected storage for example you will have device which have internal flush around but it will have also external memory for whatever purpose for logs for firmware for temporary storage like SD card so you can
08:20
tap into that and collect information there are also a lot of communication interfaces mostly radio interfaces which are used for everything and we already know they are easy to hack from time to time there are very common debugging consoles are left running so developers forget to disable
08:40
debugging features before they release so that enable us to get to the boot loader it enable us to download the funeral for devices and to do whatever we need to do with it so there are also software requirements and first software requires it need to be tailored specifically to embedded hardware to hardware of the device the architecture that we chose and this
09:04
is a big problem you usually have two teams one is hardware development team the other is software development team so hardware team will choose architecture that they think it will work for them software team needs to adjust and that comes to some problem because CPU speed memory
09:21
constraint available storage they all must they will all impact software development of course again power consumption error handling soft and and bugs resilience so software developers must be able to adjust their processes and their code to specific architecture how to do it there is a lot
09:41
of different hardware as we already mentioned that you have a different architectures with different ndns different peripherals and you need to account for all possibilities of a combination of different devices so the common solution for this use something of existing frameworks and real-time operating systems which will help you to solve this into controllable manner
10:05
one of the very common operating systems that are used is free RTOS it is nice because it is open source it is available in the market for a lot of time a long time there is a commercial version which is certified for security
10:22
blah blah blah so it might be interesting if you want to take a look at more details on the site that is down there it ran on almost every possible platform including Arduino so if you want to try it at home you can play with it no problem it's easy to port to new platforms you need to change only three files which are hardware dependent everything else will
10:45
run as is and it support multitasking it's even has tiny footprint so on top of this basic operating system we have additional modules which are available to make our free RTOS device more usable so first and most
11:04
important is TCP IP stack then we have a fat file system command line and IO support which includes GPIO you all know what is GPIO okay I assume yes so basic structure of free RTOS is as shown here we have hardware on the
11:27
lowest level then we have hardware dependent code those three files that I showed you then we have core those are hardware independent files which are same and provide the same functionalities and we have user code which will actually be executing on top of free RTOS and it will serve the
11:45
purpose we intended so main component is task scheduler task scheduler is the orchestrator which will take care of executing tasks tasks are programmer provided pieces of code so actually it would be like programs on the desktop
12:04
that runs specific functions and they execute concurrently so it is multitasking each task has a separate stack and you will see later how that stack is handled there are coroutines that is the I mentioned this but this
12:22
is almost not used anymore I think it is not even supported anymore and we have communication with inter-process communications so data queues to exchange information between processes semaphore and mutagenesis for signalization and timers for measuring time as we say real-time is really important in this case the most important structure are lists everything
12:47
in free rtos is contained in some form of list so we have a pegs task ready list which is most important list which has pointers to records of task control blocks task control
13:04
block contain all necessary information for the customly created task so when you create first task you will create task control block somewhere in memory and you will add it as a number one in your task ready list but when you create first
13:22
task one more task will be automatically created which one any ideas idle yes so first task zero task will be idle task which will take care of all the unused cpu cycles and then all the others so when you
13:41
extension your first task it will create automatically automatically idle task so we have a little bit about queues so again they are lists with some specifics to it semaphores they are they can be binary semaphores or or or multiple semaphores and they can
14:02
use views to communicate between signal between the processes and mutexes are used to protect access to resources during the multitasking now what will happen if you have two tasks one is of highest priority than the other and each of them
14:21
needs to access two resources so first will be started with high level task it will create high level mutex protecting the resource then you will have lower task executes it will create mutex to access the other other resource which is not claimed yet by the higher level task and it will
14:42
create mutex now you will go into situation that you're blocked because your high level task cannot access resource which is blocked by the lower lower level task and vice versa so both tasks are blocked and you cannot you cannot proceed so free rtrs solves this
15:00
by temporarily raising the level of the process which is waiting for mutex from higher level process so in this case lower lower level task will be upgraded to high level priority so it will be able to take the mutex and proceed accordingly it will not be waiting for the higher level task
15:26
so there are some security features which are always embedded in free rtrs add-on so first add-on is ssl library it doesn't came with free rts it is separate library from wolf ssl i believe it is additional it is
15:42
much smaller than standard open ssl and if you are aware most of the vulnerabilities we had in the last couple of years to serious vulnerabilities were related to open ssl it became too big for its purpose and it's difficult to so this this operating system is using another library which is very nice and
16:04
small and support everything that you actually need it has some rudimentary stackover for protection and it supports different privilege levels for the tasks but that is limited only to cortex m3 devices which have memory protection unit so in this case you can create
16:24
task of different privileges that is not the best approach because it is easy to to to to to go around problem is that from unprivileged task you can create privileged task
16:41
so if you manage to exploit something that runs under unprivileged task you can rope your way out of it by creating privileged task and getting access difference between privileged and privileged tasks are privileged that has access to its own stack and to all other stacks unprivileged task task can access only his own resources only his own stack
17:05
yep so we have a stack for overflow protection is rudimentary so it is in two there are two possible modes one will just simple check if your stack pointer is somewhere where in the range where it should be expected the other one will add small
17:23
canneries to measure if it is on the expected point and problem is the tcpip stack is not very resilient because this is a bd device it is not made to suffer harassment of million users connecting to it all the time so if you do any more
17:41
intensive for example port scan on this device they might experience some issues and this is see that very often it's the devices so this is why we never scan skater devices in the production they are they have really sensitive tcpip stack and of course it's free rtos is developed
18:01
in c it inherits all the possible issues that you have in any other c programs to be fair i i was searching for such vulnerabilities for two months and i couldn't find any it doesn't mean that they don't exist but they couldn't find them but you might find in the custom created
18:20
tasks so they can introduce vulnerabilities free rtos is relatively safe from it and you can always investigate it because it is open source and everything that we discussed so far could be fine and checked into source codes that are provided on the site we are going to develop a simple application that twitter will later be
18:42
destroying here for purpose of demonstration and we are going to develop a simple application because it will be easier for us to see and to show you what is important so we'll create an application which have only two goals one is to check if button is pressed and if button is pressed it will toggle the lead so it is very simple
19:05
and this is the basic architecture that first come to mind so we have core rtos we have a task scheduler running the two tasks first task we check if the button is pressed do the bounce and everything and then we'll put in data queue information that
19:23
button is pressed the other task is led toggle task it will verify if data queue has information that he expects and he will turn off or turn on the ladder accordingly this is nice but it is bad this is not how it is done actually on embedded devices so i created a little bit better
19:42
architecture problem with first architecture is the device will never go to sleep so we have problem with power consumption in this case i have changed a button handler to be interrupt so device can go to sleep and only when you press the button you will generate interrupt and wake up device device will detect that it is waken up by external interrupt
20:03
and it will trigger the binary semaphore it will became available let's toggle task will wait for binary semaphore to became available and when he detects that it is available it will turn on the LED and and make semaphore again unavailable so it
20:23
cannot do two things he cannot toggle twice on the same time so next time only button handler needs to to set the semaphore again so how it is done it is very simple so bolded lines are hardware dependent lines so set of hardware is hardware dependent as expected
20:42
everything else is not hardware dependent so we created one task which is LED semaphore handler task and we started task scheduler if we ever get return one there is a problem with our application it should never return task schedule and start running should never return
21:00
and two functions first one is regard related to LED so how to toggle the LED it will check if semaphore is available it will wait forever if it is not available then become available it will trigger toggle the LED i give alternate the alternate way of triggering LED because it might be interesting
21:21
for something that we'll be showing you later and we have interrupt handler in this case our button is on line eight so we need specific interrupts which will handle line eight we check if it is line eight and do what we need so we release make semaphore available and let LED trigger what remains is to go from the source to the
21:47
hardware so we will do compilation blah blah blah blah blah blah and we will upload everything to our device power it on and will detect that it is running so we have created our first ability device we expect some profit from it of
22:02
course we don't do stuff for free but we make a lot of mistakes and the dark lord of murder is looking at you and he will do something bad to our device so vitter dark lord please okay so um one of the things that
22:21
it's interesting so we have the good thing and the bad thing about these embedded systems and well the good thing is that they are deeply tied into the into the into the mcu and this means that you have a lot of documentation you can go to the to the to the st electronics for instance we
22:41
for this example we used we focused more on the stm32 f0 mcu which is based on the on the arm six m0 core and the good thing is that the embedded devices they need to be developed for the specific mcu so this allows you to have you will have a lot of documentation about the mcu the interrupts all
23:01
all the architecture and this is a good thing on the other side the bad thing is that it's tied to the mcu so if you have your firmware you and you don't know what is the target of it so it will be hard for you to understand what's going on inside it because you won't know how the starting address is you won't know how how to to approach it so it's a good thing and it's a bad thing
23:25
so um let's imagine that we don't have a lot of string analysis usually these these kind of systems don't really need to output a lot of things to the user so if you look at the strings you don't get that many things that many that much information has gotten said because the code of that the user code
23:44
on free rtos is embedded so deeply into the operating system you don't really have the sys calls that you can search for there are some of them that you become that is reused when you compiled your code like the the scheduler but in reality you don't have that sys calls to read memory to read
24:01
the the some kind of in of of interrupt you don't have that so it's not that easy to to look and see where you are going to start and from the memory point of view it's not protected so when your application is running basically you are reading and writing from all memory addresses depending on if you are
24:21
trying to read from a register which is tied to a give to a pin output or or input or if you are looking at the on on an external interrupt so everything our memory addresses so you don't really have the abstraction layer that you have on normal operating systems and this leads us to some kind of difficulties when you are trying to reverse engineer an application
24:42
free rtos image because you don't really have the usual desktop approach so um can we the first thing is that we need by default when we put the image into either like vladan said you need to set the initial the the initial address for the image you need to have
25:02
some some information the size of the image you need to know exactly what to put and either will disassemble it but the thing is the the entry point and you it might be not that easy to find the entry point to see how your program is starting you can wandering around and try to search for it but it's not that easy and either you might not detect it so
25:23
can we find it how can we do it yes we can and one of the things that dst32 by default they have they have a group of interrupt handlers that will help that will by default help the the the firmware to know how to behave when the the first
25:44
the mcu boots up so in order to know where the that handlers are the this mcu has the interrupt vector table which pretty much is a table that holds all the information about about what kind of interrupts can exist on the mcu
26:03
and one of these interrupts is the reset so what's the reset more than simply a boot so when you boot the device it's a reset it's nothing else than that so if we look at the at this table and we looked for the interrupt
26:21
for the reset interrupt handler we pretty much might have that that answer so if you look there you see that oh going from bottom to to up you have this is the the actual table that you can get from the documentation and you can see that you have the initial stack pointer and then you have the reset so this table pretty much
26:40
goes to this at the beginning of the image at offset zero zero so you can see that you have some code there that was not is not actually put into that that table form so what we did was we tried to get a plug-in that would help us to have a mapping between these values and the actual values that are on the
27:02
documentation so these are the two first values that we have and after we run the script we'll see it like this and we also added some documents some comments that will help us to initially understand what's going on so first we have the the stack valid then we have the reset handler and there there are other handlers like theirs like the the SysTick handler
27:22
or the SVC handler which are used by the VRTOS to to manage the tasks so if we now after we have this the the both addresses for the for the interrupt handler we can go there and we can actually see what is going on so as soon as this device boots in this case what he's doing is is basically putting
27:43
the initial stack address into the stack pointer which pretty much can be the first the first action that it does so now we have a now we have an entry point and this helps us to start our analysis now we really can can see where our code starts to being executed
28:00
of course as we said this is highly dependent on the MCU so the good thing is that it's well documented and probably if you know which MCU you are your image targets you can go online and search for the documentation and you will find that that the description of that table which will help you to understand exactly what it's doing so
28:23
now we have an entry point we know how to start but as i said also everything in RTOS is pretty much reading from memory and writing to memory addresses so there's no syscalls so if you remember i said that all the peripherals inside the MCUs
28:43
they are managed by these addresses so these ranges and these offsets can they be useful for us yeah of course they can for that from from reading that we can understand exactly what what our image is doing so again we can go to to the documentation of the specific MCU and what we did was well
29:02
since we're doing a plugin to help us we basically run a plugin that will have that has some information about the the documentation it will list all the registers that are manipulated the functions that that manipulate each register so that we can go directly to the code that we want to see and
29:22
and also it will have that um well comments that will help us to manage it so in the end we can see things like this so for instance in this case we know that we are attributing the control the clock control register this is important for instance because if you want to see
29:41
a peripheral that has some kind of GPIO read or write it will have to have a clock control register attributed to it so if if by chance because some of these addresses can be generated in real in runtime even though if you cannot find the specific register where the the GPIO is being written
30:02
you can just search for this kind of registers which will tell you exactly which GPIO buses are being used so because some of these addresses they can be hard coded and they can be generated in in memory however the compiler tends to generate some of them to keep some of them hard coded so that it doesn't need to make
30:21
so much so much so many operations during execution the other one that is really interesting to see is the SysTick the SysTick will generate a clock basically and will call the interrupt the interrupt the SysTick interrupt every time the clock reaches zero so if you want to check for
30:42
tasks that are in the loop this is the the place to go and this will this will tell you exactly how the clock is behaving which is also really important so that you if you for instance you have a firmware which is checking on certain intervals for for some signal that is coming from an external service that can that can be it so it's it's
31:02
also very interesting to check the other thing is that what we did was okay now we can see exactly as i told now we can see exactly which which functions are manipulating our registers so we can go we can have a more direct approach we can look into the those functions and see exactly what they are doing the code of those functions is ARM so everyone that knows ARM can will be
31:24
able to understand it so this is much more about how what what would be the methodology to get there instead of just looking at the code without really wondering without really knowing where to look so in this case for instance what we what we have done is we are looking at the the SysTick
31:43
function and as we can see up there it's we are setting the reload value and we are doing the control register so these specific registers they belong to the core to the ARM core not to the MCU because you have two different kinds of registers you will have the registers which belong to the core to the ARM core
32:02
and you'll have the registers which are on the MCU so they are not they are not the same and they are protected in different ways but in this case this is just an example what we are seeing here is that we are telling the we are configuring the register for the SysTick so the first one we are giving the hit a thousand ticks and after a thousand
32:25
ticks it will do something and that's defined by the second register so the SysTick control register so if you look at the documentation we should be going through the next slide oh sorry my prop point crashed okay yeah
32:43
so we're not if you go if you look at the documentation in this case in ARM you'll see that those three bits are the ones that configure actually the register so when we do when we move the seven into the into that register what we are saying is that well we want the clock source to be one we want the tick int to be one and we want the clock enabled
33:03
so the clock source is just saying that it's a hardware clock it will go directly from the from the CPU the tick int is saying that when the clock comes to zero it will release an interrupt and it will stay and it will wait it will not move on to the next cycle and enable basically it's enabled the
33:22
clock it's enabling the clock so in this case what this application is doing is that at every a thousand clicks it will generate an interrupt and it will wait so this is kind of thing that you will find on the documentation of and on of all MCUs in this case all MCUs based on
33:41
the the ARM 6M0 will have this kind of clock which can be configured on whatever you want but depending on different ARM cores or depending on different MCUs you can have you can have different registers so the thing here is that this what we did was basically we tried to have kind of plugin that would help us
34:01
to understand that code much easier than just be looking and knowing the addresses from the top of our heads so the other thing that it's also interesting is that when you have a free RTLS OS basically you will have critical sections and this is really important because sometimes you cannot
34:20
wait you cannot have an interrupt while you're doing something if you are breaking a car you cannot have an interrupt to say well stop breaking and keep on so there are the ARM processor has two specific instructions which allow you to enable or disable their interrupts which is a good place to start looking if you are trying to do the reverse engineering of an
34:43
application it's a good place because most probably critical code for your for your application will be inside a disable enable block of disable interrupt enable interrupt block of code so the other thing that that we tried to do was basically list all the
35:03
functions that enable the the interrupts because that will be the end of our block so we want to go from bottom to up to up so in this case we'll we just list all functions that that has the the instruction to enable the interrupts and then we list all functions that basically call that function and this
35:21
helps us to understand that in this case for instance we are the the the function the one e4 disables the interrupts right at the beginning of its execution and then it will re-enable them really really down the code so if we wanted to understand exactly what that block of code was doing the good thing would be to try to understand exactly what was going on between the that that block
35:44
so in here it's the same function but you'll see that we are calling there the cdc which we identified as being one of the the function that were inside it is has the code to re-enable the interrupts now enable and disable the interrupts is not that thin here because there are a group of each
36:01
interrupt will have different priorities and there are a couple of priorities that will actually make this the kernel of the rtos to stop and execute the function that the handler that has that handles that interrupt so it really depends on the the priority of of your code again there are there are registers
36:23
that are used to define the priorities of each each each handler and again that's just a register inside the mcu just need to look at the documentation you'll have exactly exactly what register we are talking about so there are a couple of other really
36:40
interesting registers like the the sysconfig x which is basically a register that will manipulate well going a little back all mcus they have several pins and those pins will be connected to a multiplier multiplier which basically will be enabled will be enabled or
37:01
disabled according with the bits that you have so what this means is that you basically have all depending on the architecture but on this architecture you have two buses which have several gpios and then you need to select which ones you want to check so this register the sysconfig ext which basically allows you to configure which external interrupts you're going to have into your mcu
37:23
and then you have the the exti register which basically allows you to define the handlers for those interrupts and the pins that you'll have also the the clock source we have already talked about and the nvi registers well the nested vector interrupt control which also it's the one that allows you
37:43
to define to actually to define the the interrupts that you will have so how you handle those interrupts and which are the priorities that you have on those interrupts if the exti allows you to to define which are which ones are the external interrupts that you will be using and on which pins the the nvi
38:03
will allow you to define the priority of those of those of those interrupts and then we have the the clock which is also interesting because if you want to have a gpiio external with external data to read from an esper from a flash flash memory or from some other kind of external device
38:21
you'll need to to give it a clock so even if you don't find the the address that allows you to identify which pin you are using you can check this register to see which pins are being enabled which gpios are being enabled so it gives you a clue or where to find afterwards what you need so and based on this basically what we did was
38:43
well we defined the list of registers so the plugin that we that we did when is executed basically search the code for all of these registers and we'll and it will give us this output which allows us to understand which functions are doing what and at the same time it will also add some codes some comments on the code so that when you are
39:01
going through the and looking at the code you can more or less have an understanding of what's going on so this is some there is a lot of work to be done on this on this basically because there's this is highly depending on the on the mcu's so not all of them will have the same registers so that we need to implement
39:22
some heuristics to find registers which is which is which are being created dynamically so that we can know can also try to help and identify which which interrupts and which external device are being used there's also another one another thing that we want to do which basically looks at the table that we talked
39:41
about and decodes it automatically the code that that are being pointed to it and well there's a lot of work to be done especially because there's so many different mcu's so many different cores that can be used that doing this through all of them it's really well it's a huge task of reading documentation and copy documentation so the idea is that this plugin can be
40:04
updated by anyone and then anyone can just basically load it as as they need another thing that we would like to to achieve is the identification of the type of image which is something that is not that that easy and again it's highly dependent on the on the mcu's on the cpu's and well thank you that's basically it
40:31
we have time for questions if you have i have one question but it's because i haven't
40:43
understood you were speaking about the interrupt level can you re-explain that sorry you were speaking about the interrupt level it's the topic that i have not understood so when you when we enable or disable interrupts that's possible the mcu will do that
41:01
however you need to to give it a priority and there are a certain level of priority between three and one which even though you disable the interrupts the the core will always execute the handler because and even the rtos kernel will stop to execute that task so you can really when we say that we are disabling or enable
41:21
interrupts we must be careful because we cannot assume that that will happen 100 of our code if you have a task which is at one even if you are running something else that that handler will be executed when the interrupt occurs even if you disable them it's like the hierarchy well more or less yeah okay yeah thanks nobody
41:47
okay okay so thank you guys thank you