taban/PIR_MadMax
2
4
Fork 0
Code Issues 4 Pull requests Projects Releases Packages Wiki Activity Actions

chgt titre et auteurs rapport

Browse source
This commit is contained in:
Nolan Reynier Nomer 2026-05-12 15:28:59 +02:00
parent 2040b27f72
commit e6eb04a278
5 changed files with 290 additions and 217 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

28
Sécurité/main.aux
View file

@ -3,14 +3,24 @@
\@writefile{toc}{\contentsline {section}{\numberline {II}Litterature review}{1}{}\protected@file@percent }
\@writefile{toc}{\contentsline {section}{\numberline {III}Research gap}{1}{}\protected@file@percent }
\@writefile{toc}{\contentsline {section}{\numberline {IV}The aim of the study}{1}{}\protected@file@percent }
\bibcite{b7}{1}
\citation{b1}
\citation{b1}
\citation{b2}
\@writefile{toc}{\contentsline {section}{\numberline {V}Software and Connectivity}{2}{}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {V-A}}BLE Compatibility With the VESC}{2}{}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {V-B}}BLE Vulnerability}{2}{}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {V-C}}Testing of BLE-modules}{2}{}\protected@file@percent }
\@writefile{toc}{\contentsline {section}{\numberline {VI}Code integrity}{2}{}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {VI-A}}VESC compiling}{2}{}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {VI-B}}lispBM extraction}{2}{}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {VI-C}}Discussion}{2}{}\protected@file@percent }
\@writefile{toc}{\contentsline {section}{References}{2}{}\protected@file@percent }
\gdef \@abspage@last{2}
\@writefile{toc}{\contentsline {subsubsection}{\numberline {\mbox {V-A}1}First Experiment}{2}{}\protected@file@percent }
\@writefile{toc}{\contentsline {subsubsection}{\numberline {\mbox {V-A}2}HC-05 and the VESC}{2}{}\protected@file@percent }
\@writefile{toc}{\contentsline {subsubsection}{\numberline {\mbox {V-A}3}BLE Vulnerability}{2}{}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {V-B}}Code integrity}{2}{}\protected@file@percent }
\@writefile{toc}{\contentsline {subsubsection}{\numberline {\mbox {V-B}1}Context}{2}{}\protected@file@percent }
\@writefile{toc}{\contentsline {subsubsection}{\numberline {\mbox {V-B}2}LispBM extraction}{2}{}\protected@file@percent }
\@writefile{toc}{\contentsline {subsubsection}{\numberline {\mbox {V-B}3}LispBM Code}{2}{}\protected@file@percent }
\@writefile{toc}{\contentsline {subsubsection}{\numberline {\mbox {V-B}4}Proposed Solution}{2}{}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {V-C}}VESC Compiling}{2}{}\protected@file@percent }
\@writefile{toc}{\contentsline {section}{\numberline {VI}Discussion}{2}{}\protected@file@percent }
\bibcite{b1}{1}
\bibcite{b2}{2}
\@writefile{toc}{\contentsline {section}{\numberline {VII}Results}{3}{}\protected@file@percent }
\@writefile{toc}{\contentsline {section}{\numberline {VIII}Conclusion/Summary}{3}{}\protected@file@percent }
\@writefile{toc}{\contentsline {section}{References}{3}{}\protected@file@percent }
\gdef \@abspage@last{3}

311
Sécurité/main.log
View file

@ -1,22 +1,22 @@
This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023/Debian) (preloaded format=pdflatex 2026.4.14) 11 MAY 2026 16:39
This is pdfTeX, Version 3.141592653-2.6-1.40.22 (TeX Live 2022/dev/Debian) (preloaded format=pdflatex 2026.3.16) 12 MAY 2026 15:27
entering extended mode
restricted \write18 enabled.
%&-line parsing enabled.
**main.tex
(./main.tex
LaTeX2e <2023-11-01> patch level 1
L3 programming layer <2024-01-22>
LaTeX2e <2021-11-15> patch level 1
L3 programming layer <2022-01-21>
(/usr/share/texlive/texmf-dist/tex/latex/ieeetran/IEEEtran.cls
Document Class: IEEEtran 2015/08/26 V1.8b by Michael Shell
-- See the "IEEEtran_HOWTO" manual for usage information.
-- http://www.michaelshell.org/tex/ieeetran/
\@IEEEtrantmpdimenA=\dimen140
\@IEEEtrantmpdimenB=\dimen141
\@IEEEtrantmpdimenC=\dimen142
\@IEEEtrantmpcountA=\count187
\@IEEEtrantmpcountB=\count188
\@IEEEtrantmpcountC=\count189
\@IEEEtrantmptoksA=\toks17
\@IEEEtrantmpdimenA=\dimen138
\@IEEEtrantmpdimenB=\dimen139
\@IEEEtrantmpdimenC=\dimen140
\@IEEEtrantmpcountA=\count185
\@IEEEtrantmpcountB=\count186
\@IEEEtrantmpcountC=\count187
\@IEEEtrantmptoksA=\toks16
LaTeX Font Info: Trying to load font information for OT1+ptm on input line 5
03.
(/usr/share/texlive/texmf-dist/tex/latex/psnfss/ot1ptm.fd
@ -24,11 +24,11 @@ File: ot1ptm.fd 2001/06/04 font definitions for OT1/ptm.
)
-- Using 8.5in x 11in (letter) paper.
-- Using PDF output.
\@IEEEnormalsizeunitybaselineskip=\dimen143
\@IEEEnormalsizeunitybaselineskip=\dimen141
-- This is a 10 point document.
\CLASSINFOnormalsizebaselineskip=\dimen144
\CLASSINFOnormalsizeunitybaselineskip=\dimen145
\IEEEnormaljot=\dimen146
\CLASSINFOnormalsizebaselineskip=\dimen142
\CLASSINFOnormalsizeunitybaselineskip=\dimen143
\IEEEnormaljot=\dimen144
LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <5> not available
(Font) Font shape `OT1/ptm/b/n' tried instead on input line 1090.
LaTeX Font Info: Font shape `OT1/ptm/bx/it' in size <5> not available
@ -79,40 +79,40 @@ LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <24> not available
LaTeX Font Info: Font shape `OT1/ptm/bx/it' in size <24> not available
(Font) Font shape `OT1/ptm/b/it' tried instead on input line 1090.
\IEEEquantizedlength=\dimen147
\IEEEquantizedlengthdiff=\dimen148
\IEEEquantizedtextheightdiff=\dimen149
\IEEEilabelindentA=\dimen150
\IEEEilabelindentB=\dimen151
\IEEEilabelindent=\dimen152
\IEEEelabelindent=\dimen153
\IEEEdlabelindent=\dimen154
\IEEElabelindent=\dimen155
\IEEEiednormlabelsep=\dimen156
\IEEEiedmathlabelsep=\dimen157
\IEEEiedtopsep=\skip48
\c@section=\count190
\c@subsection=\count191
\c@subsubsection=\count192
\c@paragraph=\count193
\c@IEEEsubequation=\count194
\abovecaptionskip=\skip49
\belowcaptionskip=\skip50
\c@figure=\count195
\c@table=\count196
\@IEEEeqnnumcols=\count197
\@IEEEeqncolcnt=\count198
\@IEEEsubeqnnumrollback=\count199
\@IEEEquantizeheightA=\dimen158
\@IEEEquantizeheightB=\dimen159
\@IEEEquantizeheightC=\dimen160
\@IEEEquantizeprevdepth=\dimen161
\@IEEEquantizemultiple=\count266
\@IEEEquantizeboxA=\box51
\@IEEEtmpitemindent=\dimen162
\IEEEPARstartletwidth=\dimen163
\c@IEEEbiography=\count267
\@IEEEtranrubishbin=\box52
\IEEEquantizedlength=\dimen145
\IEEEquantizedlengthdiff=\dimen146
\IEEEquantizedtextheightdiff=\dimen147
\IEEEilabelindentA=\dimen148
\IEEEilabelindentB=\dimen149
\IEEEilabelindent=\dimen150
\IEEEelabelindent=\dimen151
\IEEEdlabelindent=\dimen152
\IEEElabelindent=\dimen153
\IEEEiednormlabelsep=\dimen154
\IEEEiedmathlabelsep=\dimen155
\IEEEiedtopsep=\skip47
\c@section=\count188
\c@subsection=\count189
\c@subsubsection=\count190
\c@paragraph=\count191
\c@IEEEsubequation=\count192
\abovecaptionskip=\skip48
\belowcaptionskip=\skip49
\c@figure=\count193
\c@table=\count194
\@IEEEeqnnumcols=\count195
\@IEEEeqncolcnt=\count196
\@IEEEsubeqnnumrollback=\count197
\@IEEEquantizeheightA=\dimen156
\@IEEEquantizeheightB=\dimen157
\@IEEEquantizeheightC=\dimen158
\@IEEEquantizeprevdepth=\dimen159
\@IEEEquantizemultiple=\count198
\@IEEEquantizeboxA=\box50
\@IEEEtmpitemindent=\dimen160
\IEEEPARstartletwidth=\dimen161
\c@IEEEbiography=\count199
\@IEEEtranrubishbin=\box51
)
** ATTENTION: Overriding command lockouts (line 2).
(/usr/share/texlive/texmf-dist/tex/latex/cite/cite.sty
@ -121,8 +121,8 @@ LaTeX Info: Redefining \nocite on input line 332.
Package: cite 2015/02/27 v 5.5
)
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsmath.sty
Package: amsmath 2023/05/13 v2.17o AMS math features
\@mathmargin=\skip51
Package: amsmath 2021/10/15 v2.17l AMS math features
\@mathmargin=\skip50
For additional information on amsmath, use the `?' option.
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amstext.sty
@ -130,63 +130,53 @@ Package: amstext 2021/08/26 v2.01 AMS text
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsgen.sty
File: amsgen.sty 1999/11/30 v2.0 generic functions
\@emptytoks=\toks18
\ex@=\dimen164
\@emptytoks=\toks17
\ex@=\dimen162
))
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsbsy.sty
Package: amsbsy 1999/11/29 v1.2d Bold Symbols
\pmbraise@=\dimen165
\pmbraise@=\dimen163
)
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsopn.sty
Package: amsopn 2022/04/08 v2.04 operator names
Package: amsopn 2021/08/26 v2.02 operator names
)
\inf@bad=\count268
\inf@bad=\count266
LaTeX Info: Redefining \frac on input line 234.
\uproot@=\count269
\leftroot@=\count270
\uproot@=\count267
\leftroot@=\count268
LaTeX Info: Redefining \overline on input line 399.
LaTeX Info: Redefining \colon on input line 410.
\classnum@=\count271
\DOTSCASE@=\count272
\classnum@=\count269
\DOTSCASE@=\count270
LaTeX Info: Redefining \ldots on input line 496.
LaTeX Info: Redefining \dots on input line 499.
LaTeX Info: Redefining \cdots on input line 620.
\Mathstrutbox@=\box53
\strutbox@=\box54
LaTeX Info: Redefining \big on input line 722.
LaTeX Info: Redefining \Big on input line 723.
LaTeX Info: Redefining \bigg on input line 724.
LaTeX Info: Redefining \Bigg on input line 725.
\big@size=\dimen166
\Mathstrutbox@=\box52
\strutbox@=\box53
\big@size=\dimen164
LaTeX Font Info: Redeclaring font encoding OML on input line 743.
LaTeX Font Info: Redeclaring font encoding OMS on input line 744.
\macc@depth=\count273
LaTeX Info: Redefining \bmod on input line 905.
LaTeX Info: Redefining \pmod on input line 910.
LaTeX Info: Redefining \smash on input line 940.
LaTeX Info: Redefining \relbar on input line 970.
LaTeX Info: Redefining \Relbar on input line 971.
\c@MaxMatrixCols=\count274
\macc@depth=\count271
\c@MaxMatrixCols=\count272
\dotsspace@=\muskip16
\c@parentequation=\count275
\dspbrk@lvl=\count276
\tag@help=\toks19
\row@=\count277
\column@=\count278
\maxfields@=\count279
\andhelp@=\toks20
\eqnshift@=\dimen167
\alignsep@=\dimen168
\tagshift@=\dimen169
\tagwidth@=\dimen170
\totwidth@=\dimen171
\lineht@=\dimen172
\@envbody=\toks21
\multlinegap=\skip52
\multlinetaggap=\skip53
\mathdisplay@stack=\toks22
LaTeX Info: Redefining \[ on input line 2953.
LaTeX Info: Redefining \] on input line 2954.
\c@parentequation=\count273
\dspbrk@lvl=\count274
\tag@help=\toks18
\row@=\count275
\column@=\count276
\maxfields@=\count277
\andhelp@=\toks19
\eqnshift@=\dimen165
\alignsep@=\dimen166
\tagshift@=\dimen167
\tagwidth@=\dimen168
\totwidth@=\dimen169
\lineht@=\dimen170
\@envbody=\toks20
\multlinegap=\skip51
\multlinetaggap=\skip52
\mathdisplay@stack=\toks21
LaTeX Info: Redefining \[ on input line 2938.
LaTeX Info: Redefining \] on input line 2939.
)
(/usr/share/texlive/texmf-dist/tex/latex/amsfonts/amssymb.sty
Package: amssymb 2013/01/14 v3.01 AMS font symbols
@ -203,24 +193,24 @@ LaTeX Font Info: Overwriting math alphabet `\mathfrak' in version `bold'
Package: algorithmic 2009/08/24 v0.1 Document Style `algorithmic'
(/usr/share/texlive/texmf-dist/tex/latex/base/ifthen.sty
Package: ifthen 2022/04/13 v1.1d Standard LaTeX ifthen package (DPC)
Package: ifthen 2020/11/24 v1.1c Standard LaTeX ifthen package (DPC)
)
(/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
Package: keyval 2022/05/29 v1.15 key=value parser (DPC)
\KV@toks@=\toks23
Package: keyval 2014/10/28 v1.15 key=value parser (DPC)
\KV@toks@=\toks22
)
\c@ALC@unique=\count280
\c@ALC@line=\count281
\c@ALC@rem=\count282
\c@ALC@depth=\count283
\ALC@tlm=\skip54
\algorithmicindent=\skip55
\c@ALC@unique=\count278
\c@ALC@line=\count279
\c@ALC@rem=\count280
\c@ALC@depth=\count281
\ALC@tlm=\skip53
\algorithmicindent=\skip54
)
(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
Package: graphicx 2021/09/16 v1.2d Enhanced LaTeX Graphics (DPC,SPQR)
(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
Package: graphics 2022/03/10 v1.4e Standard LaTeX Graphics (DPC,SPQR)
Package: graphics 2021/03/04 v1.4d Standard LaTeX Graphics (DPC,SPQR)
(/usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty
Package: trig 2021/08/11 v1.11 sin cos tan (DPC)
@ -231,39 +221,37 @@ File: graphics.cfg 2016/06/04 v1.11 sample graphics configuration
Package graphics Info: Driver file: pdftex.def on input line 107.
(/usr/share/texlive/texmf-dist/tex/latex/graphics-def/pdftex.def
File: pdftex.def 2022/09/22 v1.2b Graphics/color driver for pdftex
File: pdftex.def 2020/10/05 v1.2a Graphics/color driver for pdftex
))
\Gin@req@height=\dimen173
\Gin@req@width=\dimen174
\Gin@req@height=\dimen171
\Gin@req@width=\dimen172
)
(/usr/share/texlive/texmf-dist/tex/latex/base/textcomp.sty
Package: textcomp 2020/02/02 v2.0n Standard LaTeX package
)
(/usr/share/texlive/texmf-dist/tex/latex/xcolor/xcolor.sty
Package: xcolor 2023/11/15 v3.01 LaTeX color extensions (UK)
Package: xcolor 2021/10/31 v2.13 LaTeX color extensions (UK)
(/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/color.cfg
File: color.cfg 2016/01/02 v1.6 sample color configuration
)
Package xcolor Info: Driver file: pdftex.def on input line 274.
(/usr/share/texlive/texmf-dist/tex/latex/graphics/mathcolor.ltx)
Package xcolor Info: Model `cmy' substituted by `cmy0' on input line 1350.
Package xcolor Info: Model `hsb' substituted by `rgb' on input line 1354.
Package xcolor Info: Model `RGB' extended on input line 1366.
Package xcolor Info: Model `HTML' substituted by `rgb' on input line 1368.
Package xcolor Info: Model `Hsb' substituted by `hsb' on input line 1369.
Package xcolor Info: Model `tHsb' substituted by `hsb' on input line 1370.
Package xcolor Info: Model `HSB' substituted by `hsb' on input line 1371.
Package xcolor Info: Model `Gray' substituted by `gray' on input line 1372.
Package xcolor Info: Model `wave' substituted by `hsb' on input line 1373.
Package xcolor Info: Driver file: pdftex.def on input line 227.
Package xcolor Info: Model `cmy' substituted by `cmy0' on input line 1352.
Package xcolor Info: Model `hsb' substituted by `rgb' on input line 1356.
Package xcolor Info: Model `RGB' extended on input line 1368.
Package xcolor Info: Model `HTML' substituted by `rgb' on input line 1370.
Package xcolor Info: Model `Hsb' substituted by `hsb' on input line 1371.
Package xcolor Info: Model `tHsb' substituted by `hsb' on input line 1372.
Package xcolor Info: Model `HSB' substituted by `hsb' on input line 1373.
Package xcolor Info: Model `Gray' substituted by `gray' on input line 1374.
Package xcolor Info: Model `wave' substituted by `hsb' on input line 1375.
)
(/usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
File: l3backend-pdftex.def 2024-01-04 L3 backend support: PDF output (pdfTeX)
\l__color_backend_stack_int=\count284
\l__pdf_internal_box=\box55
File: l3backend-pdftex.def 2022-01-12 L3 backend support: PDF output (pdfTeX)
\l__color_backend_stack_int=\count282
\l__pdf_internal_box=\box54
)
No file main.aux.
(./main.aux)
\openout1 = `main.aux'.
LaTeX Font Info: Checking defaults for OML/cmm/m/it on input line 12.
@ -280,20 +268,21 @@ LaTeX Font Info: Checking defaults for OMX/cmex/m/n on input line 12.
LaTeX Font Info: ... okay on input line 12.
LaTeX Font Info: Checking defaults for U/cmr/m/n on input line 12.
LaTeX Font Info: ... okay on input line 12.
-- Lines per column: 56 (exact).
(/usr/share/texlive/texmf-dist/tex/context/base/mkii/supp-pdf.mkii
[Loading MPS to PDF converter (version 2006.09.02).]
\scratchcounter=\count285
\scratchdimen=\dimen175
\scratchbox=\box56
\nofMPsegments=\count286
\nofMParguments=\count287
\everyMPshowfont=\toks24
\MPscratchCnt=\count288
\MPscratchDim=\dimen176
\MPnumerator=\count289
\makeMPintoPDFobject=\count290
\everyMPtoPDFconversion=\toks25
\scratchcounter=\count283
\scratchdimen=\dimen173
\scratchbox=\box55
\nofMPsegments=\count284
\nofMParguments=\count285
\everyMPshowfont=\toks23
\MPscratchCnt=\count286
\MPscratchDim=\dimen174
\MPnumerator=\count287
\makeMPintoPDFobject=\count288
\everyMPtoPDFconversion=\toks24
) (/usr/share/texlive/texmf-dist/tex/latex/epstopdf-pkg/epstopdf-base.sty
Package: epstopdf-base 2020-01-24 v2.11 Base part for package epstopdf
Package epstopdf-base Info: Redefining graphics rule for `.eps' on input line 4
@ -303,21 +292,17 @@ Package epstopdf-base Info: Redefining graphics rule for `.eps' on input line 4
File: epstopdf-sys.cfg 2010/07/13 v1.3 Configuration of (r)epstopdf for TeX Liv
e
))
[1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}{/usr/share/texlive/texmf-
dist/fonts/enc/dvips/base/8r.enc}
[1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}
]
Underfull \hbox (badness 5756) in paragraph at lines 93--94
[]\OT1/ptm/m/n/10 VESC-controllers are not nec-es-sar-ily equipped with
[]
LaTeX Font Info: Trying to load font information for U+msa on input line 114
] [2]
LaTeX Font Info: Trying to load font information for U+msa on input line 249
.
(/usr/share/texlive/texmf-dist/tex/latex/amsfonts/umsa.fd
File: umsa.fd 2013/01/14 v3.01 AMS symbols A
)
LaTeX Font Info: Trying to load font information for U+msb on input line 114
LaTeX Font Info: Trying to load font information for U+msb on input line 249
.
(/usr/share/texlive/texmf-dist/tex/latex/amsfonts/umsb.fd
@ -334,33 +319,27 @@ Before submitting the final camera ready copy, remember to:
uses only Type 1 fonts and that every step in the generation
process uses the appropriate paper size.
[2] (./main.aux)
***********
LaTeX2e <2023-11-01> patch level 1
L3 programming layer <2024-01-22>
***********
[3
LaTeX Warning: Label(s) may have changed. Rerun to get cross-references right.
)
] (./main.aux) )
Here is how much of TeX's memory you used:
4156 strings out of 474222
64575 string characters out of 5748733
1941975 words of memory out of 5000000
26378 multiletter control sequences out of 15000+600000
594898 words of font info for 107 fonts, out of 8000000 for 9000
4108 strings out of 478287
63874 string characters out of 5849289
373466 words of memory out of 5000000
22284 multiletter control sequences out of 15000+600000
500325 words of font info for 84 fonts, out of 8000000 for 9000
1141 hyphenation exceptions out of 8191
57i,8n,65p,1925b,266s stack positions out of 10000i,1000n,20000p,200000b,200000s
</usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi10.pfb></us
r/share/texlive/texmf-dist/fonts/type1/urw/times/utmb8a.pfb></usr/share/texlive
/texmf-dist/fonts/type1/urw/times/utmbi8a.pfb></usr/share/texlive/texmf-dist/fo
nts/type1/urw/times/utmr8a.pfb></usr/share/texlive/texmf-dist/fonts/type1/urw/t
imes/utmri8a.pfb>
Output written on main.pdf (2 pages, 74641 bytes).
55i,8n,62p,227b,266s stack positions out of 5000i,500n,10000p,200000b,80000s
{/usr/share/texlive/texmf-dist/fonts/enc/dvips/base/8r.enc}</us
r/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi10.pfb></usr/shar
e/texlive/texmf-dist/fonts/type1/urw/times/utmb8a.pfb></usr/share/texlive/texmf
-dist/fonts/type1/urw/times/utmbi8a.pfb></usr/share/texlive/texmf-dist/fonts/ty
pe1/urw/times/utmr8a.pfb></usr/share/texlive/texmf-dist/fonts/type1/urw/times/u
tmri8a.pfb>
Output written on main.pdf (3 pages, 78941 bytes).
PDF statistics:
37 PDF objects out of 1000 (max. 8388607)
22 compressed objects within 1 object stream
40 PDF objects out of 1000 (max. 8388607)
24 compressed objects within 1 object stream
0 named destinations out of 1000 (max. 500000)
1 words of extra memory for PDF output out of 10000 (max. 10000000)

BIN
Sécurité/main.pdf
View file

Binary file not shown.

BIN
Sécurité/main.synctex.gz
View file

Binary file not shown.

168
Sécurité/main.tex
View file

@ -11,60 +11,76 @@
T\kern-.1667em\lower.7ex\hbox{E}\kern-.125emX}}
\begin{document}
\title{Improving the MAD Max\\
\thanks{laMAD}
\title{
Design and Implementation of a High-Power Motor Controller for Bicycles
}
%\maketitle
\author{\IEEEauthorblockN{Hugo Abescat}
\IEEEauthorblockA{\textit{GEI} \\
\IEEEauthorblockA{\textit{GEI Department} \\
\textit{INSA Toulouse}\\
Toulouse, France \\
Abescat@insa-toulouse.fr}
%\and
abescat@insa-toulouse.fr}
\and
\IEEEauthorblockN{Karima Attar}
\IEEEauthorblockA{\textit{GEI} \\
\IEEEauthorblockA{\textit{GEI Department} \\
\textit{INSA Toulouse}\\
Toulouse, France \\
Attar@insa-toulouse.fr}
karima.attar@insa-toulouse.fr}
\and
\IEEEauthorblockN{Brage Flønæs Johnsen}
\IEEEauthorblockA{\textit{GEI} \\
\IEEEauthorblockA{\textit{GEI Department} \\
\textit{INSA Toulouse}\\
Toulouse, France \\
Johnse@insa-toulouse.fr}
%\and
johnse@insa-toulouse.fr}
\and
\IEEEauthorblockN{Oskar Orvik}
\IEEEauthorblockA{\textit{GEI} \\
\IEEEauthorblockA{\textit{GEI Department} \\
\textit{INSA Toulouse}\\
Toulouse, France \\
Orvik@insa-toulouse.fr\\}
%\and
orvik@insa-toulouse.fr}
\and
\IEEEauthorblockN{Julien Pavillon}
\IEEEauthorblockA{\textit{GEI} \\
\IEEEauthorblockA{\textit{GEI Department} \\
\textit{INSA Toulouse}\\
Toulouse, France \\
Pavillon@insa-toulouse.fr}
pavillon@insa-toulouse.fr}
\and
\IEEEauthorblockN{Nolan Reynier Nomer}
\IEEEauthorblockA{\textit{GEI} \\
\IEEEauthorblockA{\textit{GEI Department} \\
\textit{INSA Toulouse}\\
Toulouse, France \\
nomer@insa-toulouse.fr}
%\and
reynier-nome@insa-toulouse.fr}
\and
\IEEEauthorblockN{Aleksander Taban}
\IEEEauthorblockA{\textit{GEI} \\
\IEEEauthorblockA{\textit{GEI Department} \\
\textit{INSA Toulouse}\\
Toulouse, France \\
Taban@insa-toulouse.fr}
taban@insa-toulouse.fr}
}
\maketitle
\begin{abstract}
Electric bikes are becoming an increasingly attractive solution for transporting goods between short distances, especially in city-wide infrastructures. However, most commercially available controllers rely on complex integrated circuits making repair and local manufacturing difficult, particularly for organisations operating in resource-constrained or low-tech environments. La Manufacture Autonome Décentralisée (LaMAD) is developing products and solutions, particularly e-bikes, which are more repairable and sustainable. Previous studies have predominantly focused on performance optimisation of Field Oriented Control (FOC) and trapezoidal commutation strategies, with limited attention to repairability, component sourcing, and community-centred sustainability criteria. This project aims to design, assemble, and develop a functional, low-tech and open-source motor controller for electric cargo bikes. The current model uses an open-source motor control called VESC (Vedder Electronic Speed Controller) that allows precise control of electric motors. The controller needs to be compatible with a VESC controller and easily locally repairable by LaMAD. By exploring the inner workings of the VESC project, modelling of the physical systems and the Printed Circuit Board, PCB, we investigated the ways we could do it in another way. We acquired a VESC controller to compare our system and a commercial product. Preliminary results demonstrate that the adapted VESC-based controller successfully drives the target motor under both commutation strategies, and that positional control is achievable with the current hardware configuration. Security vulnerabilities related to open Bluetooth access were identified. These findings suggest that open-source, locally fabricated motor controllers can meet the functional requirements of electric cargo bikes while significantly improving repairability.
Electric bikes are becoming an increasingly attractive solution for transporting goods between short distances,
especially in city-wide infrastructures. However, most commercially available controllers rely on complex integrated
circuits making repair and local manufacturing difficult, particularly for organisations operating in
resource-constrained or low-tech environments. La Manufacture Autonome Décentralisée (LaMAD) is developing products
and solutions, particularly e-bikes, which are more repairable and sustainable. Previous studies have predominantly
focused on performance optimisation of Field Oriented Control (FOC) and trapezoidal commutation strategies, with limited
attention to repairability, component sourcing, and community-centred sustainability criteria. This project aims to
design, assemble, and develop a functional, low-tech and open-source motor controller for electric cargo bikes. The
current model uses an open-source motor control called VESC (Vedder Electronic Speed Controller) that allows precise
control of electric motors. The controller needs to be compatible with a VESC controller and easily locally repairable
by LaMAD. By exploring the inner workings of the VESC project, modelling of the physical systems and the Printed Circuit
Board, PCB, we investigated the ways we could do it in another way. We acquired a VESC controller to compare our system
and a commercial product. Preliminary results demonstrate that the adapted VESC-based controller successfully drives
the target motor under both commutation strategies, and that positional control is achievable with the current hardware
configuration. Security vulnerabilities related to open Bluetooth access were identified. These findings suggest that
open-source, locally fabricated motor controllers can meet the functional requirements of electric cargo bikes while
significantly improving repairability.
\end{abstract}
\begin{IEEEkeywords}
@ -72,71 +88,139 @@ VESC Project, Brushless DC motor, Field Oriented Control, Trapezoidal commutatio
\end{IEEEkeywords}
\section{Introduction}
The fast urbanization of global logistics has positioned electric cargo bikes as a primary solution. At the heart of these vehicles is the motor controller. Current research and industry standards primarily focus on two methods of commutation for the controller: Trapezoidal commutation and Field Oriented Control (FOC).
The fast urbanization of global logistics has positioned electric cargo bikes as a primary solution. At the heart of
these vehicles is the motor controller. Current research and industry standards primarily focus on two methods of
commutation for the controller: Trapezoidal commutation and Field Oriented Control (FOC).
As motor controllers become smarter, they increasingly incorporate wireless connectivity for tuning and diagnostics. Current research highlights that while Bluetooth Low Energy (BLE) and mobile app integration improve user experience, they often introduce vulnerabilities. Open-source projects, in particular, must balance ease of access for community developers with the need to secure the vehicle.
As motor controllers become smarter, they increasingly incorporate wireless connectivity for tuning and diagnostics.
Current research highlights that while Bluetooth Low Energy (BLE) and mobile app integration improve user experience,
they often introduce vulnerabilities. Open-source projects, in particular, must balance ease of access for community
developers with the need to secure the vehicle.
We also argue the need for general public's safety when it comes to these bikes, as it could be a danger to the traffic.
This is especially true when it comes to vehicules carrying a substantial load. This needs to be considered by laMAD,
where their responsibility and control begins and ends. Should there be a difference between the firmware loaded on a
product from laMAD than what is publicly available?
We also argue the need for general public's safety when it comes to these bikes, as it could be a danger to the traffic. This is especially true when it comes to vehicules carrying a substantial load. This needs to be considered by laMAD, where their responsibility and control begins and ends. Should there be a difference between the firmware loaded on a product from laMAD than what is publicly available?
\section{Litterature review}
\section{Research gap}
Despite this progress, limited research has examined the adaptation of open-source motor controllers to LowTech and repairability constraints. To date, researchers have not addressed the challenge of designing a controller that can be locally fabricated, repaired with standard components, and secured against unauthorised wireless access requirements that are critical for decentralised, community-operated fleets.
Despite this progress, limited research has examined the adaptation of open-source motor controllers to LowTech and
repairability constraints. To date, researchers have not addressed the challenge of designing a controller that can
be locally fabricated, repaired with standard components, and secured against unauthorised wireless access requirements
that are critical for decentralised, community-operated fleets.
\section{The aim of the study}
This report presents the design and implementation of a VESC-based motor controller tailored to the needs of the Manufacture Autonome Décentralisée (MAD), an organisation operating electric cargo bikes and freight tricycles. We aim to focus on adapting the VESC open-source firmware to support both FOC and trapezoidal commutation, integrating positional control, and addressing Bluetooth security, while prioritising local manufacturability at INSA Toulouse.
This report presents the design and implementation of a VESC-based motor controller tailored to the needs of the
Manufacture Autonome Décentralisée (MAD), an organisation operating electric cargo bikes and freight tricycles.
We aim to focus on adapting the VESC open-source firmware to support both FOC and trapezoidal commutation, integrating
positional control, and addressing Bluetooth security, while prioritising local manufacturability at INSA Toulouse.
\section{Software and Connectivity}
\subsection{BLE Compatibility With the VESC}
\subsubsection{First Experiment}
VESC-controllers are not necessarily equipped with Bluetooth-modules by default. Often, it is necessary to add a BLE-module. A standard HC-05 bluetooth-module compatible with arduino is a great way to send and recieve bluetooth-packets from a host, e.g. a mobile phone, via a bridge translating the bluetooth packets to the UART protocol. This could be demonstrated using a ESP8622's standard library with said module, by letting us send characters from one device to another.
VESC-controllers are not necessarily equipped with Bluetooth-modules by default. Often, it is necessary to add a
BLE-module. A standard HC-05 bluetooth-module compatible with arduino is a great way to send and recieve
bluetooth-packets from a host, e.g. a mobile phone, via a bridge translating the bluetooth packets to the UART protocol.
This could be demonstrated using a ESP8622's standard library with said module, by letting us send characters from one
device to another.
\subsubsection{HC-05 and the VESC}
By flashing the VESC firmware on a discovery-card and connecting the HC-05 module to the PB10 and PB11-pins, which are the Rx and Tx-pins for the STM32F4xx chip, we discovered that the setup for the bluetooth module was not available in the VESC tool. The inherent BLE capabilities is an important limitation to consider when designing a VESC system.
We learned therefore that the HC-05 is not originally adapted for BLE. The need for a bridge also adds on complexity and cost, in the form of extra components and another device to maintain the code of. For the future, choosing a bluetooth module supporting BLE will be the easiest solution. Preferably a module fitting the communication connector on the cheap FOCer project\cite{b1} could facilitate the relevancy of the PCB project with a microcontroller.
By flashing the VESC firmware on a discovery-card and connecting the HC-05 module to the PB10 and PB11-pins, which are
the Rx and Tx-pins for the STM32F4xx chip, we discovered that the setup for the bluetooth module was not available in
the VESC tool. The inherent BLE capabilities is an important limitation to consider when designing a VESC system.
We learned therefore that the HC-05 is not originally adapted for BLE. The need for a bridge also adds on complexity
and cost, in the form of extra components and another device to maintain the code of. For the future, choosing a
bluetooth module supporting BLE will be the easiest solution. Preferably a module fitting the communication connector on
the cheap FOCer project\cite{b1} could facilitate the relevancy of the PCB project with a microcontroller.
\subsubsection{BLE Vulnerability}
Bluetooth could be a vulnerability to a VESC if it is to be used as a controller in real-time, as the controller could be jammed. Our test with the Flipper Zero shows the disfunctionnality of Bluetooth with different use cases. We experienced with the jamming of a bluetooth speaker that the music completely stopped. It could also be investigated how the connection to the VESC could be modified using the vesc tool. We will touch more on the accessability of the code within the vesc tool sooner.
Bluetooth could be a vulnerability to a VESC if it is to be used as a controller in real-time, as the controller could
be jammed. Our test with the Flipper Zero shows the disfunctionnality of Bluetooth with different use cases.
We experienced with the jamming of a bluetooth speaker that the music completely stopped. It could also be investigated
how the connection to the VESC could be modified using the vesc tool. We will touch more on the accessability of the
code within the vesc tool sooner.
\subsection{Code integrity}
\subsubsection{Context}
As the project is open source, and the code is freely accessible, there should be no reason to hide the code. It could however be reasonable to protect the code from changes which could hurt other people. Changing following parameters should at least come with a disclaimer and clearly state the dangers possible by proceeding with said changes. We have in mind the maximum speed permitted and the power available to the motors.
As the project is open source, and the code is freely accessible, there should be no reason to hide the code. It could
however be reasonable to protect the code from changes which could hurt other people. Changing following parameters
should at least come with a disclaimer and clearly state the dangers possible by proceeding with said changes. We
have in mind the maximum speed permitted and the power available to the motors.
\subsubsection{LispBM extraction}
We caugth word that the lisp code for the VESC used by Maillon mobility was easy to extract. By building an older firmware with the Maillon mobility software, we observed this by going to the lispBM tab and clicking read. It's up to laMAD if they would like to reinforce this mechanism. A modification on a parameter and then clicking upload allowed us to easily change the speed limit. This could bring up a public danger. This raises questions on the use of laMADs equipment which is in a traffic friendly manner.
We caugth word that the lisp code for the VESC used by Maillon mobility was easy to extract. By building an older
firmware with the Maillon mobility software, we observed this by going to the lispBM tab and clicking read. It's up to
laMAD if they would like to reinforce this mechanism. A modification on a parameter and then clicking upload allowed
us to easily change the speed limit. This could bring up a public danger. This raises questions on the use of laMADs
equipment which is in a traffic friendly manner.
\subsubsection{LispBM Code}
When we flashed newer firmware from the project made by Benjamin Vedder\cite{b1}, we also observed some difficulties in uploading the lispBM script taken from the one on firmware version 6.06. This could indicate that there needs to be further maintenance of the code in order to get the software up to speed. This needs to be documented better for someone to continue the project. This could be a good investment for laMAD as well in the context of training for the people working on the motor control part of the e-bike.
When we flashed newer firmware from the project made by Benjamin Vedder\cite{b1}, we also observed some difficulties in
uploading the lispBM script taken from the one on firmware version 6.06. This could indicate that there needs to be
further maintenance of the code in order to get the software up to speed. This needs to be documented better for someone
to continue the project. This could be a good investment for laMAD as well in the context of training for the people
working on the motor control part of the e-bike.
This documentation could be as simple as referencing the relevant parts of the lispBM documentation \cite{b2}
\subsubsection{Proposed Solution}
This risk could be patched by developing a VESC application for the VESC controller or using a binary. This is a solution which is less open source, but which is make unlawful use of the material harder. The application could be created using C and use an algorithm known by laMAD in order to securise the access to someone to change the parameters only if they are laMAD certified personnel. This encryption would preferably be reduced to the most essential settings in order to align with what our impression of the philosophy of laMAD would be.
This risk could be patched by developing a VESC application for the VESC controller or using a binary. This is a
solution which is less open source, but which is make unlawful use of the material harder. The application could be
created using C and use an algorithm known by laMAD in order to securise the access to someone to change the parameters
only if they are laMAD certified personnel. This encryption would preferably be reduced to the most essential settings
in order to align with what our impression of the philosophy of laMAD would be.
\subsection{VESC Compiling}
As mentionned, we have been able to compile the VESC tool and the VESC firmware. This firmware has been put onto an STM32F4xx Discovery card. This poses several obstacles for our progress on the topic of cybersecurity. We will however summarise what we have learned for you and propose some additional work for the future. The challenges we encountered were the following: The lack of bluetooth capabilities. We did not have a module with BLE either. We had access to a HC-05 module, but that only allows for a normal bluetooth protocol and would require further work on a bridge to UART by using an esp8622 that we had as well. We propose that the next group has access to a VESC controller from the beginning, as well as a motor we could control. This could be in cooperation with laMAD, as laMAD could propose some models they're interested in.
As mentionned, we have been able to compile the VESC tool and the VESC firmware. This firmware has been put onto an
STM32F4xx Discovery card. This poses several obstacles for our progress on the topic of cybersecurity. We will however
summarise what we have learned for you and propose some additional work for the future. The challenges we encountered
were the following: The lack of bluetooth capabilities. We did not have a module with BLE either. We had access to a
HC-05 module, but that only allows for a normal bluetooth protocol and would require further work on a bridge to UART
by using an esp8622 that we had as well. We propose that the next group has access to a VESC controller from the
beginning, as well as a motor we could control. This could be in cooperation with laMAD, as laMAD could propose
some models they're interested in.
We also found that the information on the VESC is scattered around the internet. The ressources is also sometimes based on a debian-based linux system which adds more work for someone using another distribution of linux. This could hinder the implementation facility for new users. We struggeled particularly with the Qt packages for positioning and gamepad. We would therefore recommend the use of a debian-based linux system for the computer working with the VESC for the laMAD associates.
We also found that the information on the VESC is scattered around the internet. The ressources is also sometimes
based on a debian-based linux system which adds more work for someone using another distribution of linux. This could
hinder the implementation facility for new users. We struggeled particularly with the Qt packages for positioning and
gamepad. We would therefore recommend the use of a debian-based linux system for the computer working with the VESC
for the laMAD associates.
\section{Discussion}
This project could be seen as an introduction to the VESC project for someone who don't know about it from beforehand, the challenges the new users face during setup, as well as a demand for clear expectations concerning documentation on the subject. The project laMAD is leading should probably not be a fork of the project, as the project is still in development.
This project could be seen as an introduction to the VESC project for someone who don't know about it from beforehand,
the challenges the new users face during setup, as well as a demand for clear expectations concerning documentation
on the subject. The project laMAD is leading should probably not be a fork of the project, as the project is still
in development.
As a final note, this proved to be a project which could easily be developed into several different projects in different fields. Some projects could be continued later on as a different PIR subject, other could be proposed to later years in different spesialisations like TLS SEC, ESPE. Our thoughts on the following projects that could be explored are the following.
As a final note, this proved to be a project which could easily be developed into several different projects in
different fields. Some projects could be continued later on as a different PIR subject, other could be proposed to
later years in different spesialisations like TLS SEC, ESPE. Our thoughts on the following projects that could be
explored are the following.
The fabrication line for electronics is globalised. This is okay in a stable world, but it could be a problem in a world full of instability, be it war, blockages, or tarifs. The idea of opening a spesialisation in cooperation with AIME came up as an idea.
The fabrication line for electronics is globalised. This is okay in a stable world, but it could be a problem in a world
full of instability, be it war, blockages, or tarifs. The idea of opening a spesialisation in cooperation with AIME came
up as an idea.
For TLS SEC the subject could be the design for a fitting mechanism to restrict certain priveligies to certified personnel that could be used in the C programming language. Later down the line we could also see the possibility to analyse the Bluetooth frames in order to manipulate them in order to change important parameters.
For TLS SEC the subject could be the design for a fitting mechanism to restrict certain priveligies to certified
personnel that could be used in the C programming language. Later down the line we could also see the possibility to
analyse the Bluetooth frames in order to manipulate them in order to change important parameters.
The continuation on the PCB could be a subject fitting an ESPE spesialisation.
The proposition of and supply of a vesc system to play with and troubleshoot could be a good rule of thumb, which allows for a quicker start and gives among other things an idea of the budget and the supply line used by a entity in the sector. Proposing a visit could also be one way to familiarise students with the association.
The proposition of and supply of a vesc system to play with and troubleshoot could be a good rule of thumb, which
allows for a quicker start and gives among other things an idea of the budget and the supply line used by a entity
in the sector. Proposing a visit could also be one way to familiarise students with the association.
What should be a clear conclusion from our test with the jammer is that a controlles based on Bluetooth alone should be avoided when possible and practical. Examples where this could be relevant include electric skateboards, as cables could impose a tripping hazard. There, an encapsulation of an encrypted control frame could be an thought.
What should be a clear conclusion from our test with the jammer is that a controlles based on Bluetooth alone should be
avoided when possible and practical. Examples where this could be relevant include electric skateboards, as cables could
impose a tripping hazard. There, an encapsulation of an encrypted control frame could be an thought.
\section{Results}