Fuzz testing is a software testing technique that has risen to prominence over the past two decades. The unifying feature of all fuzz testers (fuzzers) is their ability to somehow automatically produce random test cases for software. Fuzzers can generally be placed in one of two classes: black-box or white-box. Blackbox fuzzers do not derive information from a program's source or binary in order to restrict the domain of their generated input while white-box fuzzers do. A tradeoff involved in the choice between blackbox and whitebox fuzzing is the rate at which inputs can be produced; since blackbox fuzzers need not do any "thinking" about the software under test to generate inputs, blackbox fuzzers can generate more inputs per unit time if all other factors are equal. The question of how blackbox and whitebox fuzzing should be used together for ideal economy of software testing has been posed and even speculated about, however, to my knowledge, no publically available study with the intent of characterizing an answer exists. The purpose of this thesis is to provide an initial exploration of the bug-finding characteristics of blackbox and whitebox fuzzers. A blackbox fuzzer is implemented and extended with a concolic execution program to make it whitebox. Both versions of the fuzzer are then used to run tests on some small programs and some parts of a file compression library.

Karlstads kommun innehar en så kallad solkarta vars syfte är att ge kommunens invånare en översikt över hur mycket solenergi som infaller på varje individuell takyta och kan användas som underlag för beslut om installation av solpaneler på byggnadstak. Kartan är interaktiv och sträcker sig över hela kommunen. Tyvärr brister den i detaljnivå utanför Karlstad tätort och skulle behöva en uppdatering. Syftet med studien är att undersöka metoder att utvinna tvådimensionella takplansytor enligt LOD2 utifrån byggnadsfotavtryck och punktmolnsdata, som sedan ska kunna lägga grunden till en interaktiv solkarta. Tre metoder för takplanssegmentering valdes ut som baserades på tre olika GIS-mjukvaror: ArcGIS Pro, Whitebox Tools och TerraScan. Studieområdet, beläget på industriområdet Våxnäs i Karlstad, bestod av 68 byggnader med varierande taktyper av olika hög komplexitet. En ytterligare dimension till studien var att två olika indatamängder jämfördes för varje segmenteringsmetod: ett högupplöst fotogrammetriskt framställt punktmoln utifrån bilder tagna med UAV (Unmanned Aerial Vehicle) samt ett lägre upplöst punktmoln insamlat med flygburen laserskanning. Totalt erhölls sex olika resultat som utvärderades efter fullständighet och utseende. Den högsta medelfullständigheten för varje metod var: 99,6 % för metoden baserad på TerraScan, 90,2 % för metoden baserad på Whitebox Tools och 82,0 % för metoden baserad på ArcGIS Pro. Gällande indatamängder gav UAV-datamängden ca 6 procentenheter bättre medelfullständighet för de två bästa metoderna och 10 procentenheter lägre för metoden som funkade sämst. Gällande användbarheten av resultaten är kontentan att TerraScan-metoden hade lagt en bra grund för en solkarta. Whitebox Tools-metoden hade sannolikt också kunnat vara användbar om en förbättrad generaliseringsalgoritm i efterbearbetningen hade applicerats. Studien diskuterar skillnader, felkällor samt nämner några ytterligare beprövade metoder som aldrig färdigställdes på grund av odugliga resultat. Problem som återstår att lösa är hantering av hål i punktmolnsdata inför takplanssegmentering. / Karlstad Municipality has what is known as a solar radiation map with the purpose of providing an overview of how much solar irradiance that is received by individual roof planes. It serves as a basis for decisions regarding the installation of solar panels on building roofs. The map is interactive and covers the entire municipality. Unfortunately, it lacks detail outside the city of Karlstad and would benefit from an update. The study aims to explore methods for extracting two-dimensional roof planes according to LOD2 (Level of Detail 2) using building footprints and point cloud data. The roof planes could later form the foundation for an interactive solar map. Three methods for roof segmentation were examined, each based on different software: ArcGIS Pro, Whitebox Tools, and TerraScan. The study area, located in the Våxnäs industrial area in Karlstad consisted of 68 buildings with varying roof types and complexities. An additional dimension to the study involved comparing two different input datasets for each segmentation method: a high-resolution photogrammetric point cloud generated from UAV (Unmanned Aerial Vehicle) images and a lower-resolution point cloud collected with airborne laser scanning. In total, six different results were evaluated based on completeness and appearance. The highest mean completeness for each method was: 99,6 % for the TerraScan-based method, 90,2 % for the Whitebox Tools-based method and 82,0 % for the ArcGIS Pro-based method. Regarding input datasets, the two best methods showed an increase of approximately 6 percentage points in mean completeness for the UAV dataset, while the least effective method showed a decrease of 10 percentage points. In terms of practicality, the TerraScan method provided a solid basis for a solar map. The Whitebox Tools method could most likely be usable if a better generalization algorithm in post-processing is cultivated. The study also discusses differences, potential sources of error, and mentions some additional methods that were not fully developed due to inadequate results. Remaining challenges include addressing gaps of missing data in point clouds before roof plane segmentation.

Rapporten behandlar ett examensarbete med fokus på att hitta och jämföra en whiteboxlösningmot en nuvarande nätverksenhet åt företaget Cygate. Whiteboxlösningar är ett växande konceptsom är relativt outforskat och den större delen av nätverksmarknaden domineras fortfarande avetablerade märken. En brist på jämförelser mellan whiteboxslöningar och etablerade märken ären bidragande orsak till denna rapport. Cygate ville veta om det fanns några whiteboxlösningarsom kunde mäta sig prestandamässigt mot en av deras nuvarande enheter. Olikawhiteboxlösningar granskades och analyserades med fokus på porthastighet, antal portar ochstöd för utvalda protokoll. Den teoretiska undersökningen av olika whiteboxlösningar gjordeatt det gick att konstatera att det fanns en whiteboxlösning som levde upp till liknade prestandasom den nuvarande nätverksenheten. Whiteboxlösningen levde upp till de kraven som ställtsfrån Cygate och visade sig vara mer ekonomiskt lönsam och på vissa punkter ha bättreprestanda. Granskningen visar att ett företag kan förbättra sin prestanda och minska sinakostnader genom att implementera en whiteboxlösning.

Inom nätverksbranchen finns en strävan att gå från proprietära lösningar till en öppen standard för hård- och mjukvara. En term för detta är Whiteboxing och det innebär att användaren ges möjlighet att plocka ihop komponenter efter behov, och själv välja vilken mjukvara som används. I sin enklaste form byggs en Whiteboxrouter av en konventionell PC med två nätverkskort och en mjukvarubaserad routingapplikation. Företaget ÅF är intresserade av att veta hur Whitebox-lösningar för routrar står sig prestandamässigt i relation till konventionella routerlösningar med Application Specific Integrated Circuit. Detta arbete har undersökt prestandan genom att mäta throughput och goodput hos en Cisco 2911-router, en Whiteboxrouter med mjukvaran pfSense, samt en Whiteboxrouter som körde pfSense virtualiserat på ESXi. Dessutom undersöktes respektive konfigurations prestanda när trafiken skickades över IPsec VPN. För mätningarna användes filöverföringar med FTP och mätprogrammet Iperf3. Målet med arbetet var att skapa ett beslutsunderlag som klargjorde eventuella prestandaskillnader och utarbetade rekommendationer för framtida val av routerlösning. Resultatet visade att vid generell paketförmedling var prestandan mellan routrarna relativt jämn, dock rekommenderas den virtualiserade Whiteboxroutern då den fick det bästa resultatet. När trafiken sedan krypterades med IPsec VPN var det stora prestandaskillnader mellan enheterna. Bäst prestanda fick Whiteboxroutern. Författaren ser en vinning med Whitebox-tekniken i stort då den medger att serverutrustning som ska utrangeras på grund av prestandakrav, istället kan fungera som nätverksutrustning (routrar och brandväggar) och fortsätta användas under en större del av den tekniska livslängden. Detta kan på sikt leda till minskad miljöpåverkan och besparingar för företaget.

Whitebox cryptography aims at protecting standard cryptographic algorithmsthat execute in attacker-controlled environments. In these, the attacker is ableto read a secret key directly from memory. Common implementations mask alldata at runtime and operate on masked data by using many small precomputedtables. Practical whiteboxes involve trade-offs between security and executionspeed, to limit their footprints and enable applications such as real-time videostreaming.To improve this compromise, we study the use of bitslicing (or bitparallelism)to implement whiteboxes. Bitslicing is commonly used to writefast constant-time implementations of cryptographic algorithms and relies onthe synthesis of boolean circuits implementing the corresponding algorithms.The synthesis of optimal circuits for lookup tables is resource intensive andgenerally only performed once. In a whitebox context however, many randomlookup tables are generated at compile-time. We therefore require the booleancircuit generation to be time efficient.In this master thesis, we review the existing circuit-synthesis algorithms,and analyse their usability in the whitebox context. In particular, we studythe technique of Binary Decision Diagrams to generate efficient circuits ina cheap and adaptable manner. We implemented a flexible version of thisalgorithm as a C++ library. Eventually, we go through different techniques toevaluate the generated circuits and analyse the performances of our algorithm,and recommand the best parameters for the whitebox context. / Vit-låda kryptografi syftar till att skydda kryptografiska standardalgoritmersom körs i miljöer som kontrolleras av angripare, där angriparen kan läsa enhemlig nyckel direkt från minnet. Vanliga tillämpningar maskerar alla data vidkörning och bearbetar maskerade data med hjälp av många små förberäknadetabeller. Praktiska vit-låda innebär att man måste göra avvägningar mellansäkerhet och exekveringshastighet, för att begränsa deras fotavtryck och möjliggöratillämpningar som till exempel videoströmning i realtid.För att förbättra denna kompromiss studerar vi användningen av bitslicing(eller bit-parallelism) för att genomföra vit-låda. Bitslicing används vanligenför att skriva snabba konstanttidsimplementationer av kryptografiska algoritmeroch kräver syntes av boolska kretsar som implementerar motsvarande funktioner.Syntesen av optimala kretsar för uppslagstabeller är resurskrävande och utförsi allmänhet bara en gång. I ett vit-låda-sammanhang genereras dock mångaslumpmässiga uppslagstabeller vid kompilering, och därför kräver vi attgenereringen av boolska kretsar är tidseffektiv.I denna masteruppsats går vi igenom de befintliga algoritmerna för kretssyntesoch analyserar deras användbarhet i vit-låda-sammanhang. Vi studerar särskilttekniken med binära beslutsdiagram för att generera effektiva kretsar på ettbilligt och anpassningsbart sätt. Vi har implementerat en flexibel version avdenna algoritm som ett C++-bibliotek. Slutligen går vi igenom olika teknikerför att utvärdera de genererade kretsarna och analysera vår algoritms prestandaoch rekommenderar de bästa parametrarna för whitebox-kontexten. / La cryptographie en boîte blanche est connue comme protection pour desalgorithmes cryptographiques s’exécutant dans des environnements contrôléspar l’attaquant. L’approche classique consiste à remplacer les opérations pardes accès à des tables précalculées, ce qui a un coût en performance. Il estdifficile d’obtenir un bon compromis entre sécurité et vitesse d’exécution pourdes applications lourdes telles que la diffusion de contenus vidéos en tempsréel.Le parallélisme au bit ou bitslicing est utilisé en cryptographie traditionnellepour accélérer les implémentations, mais aussi en boîte blanche. Cettetechnique d’implémentation demande la synthèse d’un circuit booléen pourchaque table, recherche qui peut être très coûteuse en temps. En pratique, ilest commun de regénérer régulièrement toutes les tables utilisées dans uneboîte blanche pour renouveler sa défense, ce qui complique l’application dubit-parallélisme.Nous présentons dans cette thèse de master notre effort pour une synthèseefficace de circuits booléens à l’usage de la compilation de boîtes blanchesparallèles au bit. Nous publierons avec cet article une bibliothèque C++ etun module de compilation LLVM pour l’écriture d’implémentation bitslicée,avec un objectif de performance et de lisibilité.

<p>Att genomföra ett penetrationstest av en nätverksarkitektur är komplicerat, riskfyllt och omfattande. Denna rapport utforskar hur en konsult bäst genomför ett internt penetrationstest tidseffektivt, utan att utelämna viktiga delar. I ett internt penetrationstest får konsulten ofta ta del av systemdokumentation för att skaffa sig en bild av nätverksarkitekturen, på så sätt elimineras den tid det tar att kartlägga hela nätverket manuellt. Detta medför även att eventuella anomalier i systemdokumentationen kan identifieras. Kommunikation med driftansvariga under testets gång minskar risken för missförstånd och systemkrascher. Om allvarliga sårbarheter identifieras meddelas driftpersonalen omgå-ende. Ett annat sätt att effektivisera testet är att skippa tidskrävande uppgifter som kommer att lyckas förr eller senare, t.ex. lösenordsknäckning, och istället påpeka att orsaken till sårbarheten är att angriparen har möjlighet att testa lösenord obegränsat antal gånger. Därutöver är det lämpligt att simulera vissa attacker som annars kan störa produktionen om testet genomförs i en driftsatt miljö.</p><p>Resultatet av rapporten är en checklista som kan tolkas som en generell metodik för hur ett internt penetrationstest kan genomföras. Checklistans syfte är att underlätta vid genomförande av ett test. Processen består av sju steg: förberedelse och planering, in-formationsinsamling, sårbarhetsdetektering och analys, rättighetseskalering, penetrationstest samt summering och rapportering.</p> / <p>A network architecture penetration test is complicated, full of risks and extensive. This report explores how a consultant carries it out in the most time effective way, without overlook important parts. In an internal penetration test the consultant are often allowed to view the system documentation of the network architecture, which saves a lot of time since no total host discovery is needed. This is also good for discovering anomalies in the system documentation. Communication with system administrators during the test minimizes the risk of misunderstanding and system crashes. If serious vulnerabilities are discovered, the system administrators have to be informed immediately. Another way to make the test more effective is to skip time consuming tasks which will succeed sooner or later, e.g. password cracking, instead; point out that the reason of the vulnerability is the ability to brute force the password. It is also appropriate to simulate attacks which otherwise could infect the production of the organization.</p><p>The result of the report is a checklist by means of a general methodology of how in-ternal penetration tests could be implemented. The purpose of the checklist is to make it easier to do internal penetration tests. The process is divided in seven steps: Planning, information gathering, vulnerability detection and analysis, privilege escalation, pene-tration test and final reporting.</p>

Att genomföra ett penetrationstest av en nätverksarkitektur är komplicerat, riskfyllt och omfattande. Denna rapport utforskar hur en konsult bäst genomför ett internt penetrationstest tidseffektivt, utan att utelämna viktiga delar. I ett internt penetrationstest får konsulten ofta ta del av systemdokumentation för att skaffa sig en bild av nätverksarkitekturen, på så sätt elimineras den tid det tar att kartlägga hela nätverket manuellt. Detta medför även att eventuella anomalier i systemdokumentationen kan identifieras. Kommunikation med driftansvariga under testets gång minskar risken för missförstånd och systemkrascher. Om allvarliga sårbarheter identifieras meddelas driftpersonalen omgå-ende. Ett annat sätt att effektivisera testet är att skippa tidskrävande uppgifter som kommer att lyckas förr eller senare, t.ex. lösenordsknäckning, och istället påpeka att orsaken till sårbarheten är att angriparen har möjlighet att testa lösenord obegränsat antal gånger. Därutöver är det lämpligt att simulera vissa attacker som annars kan störa produktionen om testet genomförs i en driftsatt miljö. Resultatet av rapporten är en checklista som kan tolkas som en generell metodik för hur ett internt penetrationstest kan genomföras. Checklistans syfte är att underlätta vid genomförande av ett test. Processen består av sju steg: förberedelse och planering, in-formationsinsamling, sårbarhetsdetektering och analys, rättighetseskalering, penetrationstest samt summering och rapportering. / A network architecture penetration test is complicated, full of risks and extensive. This report explores how a consultant carries it out in the most time effective way, without overlook important parts. In an internal penetration test the consultant are often allowed to view the system documentation of the network architecture, which saves a lot of time since no total host discovery is needed. This is also good for discovering anomalies in the system documentation. Communication with system administrators during the test minimizes the risk of misunderstanding and system crashes. If serious vulnerabilities are discovered, the system administrators have to be informed immediately. Another way to make the test more effective is to skip time consuming tasks which will succeed sooner or later, e.g. password cracking, instead; point out that the reason of the vulnerability is the ability to brute force the password. It is also appropriate to simulate attacks which otherwise could infect the production of the organization. The result of the report is a checklist by means of a general methodology of how in-ternal penetration tests could be implemented. The purpose of the checklist is to make it easier to do internal penetration tests. The process is divided in seven steps: Planning, information gathering, vulnerability detection and analysis, privilege escalation, pene-tration test and final reporting.