Master Thesis: Intentionally vulnerable infotainment system built on AGL #automotive #help
Dear AGL Community,
My name is Jakub and I plan to create a intentionally vulnerable infotainment system for demonstration purposes as my master's thesis. I will be using Raspberry Pi4 as hardware. Let me first point out that the vulnerabilities I plan to create and showcase will not be AGL-specific. My plan is to take a stable AGL version, develop/modify a couple of applications to make them vulnerable to the most common automotive security threats. These applications should be graphical, since the main purpose is demonstration.
I have spent past two weeks trying to get familiar with AGL and associated technologies, deployed a demo image to RPi4, installed standalone SDK and built a helloworld .wgt, which I failed to run so far. However, I am struggling to find any documentation on how to write, build and deploy graphical applications for AGL, how to make them work with the homescreen and so on. There's a big chance I am missing something fundamental, so in my first ask for help, I'd like to ask you if you could point me out on the resources that I just described I am after.
Any help is greatly appreciated,
Hi Jakub,toggle quoted messageShow quoted text
There are already a few demo apps which you can use either as an example on how to write new graphical apps (e.g https://gerrit.automotivelinux.org/gerrit/gitweb?p=apps/hvac.git;a=summary) or fork them and use for your purpose.
On Sun, Oct 18, 2020 at 11:45:41AM -0700, acsjakub@... wrote:
Dear AGL Community,Hi,
To some extent they will be AGL-specific. We make use a framework 
that handles application privileges and we use a LSM module  to handle
security at a global level.
a couple of applications to make them vulnerable to the most commonWhy? There are multiple parts in (infotainment) system, you can leverage
one against the other and escalate, or rather chain-load various
exploits -- which I believe is common/necessary to bypass mitigations.
If the purpose is to focus on the graphics system/sub-system, you need
to be aware that as opposed to X11, on wayland clients can not gain
access to other client's buffers. Also the demo platform/apps is a bit
more lax/permissive on purpose to allow easier development to happen, or
provide some functionality commonly found on other systems
(for instance, screenshooting, or the allow-all policy in the compositor).
Have you've taken a look some of the demo apps? Like
mediaplayer/hvac/dashboard/alexa-viewer? Some of these to not need any
additional 'graphical' interaction aside from what the toolkit (Qt)
provides. I mean, there's nothing special needed to be done. Yes, there
are cases where that might not be the case and you still some additional
support. Would suggest going over , if you would like to find out
more about that.
Deployment varies depending on you build, but it is going to be
something related to transferring your widget over the target board
using some kind of a networking tool (scp/nfs/ndb).
Also, have you taken a look at ? Some of that information might be
obsolete at this point, but nevertheless the workflow is the same. I
personally haven't used the SDK to create/builds application, rather I
use yocto/OE directly and scp to transfer it (the widget). I'm not
really sure, I guess the SDK should provide at least build tools
(cmake/qmake/meson) support. Maybe someone else can chime in if they
have more info on that matter. For system-type applications my
impression is that is always better to use yocto/OE, rather than
deploying packages, but that doesn't mean you can script your way
missing something fundamental, so in my first ask for help, I'd like https://docs.automotivelinux.org/docs/en/master/devguides/reference/iotbzh2016/03-AGL-AppFW-Privileges-Management.pdf
HI Bogdan and Marius ,
thank you for pointing me the right directions, I will definitely check these out! I must have missed them until now as I'm still learning to navigate through all the materials.
To some extent they will be AGL-specific. We make use a framework thank you, I am going to read  and  and make familiar with them and maybe come back with questions.
Why? There are multiple parts in (infotainment) system, you can leverageI'm sorry I probably wasn't very clear with this part. What I actually meant was that I want the applications to have a graphical user interface where the impact of the vulnerability can be presented to and understood by the non-technical audience, too. Not that the vulnerabilities will neccesarily have any graphical origin.
On demo being rather lax or permissive, thanks for pointing this out, I will have to discuss with my supervisor whether this is something we want to use to our advantage (it can simulate a misconfiguration problem) or whether we want to use fully-hardened image for the demonstration.
Have you've taken a look some of the demo apps? LikeThis is the next on the list, thanks for pointing that out, I was struggling to find the source codes to be honest.
Deployment varies depending on you build, but it is going to beyes, I was able to setup the xds as it was mentioned as a preferred way for development, I was also able to built using the standalone SDK as mentioned in the , however, I was wondering if these are still the preferred ways. Thank you for clarifying that. Also, I have no experience with yocto/OE, so that is another valuable piece of information there.
Overall, I am very grateful for your insight, and there's a lot of code reading and studying of what you mentioned in front of me, but this is generally what I was after, since I was drowning in the sea of different materials finding it hard to distinguish the relevant from the irrelevant.
To wrap up, thank you once more, I believe this has already been a huge help!
Fulup Ar Foll
To get a good introduction on AGL security Module, you may check the training Jose gave last year at Brest University class https://iot.bzh/en/publications/38-2019/101-lesson-ensta-2019
On 19/10/2020 17:54, acsjakub@... wrote:
HI Bogdan and Marius ,