Syftet med denna studie är utforska möjligheterna att återanvända modellkod, skriven i C, över flera plattformar, nämligen iOS, Android och HTML5. Målet är att undersöka kodstorlek och komplexitet vid återanvändning av modellkod skriven i C på plattformarna. Genom en noggrann granskning av tidigare forskning och existerande metoder identifierades lämpliga verktyg och metoder. Det som framkom är att WebAssembly var det rekommenderade verktyget för att koppla C- kod till HTML5. För Android var Java Native Interface (JNI) det mest lämpliga verktyget för att koppla C-kod till Kotlin. Swift, å andra sidan, har inbyggda verktyg för interoperabilitet som möjliggör koppling mellan Swift-kod och C. Därav påvisade resultaten att det är möjligt att återanvända modellkod skriven i C på Android, iOS och HTML5. Dock, för Android krävdes det tillsats av extra kod för att hantera kopplingen mellan Kotlin och C-modellkod. Eftersom dessa språk hanterar datatyper och minneshantering på olika sätt. Inom iOS krävdes inte lika mycket extra kod som på Android för att hantera kopplingen mellan Swift och C eftersom Swift är utvecklat med naturligt stöd för C. I HTML5 behövdes inte lika mycket extra kod som på Swift och Android eftersom Emscripten möjliggjorde automatisk generering av en omvandling från modellkod skriven i C till JavaScript. Detta underlättade utvecklandet av bindningen mellan C-baserad modellkod och HTML5-applikationen. / The purpose of this study was to explore the possibilities of reusing model code, written in C, across multiple platforms, specifically iOS, Android, and HTML5. The objective was to investigate code size and complexity when reusing model code written in C on these platforms. Through a thorough review of previous research and existing methods, suitable tools and methods were identified. It was found that WebAssembly was the recommended tool for linking C code to HTML5. For Android, the Java Native Interface (JNI) was the most appropriate tool for linking C code to Kotlin. Swift, on the other hand, has built-in tools for interoperability that allow for the connection between Swift code and C. The results indicated that it is possible to reuse model code written in C on Android, iOS, and HTML5. For Android, additional code was required to manage the connection between Kotlin and C model code, as these languages handle data types and memory management differently. However, within iOS, there was not needed additional code compared to Android, to manage the linkage between Swift and C. Since Swift is developed with inherent support for C. For HTML5, there was not as much additional code required as in Swift and Android, primarily because Emscripten enabled automatic conversion of model code written in C to JavaScript. This facilitated the development of the binding between C-based model code and the HTML5 application.

Blockchain-based cryptocurrencies is a fairly new concept with a worldwide spread, and there is a massive amount of currencies. Several of them involve so-called currency mining, a feature of Proof-of-Work based blockchains. One problem with currency mining is that it can be performed when visiting websites in the user's browser, exploiting the user's resources and consuming energy. This has spawned a wide variety of crypto mining detection algorithms in the research. A particular issue that can make detection difficult is if the code of the miner has been obfuscated. Because of the limited research on detecting obfuscated miners, this thesis selects a state-of-the-art detection algorithm and uses it to analyze crypto miners obfuscated with various obfuscation techniques. A dataset of Wasm binaries is constructed by filtering out miners with the help of the detection algorithm. The result indicates that multiple obfuscation techniques, all trivial to implement with basic find-and-replacement, are highly effective at hindering the miner detector. Some techniques lower the detection rate by 100% on the dataset. The effectiveness seems to depend primarily on how many lines are modified in the program, and secondly on what modifications exactly are performed. Also, the obfuscated samples do not take a longer time to analyze, on the contrary, the mean execution time of the detection algorithm becomes primarily shorter. The conclusion is that more research must be done in constructing detection algorithms robust towards code obfuscation, and that the detection rate of today's algorithms might be misleading if there is a large amount of obfuscated miners on the web. / Blockkedjebaserade kryptovalutor är ett relativt nytt koncept som spridit sig globalt, och det finns en uppsjö med kryptovalutor. Flera av dem involverar mining (”valutagrävning”), en företeelse hos Proof-of-work-baserade blockkedjor. Ett problem med mining är att det kan genomföras när en användare besöker webbsidor i webbläsaren, och därmed utnyttja användarens resurser och förbruka onödig energi. Detta har lett till forskning på flera olika typer av detektorer för mining. Ett särskilt problem som kan försvåra detektering är om miner-koden har obfuskerats. På grund av den begränsade forskningen på att detektera obfuskerade miner-program väljs i detta examensarbete en state-of-the-art-algoritm för detektering, och denna används för att analysera miner-program obfuskerade med olika obfuskeringstekniker. Ett dataset av Wasm-binärer konstrueras genom att filtrera ut miner-program med hjälp av detekteringsalgoritmen. Resultatet indikerar att flera obfuskeringstekniker, samtliga triviala att implementera med grundläggande hitta-och-ersätt-operationer, är mycket effektiva för att hindra detektorn. Vissa tekniker minskar detekteringsgraden med 100% på det dataset som används. Effektiviteten verkar primärt bero på hur många rader som är modifierade i programmet, och sekundärt på exakt vad för slags modifikation som genomförs. Dessutom tar de obfuskerade programmen inte längre tid att analysera, i själva verket är genomsnittstiden för detekteringsalgoritmen i huvudsak kortare jämfört med de ej obfuskerade. Slutsatsen är att mer forskning måste genomföras för att konstruera detekteringsalgoritmer som är robusta mot kodobfuskering, och detekteringsgraden hos dagens detekteringsalgoritmer kan vara vilseledande om det finns en stor mängd obfuskerade miner-program på webben.

One of the latest tools in the strive troughwards a fast and secure Web is called WebAssembly. It is a low-level, assembly-like language that can run in the browser alongside JavaScript. WebAssembly is designed to load fast and aims to execute at near-native speed. Being a compilation target for system languages like C, C++, and Rust, WebAssembly is not very accessible from a Web developer perspective. This project explores ways to generate WebAssembly directly from JavaScript code, in order to lower the learning curve, and allow for a more widespread adoption of WebAssembly. This has resulted in a utility tool called Esmbly, which can turn simple JavaScript programs into WebAssembly binaries by collecting and utilizing type information from various flavours of statically typed JavaScript.

This paper will explore the speed of execution, memory foot-print and the maturity of WebAssembly Runtimes (WasmRT).For this study, the WasmRT will be Wasmer1and Wasmtime.2Initially, benchmarks were run on a Raspberry Pi 3 model Bto simulate a more hardware capable IoT-device. Tests per-formed on a Raspberry Pi shows that there are many instanceswhere a WasmRT outperforms a similar Docker+C solution.WasmRT has a very clear use case for IoT devices, specifi-cally short jobs, the results from our research will show thatWasmRT can be up to almost 70 times as fast as a similarDocker solution. WasmRT has a very strong use case thatother container solutions can not contend with. This paperwill show how effective a lightweight, portable, and fast Was-merRT can be, but also to highlight its pain points and whenother container solutions may make more sense

WebAssembly is a new binary code specification, which was initially designed to complement JavaScript in web applications. WebAssembly is inherently portable and small, designed for multiplatform usage. Therefore, WebAssembly modules can be created to support embedded system-based biomedical sensor operation. However, WebAssembly has its own limitations to compensate with its portability. In this thesis, we show how WebAssembly modules can be applied to the basic biomedical modalities of body temperature, heart rate, and breathing pattern.  We show how the implementation performed, and what challenges were met during the development. It is concluded that WebAssembly can be applied for achieving safe and effective biomedical sensor devices, although with some limitations. / WebAssembly är ett nytt binärt maskinkodsformat, ursprungligen skapat för att komplettera JavaScript i webbapplikationer.  WebAssemblys kod är liten och kan lätt användas på flera plattformar. Därför kan WebAssembly-moduler skapas för att stödja inbyggda system för biomedicinska sensorer. WebAssembly har dock sina egna begränsningar på grund av sin portabilitet.  I denna avhandling visar vi hur WebAssembly-moduler kan användas på enkla biomedicinska mätningar av kroppstemperatur, hjärtfrekvens och andningsmönster. Vi visar hur implementeringen genomfördes och vilka utmaningar som möttes under utvecklingen. Slutsatsen är att WebAssembly kan tillämpas för att skapa säkra och effektiva biomedicinska sensorenheter, även om det finns en del begränsningar.

WebAssembly is an instruction set designed for a stack based virtual machine, with an emphasis on speed, portability and security. As the use cases for WebAssembly grow, so does the desire to target WebAssembly in compilation. In this thesis we present Rasm, a Racket to WebAssembly compiler that compiles a select subset of the top forms of the Racket programming language to WebAssembly. We also present our early findings in our work towards adding a WebAssembly backend to the Chez Scheme compiler that is the backend of Racket. We address initial concerns and roadblocks in adopting a WebAssembly backend and propose potential solutions and patterns to address these concerns. Our work is the first serious effort to compile Racket to WebAssembly, and we believe it will serve as a good aid in future efforts of compiling high-level languages to WebAssembly.

With the current developments in modern web browsers, WebAssembly has been a rising trend over the last four years. Aimed at replacing bits of JavaScript functionality, it attempts to bring extra features to achieve portability and sandboxing through virtualisation. After the release of the WebAssembly System Interface, more and more projects have been working on using it outside web pages and browsers, in scenarios such as embedded, serverless, or distributed computing. This is thus not only relevant to the web and its clients, but also to applications in distributed systems. Considering the novelty of the topic, there is currently very little related scientific literature. With constant changes in development, proposals and goals, there is a large gap in relevant research. We aim to help bridge this gap by focusing on Rust and Arc-Lang, a domain-specific language for data analytics, in order to provide an overview of how far the technology has progressed, in addition to what runtimes there are and how they work. We investigate what kind of use case WebAssembly could have in the context of distributed systems, as well as how it can benefit data processing pipelines. Even though the technology is still immature at first glance, it is worth checking whether its proposals have been implemented, and how its performance compared to that of native Rust can affect data processing in a pipeline. We show this by benchmarking a filter program as part of a distributed container environment, while looking at different WebAssembly compilers such as Cranelift and LLVM. Then, we compare the resulting statistics to native Rust and present a synopsis of the state of WebAssembly in a distributed context. / I takt med den nuvarande utvecklingen av moderna webbläsare har WebAssembly stigit i trend under de senaste fyra åren. WebAssembly har som syfte att ersätta och utöka JavaScript med funktionalitet som är portabel och isolerad från omvärlden genom virtualisering. Efter lanseringen av WebAssembly System Interface har fler och fler projekt börjat applicera WebAssembly utanför webbsidor och webbläsare, i scenarier som inbäddade, serverlösa eller distribuerade beräkningar. Detta har gjort WebAssembly till ett språk som inte bara är relevant för webben och dess användare, utan även för applikationer i distribuerade system. Med tanke på ämnets framkant finns det för närvarande väldigt lite relaterad vetenskaplig litteratur. Ständiga förändringar i utveckling, förslag och mål har resulterat i stort gap i relevant forskning. Vi strävar efter att hjälpa till att överbrygga denna klyfta genom att studera WebAssembly i perspektivet av Rust och Arc-Lang, ett domänspecifikt språk för dataanalys, för att ge en översikt över hur långt tekniken har kommit, och samt utreda vilka exekveringssystem som finns och hur de fungerar. Vi undersöker vilken typ av användning WebAssembly kan ha i samband med distribuerade system, samt hur det kan gynna databehandlingspipelines. Även om tekniken fortfarande är ny vid första anblicken, är det värt att kontrollera om dess förslag har implementerats och hur dess prestanda gentemot Rust kan påverka databehandling i en pipeline. Vi visar detta genom att benchmarka ett filtreringsprogram som en del av en distribuerad containermiljö, samtidigt som vi tittar på olika WebAssembly-kompilatorer som exempelvis Cranelift och LLVM. Vi jämför resultaten med Rust och presenterar en sammanfattning av WebAssemblys tillstånd i sammanhanget av distribuerade system.

DotVVM, WebAssembly, WASM, Blazor, ASP.NET Core, .NET Core, .NET, Mono, JavaScript, JavaScript engine, LLVM, AOT compiler, JIT compiler, WSL

The number of internet-connected devices and online services is increasing in the everyday lives of people. These devices and services solve independent tasks when used separately. However, they can solve complex tasks when used together. Trigger-action platforms (TAPs) allow users to create applications that connect their devices and services. The applications wait for a condition to be true in a device or service (trigger), and perform an operation in another device or service (action). JavaScript-driven TAPs allow users to add JavaScript code that is executed before the action. Currently, JavaScript-driven TAPs execute this code in the same JavaScript runtime for different applications. The problem is that they use unsafe isolation techniques that fail to secure code across applications. Thus, malicious applications can compromise other applications to leak their private data or control their behavior. Motivated to secure TAPs, we investigate isolation techniques on TAPs. The goal of this work is to propose isolation with WebAssembly, a recent language that is praised for its safe isolation. In line with the proposal, we prototype a WebAssembly-driven TAP. We also evaluate WebAssembly in terms of security, usability, and performance. For security, we perform a qualitative analysis of the security of current isolation techniques and WebAssembly. For usability, we implement and evaluate a set of applications on our novel platform. For performance, we conduct benchmarks on different isolation techniques including WebAssembly. The findings show that WebAssembly provides better isolation of code across applications than current isolation techniques. Our evaluation of usability and performance indicates that WebAssembly is also a practical and efficient solution. Furthermore, the performance results demonstrate that current JavaScript isolation techniques have significant performance issues that WebAssembly does not have. We conclude that WebAssembly can protect code across applications with isolation and it can be used in combination with other security measures to secure TAPs. / Antalet internetanslutna enheter och onlinetjänster ökar i det vardagliga livet. Dessa enheter och tjänster används för deras avsedda ändamål men i en kombination av varandra kan de användas för mer komplexa ändamål. Trigger-aktion-plattformar (TAP:ar) möjliggör för sina användare att skapa applikationer som sammankopplar deras enheter och tjänster. Applikationerna väntar på att ett visst villkor uppfylls på en enhet eller tjänst (trigger), och sedan utför den en handling på en annan enhet eller tjänst (aktion). JavaScript-drivna TAP:ar tillåter sina användare att skriva JavaScript-kod som exekveras före aktionen. Nuvarande JavaScript-drivna TAP:ar exekverar kod från olika applikationer i samma JavaScript-körtid. Problemet är att de använder osäkra isoleringsstrategier och därför misslyckas de med att säkra kod mellan applikationerna. Skadliga applikationer kan därmed angripa andra applikationer för att läcka deras privata data eller för att kontrollera dem. Vi undersöker isoleringsstrategier i TAP:ar med avsikt att säkra dem. Målet med detta arbete är att föreslå isolering med WebAssembly; ett nytt språk berömt för sin säkra isolering. I linje med vårt mål skapar vi en prototyp av en WebAssembly-driven TAP. Vi utvärderar även WebAssembly med avseende på säkerhet, användarbarhet och prestanda. För det förstnämnda utför vi en kvalitativ analys av säkerheten i nuvarande isoleringsstrategier och WebAssembly. För användarbarheten implementerar och evaluerar vi en uppsättning av applikationer på vår nya plattform. För prestanda utför vi flera tester på olika isoleringsstrategier inklusive WebAssembly. Resultaten visar att WebAssembly erbjuder bättre isolering för kod mellan applikationer än nuvarande isoleringsstrategier. Evalueringen av användarbarhet och prestanda påvisar dessutom att WebAssembly är en praktisk lösning med hög prestanda. Prestandaresultaten demonstrerar även att nuvarande isoleringsstrategier i JavaScript har prestandaproblem som WebAssembly inte har. Slutsatsen är att WebAssembly kan säkra kod genom att isolera applikationer och att det kan användas tillsammans med andra säkerhetsåtgärder för att säkra TAP:ar.

WebAssembly has become the fourth official web language, along with HTML, CSS and JavaScript since 2019. WebAssembly allows web browsers to execute existing programs or libraries written in other languages, such as C/C++ and Rust. In addition, WebAssembly evolves to be part of edge-cloud computing platforms. Despite being designed with security as a premise, WebAssembly is not exempt from vulnerabilities. Therefore, potential vulnerabilities and flaws are included in its distribution and execution, highlighting a software monoculture problem. On the other hand, while software diversity has been shown to mitigate monoculture, no diversification approach has been proposed for WebAssembly. This work proposes software diversity as a preemptive solution to mitigate software monoculture for WebAssembly. Besides, we provide implementations for our approaches, including a generic LLVM superdiversifier that potentially extends our ideas to other programming languages. We empirically demonstrate the impact of our approach by providing Randomization and Multivariant Execution (MVE) for WebAssembly. Our results show that our approaches can provide an automated end-to-end solution for the diversification of WebAssembly programs. The main contributions of this work are: We highlight the lack of diversification techniques for WebAssembly through an exhaustive literature review. We provide randomization and multivariant execution for WebAssembly with the implementation of two tools, CROW and MEWE respectively. We include constant inferring as a new code transformation to generate software diversification for WebAssembly. We empirically demonstrate the impact of our technique by evaluating the static and dynamic behavior of the generated diversification. Our approaches harden observable properties commonly used to conduct attacks, such as static code analysis, execution traces, and execution time. / WebAssembly har sedan 2019 blivit det fjärde officiella webbspråket, tillsammans med HTML, CSS och JavaScript sedan 2019. Detta nya språk tillåter webbläsaren att köra befintliga program eller bibliotek skrivna på andra språk, såsom C/C++ och Rust. Dessutom utvecklas WebAssembly för att vara en del av edge-cloud dator -beräkningsplattformar. Trots att WebAssembly är designatd med säkerhet i fokus som en premiss är det inte undantaget från sårbarheter. Därför ingår potentiella sårbarheter och brister i dess distribution och exekvering, vilket belyser ett av problemen med mjukvarumonokultur. MÅ andra sidan, medan mångfald av programvara har visat sig mildra monokultur, har ingen diversifieringsmetod föreslagits för WebAssembly. Denna avhandling föreslår en mångfald av programvara som en förebyggande lösning med syfte att minska programvarumonokultur för WebAssembly. Dessutom tillhandahåller vi implementeringar för våra tillvägagångssätt, däriblandinklusive en generisk LLVM- superdiversifierare som potentiellt utökar våra idéer till andra programmeringsspråk. Vi visar effekten av vårt tillvägagångssätt empiriskt genom att tillhandahålla rRandomisering och mMultivariante Exekvering (MVE) för WebAssembly. Våra resultat visar att våra tillvägagångssätt kan ge en automatiserad end-to-end lösning för diversifiering av program i WebAssembly. Detta arbetes viktigaste bidragen från detta arbete är: Vi lyfter fram bristen på diversifieringstekniker för WebAssembly genom en uttömmande litteraturgenomgång. Vi tillhandahåller en implementationeringen av två verktyg, CROW och MEWE, som genomför tillhandahåller randomisering och multivariant exekvering för WebAssembly. Vi inkluderar “constant inferring” som en ny kod-transformation för att generera mjukvarudiversifiering för WebAssembly. Vi demonstrerar empiriskt effekten av vår teknik genom att utvärdera det statiska och dynamiska beteendet hos den genererade diversifieringen. Våra metoder härdar mot observerbara egenskaper som vanligtvis används för att utföra attacker, som statisk kodanalys, exekveringsspår och exekveringstid. / <p>QC 20220909</p>