Reverse Engineering Estimote - 💡 Fix My Ideas

Reverse Engineering Estimote

Reverse Engineering Estimote


Forfatter: Ethan Holmes, 2019

Craig Federighi, Apples senior vice president for software engineering på WWDC.

Tilbage i juni sidste år - på WWDC-Apple annoncerede roligt iBeacon. Det blev ikke engang nævnt i keynote, der vises i blot et enkelt dias om"... nogle andre funktioner i SDK'en." Men for hardwarefolk var det faktisk en af ​​de mest fremtrædende funktioner i Apples seneste OS release, og min Twitter feed eksploderede. Folk søger altid nye løftestænger for at gøre det muligt for dem at gøre nye ting.

Jeg vil ikke rigtig snakke her om den interessante og noget fortælle-splittede mellem Google, som oprindeligt baserede sig på NFC-teknologi og kun for nylig har tilsigtet tilføjet Bluetooth LE-støtte til Android og Apple, som undgik NFC og koncentreret sig om at finde alternativer udnytte både Wi-Fi og Bluetooth LE-for eksempel ved at udrulning AirDrop som et alternativ til Googles nu-lukkede Bump-fildelingstjeneste. Mens jeg tror, ​​at valget af de konkurrerende teknologier faktisk fortæller os meget om de to virksomheder - det er en anden post helt.

I hvad der nemt kunne være et råvaremarked - er iBeacon ikke deres teknologi - Estimote betragtes som markedsleder og fremmes relativt tungt som en af ​​de håndfulde partnerfirmaer på nordisk messe i CES næste uge.

Hvad er iBeacon?

iBeacon er en teknologi, der giver dig mulighed for at tilføje ægte verdenskontekst til smarte telefonapplikationer. Baseret på Bluetooth LE, en del af den nye Bluetooth 4.0 standard, er det en måde at levere grundlæggende indendørs navigation på, og iBeacon er blevet integreret i iOS 7 både inden for Core Location og Passkit rammerne for at muliggøre indendørs mikro-placering og geofencing.

Men iBeacon handler ikke om placering, det handler om nærhed. Din iPhone - eller endda din Android-telefon - kan nu advare programmer, når du nærmer dig eller forlader et sted med en iBeacon. Det kan også rapportere et estimat af din nærhed til iBeacon, men du bør være opmærksom på, at jo tættere du er på fyret, desto mere præcist er estimatet for nærhed. De to faktorer her er signalstyrke og radiointerferens. Selvom signalstyrken er ret pålidelig, er interferensen ikke - og kan ændre sig radikalt med tiden - så mens du generelt kan afhænge af signalet for at advare din app om, at du er i dens generelle nærhed, ville jeg være forsigtig med at stole på afstanden for meget.

Opbyg din egen iBeacon

Det er ret nemt at opbygge din egen iBeacon - enten ved hjælp af en Raspberry Pi eller ved hjælp af et Bluetooth LE bord som Red Bear Labs BLE Mini bord - og der er nogle mennesker der drager fordel af det for at få en hurtig fortjeneste.

For eksempel sælger Radius Networks en "IBeacon Development Kit" der består af en Raspberry Pi, en Bluetooth USB dongle og et 8GB SD-kort. Omkostning omkring $ 45, når de købes separat til fuld detailpris, sælger de den sammen med $ 100. Det er ret markering, især da de ikke vil købe komponenterne i detailsalg, med meget ringe merværdi ved at købe delene separat og følge ganske enkle instruktioner om at bygge dit eget.

For at være retfærdig tror jeg, at Radius bare sælger sættet som en sidelinje for at fremme deres softwareudbud, og de har udgivet deres arbejde med reverse engineering iBeacon Bluetooth-profilen og maksimerer iBeacon-responsiviteten blandt andet.

The Estimote

Som jeg har hørt det, ramte Estimote det heldigt. Der spillede de sammen med Bluetooth LE "beacons", der kunne bruges af smartphones til indendørs lokalisering, uden folk der viste meget interesse, og så var der Apple og iBeacon, og de endte med et par måneder start på konkurrencen. Selvfølgelig kan dette være urban legend edition - eller i det mindste en revisionistisk version - af deres virksomheds historie, fortalt i barer, konferencelobbyer og andre steder, hvor udvikleren samler. Men det har en vis ring af ægthed til det.

På trods af det - og uanset den sande historie - når iBeacon diskuteres, vil du ofte høre frasen "... som Estimote." Det er lidt uretfærdigt i deres konkurrence, og der er konkurrenter Roximity, TwoCanoes, Sonic Notify, Radius Networks og få andre, men jeg tror, ​​det er pauserne.

Det er faktisk stadig temmelig svært at få hænderne på et Estimote-udvikler forhåndsvisningssæt, da det stadig forsendes i begrænsede tal, men det lykkedes mig at få et af de tidlige udviklerpakker tilbage i november sidste år, og forudsigeligt tog jeg en af ​​fyrene en del.

Det første du bemærker er, at der ikke er nogen tænd / sluk-knap, enheden udsender hele tiden, selv før du kommer ud af emballagen. Det sendes live, hvilket kan blive interessant.

Sagen er lavet af blødt silicium med en gummeret følelse, og den er helt lukket, så den er vandtæt. Jeg havde mere eller mindre nødt til at ødelægge kabinettet for at hente PCB'et ud af det, hvilket også betyder, at udskiftning af batterierne - i det mindste på modellerne i preview-kit - ikke bliver muligt. Det betyder dog, at du kan installere det udendørs, hvilket er et stort pluspunkt for nogle brugssager.

Estimote Beacon er bygget op omkring en nordisk halvleder nRF51822. Du kan også se den indbyggede antenne til Bluetooth LE-radioen til højre for billedet.

Estimote er bygget omkring den nordiske halvleder nRF51822, der forklarer deres tilstedeværelse på den nordiske messe på CES. Det er en flot chip, i grunden en 32-bit ARM Cortex M0 CPU med 256KB flash og 16KB RAM med en indbygget 2,4 GHz-radio, der understøtter både Bluetooth LE såvel som 2,4 GHz-drift - hvor 2,4 GHz-tilstanden er på luftkompatibel med nRF24L serien produkter fra nordisk.

Beaconerne markedsføres som både en temperatursensor og et accelerometer. Selvom vi senere vil se, er ingen af ​​disse annonceret som led i GATT og er ikke tilgængelige tilgængelige datapakker, i det mindste i øjeblikket.

Jeg går ud fra, for nu - at temperatursensoren de taler om, er den ene indbygget til den nordiske ARM selv, og at accelerometeret er den mindre chip (til venstre for billedet) mærket"8237 C3H DEA3H" selvom jeg bliver nødt til at indrømme, at jeg ikke har sporet dataarket for denne chip, så jeg ikke ved det helt sikkert.

Estimote annoncerer en rækkevidde på omkring 230 fod (ca. 70 meter) for deres fyrtårne. Men testning sætter området meget mindre, på et sted omkring 130 meter (ca. 40 meter) ud af kassen, med høj variabel præcision. Så vidt jeg kan fortælle dig, bør du ikke stole på nærhedsmålinger overhovedet, som i hvert fald fra min egen test, varierer disse nærhedsmålinger hurtigt - formodentlig på grund af radiointerferens.

De forudsiger også batterilevetid på op til 2 år. Men vores beacon ankom 55 procent ladning, og det er nu på 33 procent efter blot en måned, så det virker lidt optimistisk forudsigelse - og gør det lukkede kabinet mere ansvar end et aktiv.

Interessant er alle Estimote-bakkerne i alle deres forhåndsvisningssæt til udviklere afsendt med identiske UUID'er. UUID'en for hvert signal er fast, og de planlægger ikke at tilføje evnen til at ændre UUID'en helst snart. Det betyder at du ikke kan bruge dem i et produktionsmiljø som Apple havde til hensigt, eller i hvert fald ikke uden nogen ændring.

Du er også effektivt låst til at bruge deres lukkede kilde iOS SDK, hvis du bruger deres hardware, da andre iBeacon-hardware ikke fungerer sammen med deres SDK, og hvis du bruger den laveste fællesnævner-Apples egne Core Location og Passkit-rammer - at tale med en heterogen samling af iBeacon-hardware, sidder du fast i skrivebeskyttet tilstand med Estimote-beaconerne selv. Det kunne være et reelt problem i fremtiden, både for slutbrugere og Estimote selv.

Estimote har nu også afsendt en lukket kilde Android SDK. Imidlertid synes jeg ikke at være en stor fordel ved at låse dig selv i deres proprietære SDK på Android som - i modsætning til deres iOS SDK - kan beacons ikke konfigureres ved hjælp af det, så du sidder fast med skrivebeskyttet tilstand i under alle omstændigheder. Du kan lige så godt bruge et af de generiske biblioteker, der er bygget til iBeacons på Android, og være i stand til at tale med alles hardware, ikke kun Estimote's.

Beaconerne selv skal derefter konfigureres af en lukket kilde iOS SDK, og i det mindste for øjeblikket forbliver Bluetooth LE GATT-tjenesterne og karakteristikaene for beacons-i det mindste officielt uokumenterede.

For at være retfærdig over for Estimote har Apple heller ikke officielt offentligt dokumenteret iBeacon-specifikationen heller, selvom uofficiel dokumentation baseret på Apples eget eksempelkode er begyndt at blive vist. Ud over hardware skal vi se nærmere på udviklerens preview beacon software og se, om vi kan finde ud af, hvordan de virker.

Hvad annoncerer Estimote Beacon?

Ved hjælp af Sandeeps ædle pakke til node.js kan vi se på, hvad der annonceres af en af ​​beaconsne, ved hjælp af annonceopdagelsesskriptet, der følger med pakken.

En Estimote fyrtråd plukket tilfældigt fra vores udvikler forhåndsvisning kit-med en Bluetooth-adresse på E7: 44: 89: 31: ED: 4E annoncerer et lokalt navn på ”Estimote”, sammen med nogle service- og producentdata. Men det synes ikke at være reklamer for nogen service UUIDs.

Når vi kigger nærmere på fremstillingsdataene, var de data, der blev annonceret af fyret,

4C00 02 15 B9407F30F5F8466EAFF925556B57FE6D ED4E 8931 B6

Bryde dette ned,

  • Første to bytes er Apple Company Identifier (Little Endian) 0x0042.
  • Den tredje byte - i det mindste mest sandsynligt - angiver datatypen, som er 2.
  • Den fjerde byte angiver den resterende datalængde, 21 byte.
  • Estimote Beacons har en fast iBeacon UUID af B9407F30-F5F8-466E-AFF9-25556B57FE6D.
  • De næste to byte efter iBeacon UUID er iBeacon Major (Big Endian), dvs. 0xED4E, 60750.
  • De næste to bytes efter iBeacon Major er iBeacon Minor (Big Endian), dvs. 0x8931, 35121.
  • Den endelige byte er den målte RSSI ved 1 meter væk, dvs. 0xB6, -74.

Effektivt gør Estimote ikke noget særligt her, dette er bare standard iBeacon data. Tre af egenskaberne skaber fyrens identitet. Disse er:

  • UUID - Dette er en egenskab, som er unik for hvert firma. I de fleste tilfælde vil samme UUID blive givet til alle beacons, der udnyttes af en virksomhed (eller gruppe). Estimote er usædvanligt, fordi de har fastsat UUID for alle"deres" beacons at være det samme.
  • Major - Den egenskab, du bruger til at angive et relateret sæt af beacons, f.eks. alle beacons i en butik vil dele den samme hovedværdi.
  • Mindre - Ejendommen, som du angiver, angiver et bestemt fyr på et sted.

Vi skal se på de servicedata, der annonceres af fyret,

0A18 4EED318944E7 B6 4EED 3189

at se noget Estimote specifikke,

  • De første to byte angiver, at disse serviceoplysninger er til en tjeneste med UUID 0x180A.
  • De næste 6 byte er Bluetooth-adressen, men i omvendt rækkefølge, E7: 44: 89: 31: ED: 4E.
  • Den næste byte, 0xB6 matcher den målte RSSI på 1 m væk.
  • De næste 2 byte passer til iBeacon Major, men denne gang er det Little Endian.
  • De sidste 2 bytes, matcher iBeacon Minor igen i Little Endian format.

Ifølge Bluetooth-kernespecifikationstjenesten skal dataene præfikseres med 16-bit UUID for den service, dataene er for - og her for Estimote - servicedataene er til for en tjeneste med UUID på 0x180a, hvilket er interessant, fordi som vi 'll se senere, når vi ser på GATT, eksisterer denne tjeneste ikke på enheden.

GATT-tjenester og karakteristika

I kontrast med ”Klassiske” Bluetooth-hvor der er en lang række protokoller - med Bluetooth LE er der kun en protokol øverst, og det er GATT (Generisk Attribut). Den egentlige funktionalitet af en Bluetooth LE-enhed implementeres ved hjælp af attributter, som kan læses, skrives eller aktiveres til meddelelse / angivelse afhængigt af attributtypen.

Vi kan bruge Linux gatttool kommandolinjeprogram-en del af BlueZ-pakken - for at manipulere disse attributter. Tilslutning til fyret med gatttool vi får en liste over både tjenester og egenskaber.

Sæt output fra gatttool i tabular form - hvor læsbare egenskaber blev læst ved hjælp af ”Char-læsning-HND gatttool kommando - vi kan sammenligne de værdier vi fik fra gatttool til, hvad der vises Estimote iOS-applikationen,

Vores fyrtårn i Estimote iOS-appen.

og vi er meget længere fremme. Interessant, hvis du på dette tidspunkt forsøger at bruge gatttool’s ”Char-skrive-req kommandoen til at skrive til nogen af ​​Estimotes karakteristika-UUID, Minor, Major, Power Level og Advertising Interval-skriverne vender tilbage som vellykket. Imidlertid opdateres ikke iBeacons udsendte data i overensstemmelse hermed.

På trods af dette giver Estimote SDK dig mulighed for at opdatere iBeacon Minor og Major - men ikke som tidligere nævnt fyrens UUID-noget foregår her, som vi skal forstå mere fuldt ud. SDK'en gør selvfølgelig noget uanstændigt under emnetgatttool er det ikke.

Brug af SDK

Yoann Gini har opbygget et simpelt værktøj ved hjælp af Estimote SDK, som giver dig mulighed for at læse og redigere de mindre og store numre for fyret, kaldet EstimoteEditor.

Vi har forked projektet - og lavet nogle ændringer, vi vil snakke om senere - så hvis du går videre og klon repoen,

git klon https://github.com/sandeepmistry/EstimoteEditor.git cd EstimoteEditor git submodule init git submodule opdatering

og initialisere og opdatere submodulerne, så åbner projektet i Xcode, du kan opbygge og distribuere til en Bluetooth LE-aktiveret iPhone. Desværre går det ikke i IOS Simulator, det skal køres på en enhed.

Vores Estimote iBeacon vises i appen EstimoteEditor.

Når du har valgt det opdagede bjælke, er Power Level, Major, Minor og Advertising Interval alle konfigurerbare - og de redigerede værdier holder sig, i modsætning til de ændringer, vi lavede fra gatttool. Så hvad laver SDK'en anderledes?

Metode Swizzling CoreBluetooth

Da Objective-C er et runtime-sprog, er det muligt at inspicere metoder, egenskaber og variabler af klasser og objekter på runtime, selv om de er private og skjult af SDK, selvom du ikke har kildekoden og kun har adgang til en binær blob.

For at gøre dette bruger vi noget, der kaldes metode, swizzling-det giver dig mulighed for at erstatte den eksisterende implementering af en metode med din egen på runtime. Forudsigeligt, hvis det bruges korrekt, kan være et kraftfuldt værktøj. Men bruges forkert, kan det medføre ødelæggelse på bibelsk skala.

Sandeep brugte denne teknik til at se, hvordan CoreBluetooth arbejder under emhætten på OS X, og derefter brugte resultaterne til at kommunikere med blued-Bluetooth-daemonen på OS X-uden at bruge CoreBluetooth i noble, hans node.js BLE-bibliotek. Måske mere scarily har Alasdair brugt det i produktionskode til at opfange forskellige netværksopkald og indføre analyser for at indsamle netværksydelsesdata"i det vilde" på iPhone.

Lad os bruge en lignende teknik på iOS til at opfange kommunikationen mellem Estimote SDK og CoreBluetooth. Efter at have kigget på iOS runtime headers for CoreBluetooth, skiller CBXpcConnection klassen sig ud. Her bruges en XPC-forbindelse af CoreBluetooth til at kommunikere med Bluetooth-dæmonen.

Lad os swizzle følgende metoder,

- (void) handleMsg: (int) arg1 args: (id) arg2; - (void) sendMsg: (int) arg1 args: (id) arg2;

som gør det muligt for os at se, hvordan Estimote SDK bruger CoreBluetooth - med en vis fortolkning ser vi, at der ikke er noget særligt foregår her,

  1. start scanning for enheder
  2. enheder opdaget
  3. stop scanning
  4. Tilslut til enheden
  5. opdage enhedens tjenester og egenskaber
  6. læs / skriv nogle af enhedens egenskaber

Ting ligner det, vi gjorde med gatttool, bortset fra læsning / skrivning til egenskaberne ved håndtag 45 og 47. Vi skal nok gå tilbage til Xcode og sætte breakpoints under karakteristisk skrivning og se, hvad opkaldsstablerne viser,

Opkaldsstakken i Xcode IDE under karakteristik skriver.

Dette giver os to flere metoder til at swizzle, denne gang inde i ESTBeacon klassen,

- (void) pairSensorFirstPart; - (void) pairSensorSecondPart;

Når man kigger på outputet, ser det ud til at der er en særlig parringsproces, der foregår, så at sætte brudpunkter i de nye swizzled-metoder - lad os sætte ind i de oprindelige metoder - hjælper ikke så meget. Hvad er næste?

Running class-dump på bygningen giver nogle interessante output. ETBluetoothMath-klassen ser særligt interessant ud.

@ interface ETBluetoothMath: NSObject {} + (id) stringFromHexString: (id) arg1; + (id) hexStringToBytes: (id) arg1; + (int) giveSignToUnsigned: (unsigned int) arg1; + (usigneret lang) Secunit_ModExpWithBase: (unsigned long) arg1 Exp: (unsigned long) arg2 ogMod: (unsigned long) arg3; + (usigneret lang) randomUInt32; + (usigneret kort) randomUInt16; + (id) randomDataWithBytes: (unsigned int) arg1; + (const char *) CBUUIDToString: (id) arg1; + (int) compareCBUUID: (id) arg1 UUID2: (id) arg2; + (id) IntToCBUUID: (usigneret kort) arg1; + (usigneret kort) CBUUIDToInt: (id) arg1; + (usigneret kort) bytte: (usigneret kort) arg1; + (const char *) UUIDToString: (struct __CFUUID *) arg1; @ende

Lad os swizzle Secunit_ModExpWithBase: Exp: andMod: metode og tilføje nogle logge på input og returnere værdier. Det vil fortælle os, hvordan det karakteristiske håndtag 45 anvendes,

  1. Generer et tilfældigt 32-bit usigneret heltal.
  2. Skriv følgende til karakteristik ved håndtag 45: 5 ^ (tilfældig 32) mod 0xfffffffb (lille endian)
  3. Læs karakteristisk ved håndtag 45 (lille endian): (karakteristisk 45 værdi) ^ (tilfældig 32) mod 0xfffffffb

Lad os sætte et breakpoint i swizzled pairSensorSecondPart metode i ESTBeacon, og gå ind i originalen. Efter at have trukket over et par instruktioner ser vi noget interessant.

Trækker gennem koden og spotter aes_encrypt-opkaldet i TI_aes.c.

Er det TI-som i Texas Instruments? At gå til Google finder vi ikke kun, at det er, men kildekoden til TI_aes.c er tilgængelig online. Vi kan få fat i det og tilføje det til vores projekt. Det vil lade os prøve at tilføje breakpoints til aes_encrypt og aes_decrypt inde TI_aes.c. Overraskende bliver disse brydpunkter faktisk ramt, hvilket betyder, at vi kan inspicere de data, der overføres til både krypterings- og dekrypteringsmetoderne.

AES-128 krypteringsnøglen er altid 0xff8af261013625c2d810097f20d3050f. Mens krypteringsstaten er baseret på Bluetooth-adressen (E7: 44: 89: 31: ED: 4E) og er 0x4eed318944e731ed4ee74489443189ed.

AES-128 dekrypteringsnøglen er baseret på den sidste sekundet beregnet (0x8e450d08) og er 0x080d458e8e450d08088e0d458e08450d. Mens dekrypteringsstaten er resultatet af krypteringen, er 0x419a05a457dcceebeed5129e88a81c4e.

Resultatet af dekrypteringen er skrevet til karakteristikken ved håndtaget 47, der indpakker parringsprocessen.

At sætte tingene sammen

Nu har vi fundet ud af parringssekvensen og en grov specifikation af egenskaberne. Vi kan oprette et node.js script, der bruger edelt at opdage og oprette forbindelse til Estimote Beacon. Så kan vi prøve igen - efter parring at skrive til Major og Minor karakteristika. Denne gang med succes.

Interessant. SDK tillader ikke os at opdatere UUID, kan vi gøre det ved hjælp af denne metode? Det viser sig, at vi kan. At skrive den samme værdi til begge UUID-egenskaber fungerer, og iBeacon UUID opdateres. Vi kan indstille iBeacon UUID til noget, som Estimote ikke udsætter.

Konklusion

Estimote iOS SDK er lukket kilde, men ved at bruge metode swizzling og klassen-dump utility på det og CoreBluetooth rammer vi kunne finde ud af, hvordan det interagerer med fyret.

Oplysningerne i SDK er nok mere afslørende end forfatterne forventede at være, og desværre for dem er der meget lidt, de kan gøre ved det.

Selvom Estimote-udviklerens forhåndsvisningssæt og SDK stadig er i deres tidlige stadier, hvis Estimote stikker med deres nuværende sikkerhedsmodel - selvom der er tegn på, at de måske ikke gør det - alle, der opretter en applikation ved hjælp af deres SDK, vil kunne omkonfigurere enhver Estimote Beacon i det vilde.

Implikationerne heraf er ret vidtrækkende. Hvis nogen skadeligt ændrer iBeacon Major eller Minor-karakteristikken for et fyrtøj, vil enhver forbrugerapplikation, der er konfigureret til at bruge det pågældende fyrtråd, stoppe med at arbejde. Beaconerne skal konfigureres med en foruddefineret identitet for at udløse den korrekte adfærd i forbrugerens egen applikation, når deres smart telefon kommer i nærheden af ​​fyret.

Ud over det kunne du konfigurere en”Falske” beacon for at fungere som en bedrager af et andet fyrtårn, der tilhører en detailkæde, der potentielt får adgang til kampagner, gavekort og andre stedafhængige godbidder, der er bundet til det fyrtårn, du udgiver.

Andre producenter bruger forskellige og muligvis mere sikre metoder til at indstille UUID, Minor og Major værdierne af fyret. Personligt vil jeg gerne tage et seriøst kig på disse alternativer, før jeg installerer denne teknologi i produktionsmiljøer. Især hvis der var rigtige penge involveret.

Selv om det ikke er trivielt at omdanne den software og hardware, der bruges i enheder som Estimote, er det helt muligt og efter at have forstået, hvordan fyrene fungerer - vi kunne nemt ændre lysstyrken konfiguration.

Opdatering: Vi talte om begge muligheder for at konfigurere”Falske” beacons, og evnen til at deaktivere beacons i feltet, men vi troede ikke, vi ville se noget som dette helt her snart. Årets Consumer Electronics Show (CES) indeholdt en salgsfremmende jagt jagt baseret på Apples iBeacon teknologi - og det viste sig at du kunne vinde jagten uden at skulle gå til CES.

00


Du Kan Være Interesseret

FØRSTE Robotikonkonkurrence 2013

FØRSTE Robotikonkonkurrence 2013


Velkommen til Saint Malo og Faire

Velkommen til Saint Malo og Faire


Glas fra fortiden: Lav en lampe med Vintage Power Line-isolatorer

Glas fra fortiden: Lav en lampe med Vintage Power Line-isolatorer


Trafikdata, på dit armbåndsur ... (En DIY trafikmåler?)

Trafikdata, på dit armbåndsur ... (En DIY trafikmåler?)