Herken de encryptie (en hoe te decoden)...

[geerttttt]

Ik heb een wifi deurbel die ik probeer te omleiden naar mijn eigen server.

Het is me gelukt om een eigen webserver op te zetten die met de juiste certificaten een man-in-the-middle doet en de data tussen de echte server en de deurbel uitleest en her en der aanpast. Hierdoor kan ik de url die hierin verstuurd wordt waar de deurbel een snapshot jpg heen stuurt van het beeld op de deurbel aanpassen zodat deze naar mijn eigen http webserver wijst.

Dat is allemaal gelukt en de data komt aan. Nu het tweede probleem, hij stuurt een json string die versleuteld is, en ik kom er niet achter hoe die versleuteld is. Kan iemand me op weg helpen?:

code:

result: {
    "data":"U0u7WfBoVUB7xqk3NrmGLoqpDQXFoFliFWHQbo7tl52FZNE-8-9iJhxP3_K2o1b_5d8YpLBGORLnbEH5IYgKt0g_S5rnPyoCpO2S2LZXkZghwg4qYDRjla7o4zGAVnDApp85MKTqpC1JIU3YQqkg9SubbY7_M4XiqSI_4DSq35PeniVLRaGtvANh4ZTXspbGzwkpxvxehfr1qXXdBYfpkVbD-nGoF9Cbe9TPhuSt_58sHdhzJGxECdloUF6NLUOa",
    "sign":"fV12WdlPo8VnJznjIGTgxr7MYlDgEddExfO_I8TDgXE",
    "iv":"wZxMLIWbAvanP5n5PBQFcg"}

Eerder in het proces gaan er meer mogelijke encryptiesleutels oid over de lijn heen, namelijk:

code:

iv=JeqTRGl99wdDTM4gXZD23w
&signature=St8eaTVklTBYolireWVtpyK36m_vii7o_9c3znT-eks

en ook

code:

{"id":118027,"result":{
    "data":"{\
        "security\":\"KwvGGsbUCBap5p3VCua7Mw\",\
        "token\":\"GKABOtn39Y2P50sz3HijNtKjFDrG0jH_hekam-bp6lQXCj-FixbiP_pW4ZA-O0J2KMLSgkVtrmblB4ZP93mxo_2aHAahrknG_nrGrgexAdvnjlAE2sWJMTo9HyZeFHM0HrDrwQiPxNJ-k2r_rs_6cb_yLRkAX6IQzefGbc_utQxq2a_k0i3WThYfinPTQR_FN4FyVnm_QUKUocFgrtANDanHnRgSc-6bRa5kQt-y-5lFV19FqKMBGBAcr-PqhNuumR48CovVe_poGBTBAGwTrRCCD3Jv8WoE9s7L3ESdCAA\"
    }"
    }
} o

Het gaat erom dat de data in het eerste codeblokje waarschijnlijk een of meerdere https urls zou moeten bevatten. Deze wil ik ontsleutelen en aanpassen. Maar ik weet niet precies wat voor encryptie dit is. Weet iemand misschien wat meer?

[Anoniem: 160587]

of ze maken gebruik van een custom encryptie maar dit lijken payloads te zijn (en dus data).
Geen encryptie die ik ken gebruikt underscores of streepjes (wellicht dat een andere tweakers het wel weet).

Het tooltje "hashid" op python herkent je strings en gebruikte encryptie ook niet.

Wat probeer je sowieso te bereiken hiermee? Wie zegt dat je nu niet de buurman aan het treiteren bent bijvoorbeeld en wij je daarbij potentieel helpen? :-)

[DataGhost]

Dat ziet eruit als Base64 met - en _ ipv + en /. Wordt wel vaker gebruikt voor data die over het web gaat. Dat is alleen maar de representatie omdat je de output van een encryptiealgoritme natuurlijk niet in JSON kan zetten. Daarna zal het wel iets van AES zijn, met al dan niet een fixed key in de firmware, een eerder afgesproken sessie-key, of geen (naast de IV natuurlijk).

[ Voor 3% gewijzigd door DataGhost op 04-12-2019 16:50 ]

[geerttttt]

Anoniem: 160587 schreef op woensdag 4 december 2019 @ 16:41:
of ze maken gebruik van een custom encryptie maar dit lijken payloads te zijn (en dus data).
Geen encryptie die ik ken gebruikt underscores of streepjes (wellicht dat een andere tweakers het wel weet).

Het tooltje "hashid" op python herkent je strings en gebruikte encryptie ook niet.

Hm, ja misschien is het eerst nog gebase64-ed ofzo...

Wat probeer je sowieso te bereiken hiermee? Wie zegt dat je nu niet de buurman aan het treiteren bent bijvoorbeeld en wij je daarbij potentieel helpen? :-)

Nou ja ik moet mijn eigen hosts file aanpassen om een url om te leiden naar mijn eigen server, dus daar heeft mijn buurman weinig last van

Nee ik heb een Xiaomi deurbel camera die nu alles vrolijk doorstuurt naar hun servers in china. Ten eerste werkt de xiaomi app totaal niet (maar dat fixen ze wellicht nog wel in de toekomst), ten tweede is de cloud opslag maar 3 dagen, en laatst heb ik liever dat de data hier blijft in plaats van dat een camerastream naar china gaat., maar goed, dat laatste is een bonusje voor later denk ik. Als het moet kan ik wel foto's sturen van de camera hoor

[Anoniem: 160587]

DataGhost schreef op woensdag 4 december 2019 @ 16:50:
Dat ziet eruit als Base64 met - en _ ipv + en /. Wordt wel vaker gebruikt voor data die over het web gaat. Dat is alleen maar de representatie omdat je de output van een encryptiealgoritme natuurlijk niet in JSON kan zetten. Daarna zal het wel iets van AES zijn, met al dan niet een fixed key in de firmware, een eerder afgesproken sessie-key, of geen (naast de IV natuurlijk).

Heh? Hoe dan?

U0u7WfBoVUB7xqk3NrmGLoqpDQXFoFliFWHQbo7tl52FZNE-8-9iJhxP3_K2o1b_5d8YpLBGORLnbEH5IYgKt0g_S5rnPyoCpO2S2LZXkZghwg4qYDRjla7o4zGAVnDApp85MKTqpC1JIU3YQqkg9SubbY7_M4XiqSI_4DSq35PeniVLRaGtvANh4ZTXspbGzwkpxvxehfr1qXXdBYfpkVbD-nGoF9Cbe9TPhuSt_58sHdhzJGxECdloUF6NLUOa

Als we jou methode pakken en dat vertalen dan komt er nog niks zinnigs uit, iig geen geldige base64. Of ik begrijp je verkeerd :-)

[geerttttt]

Oke, dat zou kunnen, dan krijg je een encoded stuk data, zoiets:

code:

볠֓NíQݙ˳Ǡ׵ޥſ&D؎א枑]ZL`jBo𡤪IM#ٌࠥۼ=ࠜҰ˪oљk3焹暭cn
⚾?/B-@,Y͒ې䏕򵛊ѨbiS!ߣɅ׻󞓌چ󚅇ذ    )Yp/󒎚;Ƣc֮ҢӿܷΉ̅ۧ󻜎̦Z,@ӋWپtࠆʾ˚َ9@v&6ԅɦ
�

(voor zover je dat kunt plakken..)

En dan dus het encryptie stuk... De IV is geen juiste lengte geven de tools mij aan, dat lijkt me al probleem 1... Iemand een idee?

[DataGhost]

Wat ik zeg is dat wat in data staat al base64-encoded is. Dat je nooit - en _ in een base64-encoded string hebt gezien wil niet zeggen dat het niet kan, sterker nog, de RFC laat daar gewoon ruimte voor in plaats van de + en / die je normaal ziet, en er zijn meerdere implementaties die zelfs andere (custom) karakters gebruiken in plaats daarvan. Als je dat door een base64 decoder heen haalt (die niet zo naief is en snapt dat - en _ gebruikt zijn) komt er inderdaad rommel uit, dat is de binaire output van het encryptiealgoritme waarmee de data versleuteld is. Op dezelfde manier is de iv 22 karakters lang, wat inhoudt dat de laatste twee padding-bytes (==) gewoon weggelaten zijn. Als je dat base64 decodet kom je op een string van 16 tekens, wat prima een IV kan zijn voor AES.

Edit:

geerttttt schreef op woensdag 4 december 2019 @ 17:01:
Oke, dat zou kunnen, dan krijg je een encoded stuk data, zoiets:
En dan dus het encryptie stuk... De IV is geen juiste lengte geven de tools mij aan, dat lijkt me al probleem 1... Iemand een idee?

Het online tooltje wat je gebruikt is waarschijnlijk die van de eerste hit in Google. Het lijkt erop dat die alleen maar een base64 decode doet op de input, niet op de IV. De IV is wel degelijk 16 tekens lang.

[ Voor 25% gewijzigd door DataGhost op 04-12-2019 17:04 ]

[Groentjuh]

Anoniem: 160587 schreef op woensdag 4 december 2019 @ 16:57:
[...]


Heh? Hoe dan?

[...]


Als we jou methode pakken en dat vertalen dan komt er nog niks zinnigs uit, iig geen geldige base64. Of ik begrijp je verkeerd :-)

Encrypt geeft een mooie onleesbare mix van bitjes. Als je dat in JSON zet, dan is dat vragen om problemen. Ik gok ook op Base64 met URL en bestandsnaam veilig alphabet en daarna iets als AES.

[geerttttt]

DataGhost schreef op woensdag 4 december 2019 @ 17:02:
Op dezelfde manier is de iv 22 karakters lang, wat inhoudt dat de laatste twee padding-bytes (==) gewoon weggelaten zijn. Als je dat base64 decodet kom je op een string van 16 tekens, wat prima een IV kan zijn voor AES.

Dat laatste stuk snap ik niet helemaal. Ik dacht dat een IV daadwerkelijk een soort leesbare string moest zijn. Als ik de IV base64 decode krijg ik een wazig stukje...

[DataGhost]

geerttttt schreef op woensdag 4 december 2019 @ 17:04:
[...]

Dat laatste stuk snap ik niet helemaal. Ik dacht dat een IV daadwerkelijk een soort leesbare string moest zijn. Als ik de IV base64 decode krijg ik een wazig stukje...

Nergens staat een eis beschreven dat de IV een leesbare string moet zijn. Vaak wordt 'ie gerepresenteerd als een 32-bytes lange hexadecimale string. In dit geval zou dat dus "c19c4c2c859b02f6a73f99f93c140572" zijn voor "wZxMLIWbAvanP5n5PBQFcg".

[ Voor 18% gewijzigd door DataGhost op 04-12-2019 17:07 ]

[DataGhost]

Okee, het is zoals ik dacht inderdaad AES, data is de encrypted data, iv is de IV, security is de key. Allemaal zijn Base64-encoded met -_ ipv +/ en de padding ontbreekt. De rest laat ik als oefening voor je Er komt een JSON uit met een storageurl en fileid als je het goed hebt gedaan.

Edit: dit had geen dubbelpost moeten zijn maar helaas werd het dat toch.

[ Voor 24% gewijzigd door DataGhost op 04-12-2019 17:27 ]

[geerttttt]

DataGhost schreef op woensdag 4 december 2019 @ 17:21:
Okee, het is zoals ik dacht inderdaad AES, data is de encrypted data, iv is de IV, security is de key. Allemaal zijn Base64-encoded met -_ ipv +/ en de padding ontbreekt. De rest laat ik als oefening voor je Er komt een JSON uit met een storageurl en fileid als je het goed hebt gedaan.

Edit: dit had geen dubbelpost moeten zijn maar helaas werd het dat toch.

haha jij bent niet van de kant en klare oplossingen he? Een sorageurl is inderdaad PRECIES wat ik zoek. ik ga straks nogmaals proberen, want in eerste instantie kwam ik er nog niet helemaal uit, maar dan moet de oplossing er in zitten dus!

[geerttttt]

DataGhost schreef op woensdag 4 december 2019 @ 17:21:
Okee, het is zoals ik dacht inderdaad AES, data is de encrypted data, iv is de IV, security is de key. Allemaal zijn Base64-encoded met -_ ipv +/ en de padding ontbreekt. De rest laat ik als oefening voor je Er komt een JSON uit met een storageurl en fileid als je het goed hebt gedaan.

Edit: dit had geen dubbelpost moeten zijn maar helaas werd het dat toch.

code:

openssl enc -aes-128-cbc -d -nosalt -K 2B0BC61AC6D40816A9E69DD50AE6BB33 -iv c19c4c2c859b02f6a73f99f93c140572 -in datastring2.enc

Mis ik iets?

[DataGhost]

Ik heb een kort python-scriptje gemaakt om dit te doen, maar ik krijg met jouw commando dezelfde output als met mijn scriptje, dus dat klopt. Aan je vraag te zien leid ik af dat het bij jou niet werkt, heb je data wel base64 decoded voordat je het in datastring2.enc hebt gezet, en is het base64-decoden goed gegaan? datastring2.enc is bij mij 192 bytes groot.

[geerttttt]

DataGhost schreef op woensdag 4 december 2019 @ 20:16:
Ik heb een kort python-scriptje gemaakt om dit te doen, maar ik krijg met jouw commando dezelfde output als met mijn scriptje, dus dat klopt. Aan je vraag te zien leid ik af dat het bij jou niet werkt, heb je data wel base64 decoded voordat je het in datastring2.enc hebt gezet, en is het base64-decoden goed gegaan? datastring2.enc is bij mij 192 bytes groot.

Dit is mijn file, wat heb jij?
https://we.tl/t-SvBLzcsEJs

En mag ik anders je python script proberen?

[geerttttt]

Ah ik heb 'm!

code:

from Crypto.Cipher import AES
import base64
 
key = bytes.fromhex('2B0BC61AC6D40816A9E69DD50AE6BB33')
iv = bytes.fromhex('c19c4c2c859b02f6a73f99f93c140572');


data = "U0u7WfBoVUB7xqk3NrmGLoqpDQXFoFliFWHQbo7tl52FZNE-8-9iJhxP3_K2o1b_5d8YpLBGORLnbEH5IYgKt0g_S5rnPyoCpO2S2LZXkZghwg4qYDRjla7o4zGAVnDApp85MKTqpC1JIU3YQqkg9SubbY7_M4XiqSI_4DSq35PeniVLRaGtvANh4ZTXspbGzwkpxvxehfr1qXXdBYfpkVbD-nGoF9Cbe9TPhuSt_58sHdhzJGxECdloUF6NLUOa";
data = data.replace("-", "+").replace("_", "/");
data = base64.b64decode(data);
print(data);
aes = AES.new(key, AES.MODE_CBC, iv)
print(aes.decrypt(data).decode("utf-8", errors='replace'));

[Boudewijn]

Cool hoe ben je erachter gekomen?

[DataGhost]

geerttttt schreef op woensdag 4 december 2019 @ 21:08:
[...]

Dit is mijn file, wat heb jij?
https://we.tl/t-SvBLzcsEJs

En mag ik anders je python script proberen?

Jouw file lijkt er in de verste verte niet op, als ik 'm base64 encode krijg ik iets als "6zMA1hNOom0CUZ2..." en dat heb ik hier nergens gezien in het topic. Misschien dat je een andere sessie hebt gebruikt?

geerttttt schreef op woensdag 4 december 2019 @ 21:59:
Ah ik heb 'm!

code:

data = data.replace("-", "+").replace("_", "/");
data = base64.b64decode(data);

Fijn dat het zo wel gelukt is. De functie b64decode heeft nog een argument altchars, dus je had de replace kunnen laten zitten en gewoon base64.b64decode(data, "-_") kunnen doen.

Boudewijn schreef op woensdag 4 december 2019 @ 22:00:
Cool hoe ben je erachter gekomen?

Base64 kan je gewoon zien, of in ieder geval gokken. Heel random is dat niet en het ziet er best typisch uit. Verder is AES gewoon een gok omdat dat *de* standaard is en tegenwoordig vrijwel overal in hardware kan, en elke library het heeft en waarschijnlijk ook als default gebruikt. Dat er een IV te zien was duidt op CBC, wat ook behoorlijk standaard is. De key moet toch ergens worden uitgewisseld, dus probeer je gewoon alle waarden die je hebt, in aflopende volgorde van waarschijnlijkheid. Eerst tegen beter weten in "sign", die werd immers met het bericht meegestuurd, daarna "security" en dat was 'm al. Er waren nog een paar opties voordat ik tot de conclusie gekomen zou zijn dat het waarschijnlijk een hardcoded key is in de firmware, maar daar kwam ik gelukkig niet eens aan toe.

[Thralas]

DataGhost schreef op woensdag 4 december 2019 @ 23:23:
Fijn dat het zo wel gelukt is. De functie b64decode heeft nog een argument altchars, dus je had de replace kunnen laten zitten en gewoon base64.b64decode(data, "-_") kunnen doen.

Nog sneller: base64.urlsafe_b64decode

[geerttttt]

Ok, dan toch nog een laatste ding. In het originele bericht wordt ook een sign meegegeven:

code:

result: {
    "data":"U0u7WfBoVUB7xqk3NrmGLoqpDQXFoFliFWHQbo7tl52FZNE-8-9iJhxP3_K2o1b_5d8YpLBGORLnbEH5IYgKt0g_S5rnPyoCpO2S2LZXkZghwg4qYDRjla7o4zGAVnDApp85MKTqpC1JIU3YQqkg9SubbY7_M4XiqSI_4DSq35PeniVLRaGtvANh4ZTXspbGzwkpxvxehfr1qXXdBYfpkVbD-nGoF9Cbe9TPhuSt_58sHdhzJGxECdloUF6NLUOa",
    "sign":"fV12WdlPo8VnJznjIGTgxr7MYlDgEddExfO_I8TDgXE",
    "iv":"wZxMLIWbAvanP5n5PBQFcg"}

Ik gok dat dat een (gebase64de?) hash ofzo is. Wederom alleen helaas geen idee hoe ik hier wat leesbaars van wil maken, ik wil immers de data wijzigen, maar dat accepteert hij niet zonder goede sign...

[DataGhost]

Oh, ja. Volgens mij kwam daar iets uit van 32 bytes lang, dus 256 bits. Zal wel SHA256 zijn, maar er zijn andere mogelijkheden natuurlijk. En de vraag is wat er precies allemaal in de hash zit. Het kan alleen data zijn, het kan ook meer dan dat zijn. Ik krijg er in ieder geval voor wat simpele pogingen voor de data niet dezelfde output uit als sign met SHA256 of HMAC-SHA256 met de key.

[ Voor 21% gewijzigd door DataGhost op 05-12-2019 09:48 ]

[geerttttt]

DataGhost schreef op donderdag 5 december 2019 @ 09:32:
Oh, ja. Volgens mij kwam daar iets uit van 32 bytes lang, dus 256 bits. Zal wel SHA256 zijn, maar er zijn andere mogelijkheden natuurlijk. En de vraag is wat er precies allemaal in de hash zit. Het kan alleen data zijn, het kan ook meer dan dat zijn. Ik krijg er in ieder geval voor wat simpele pogingen voor de data niet dezelfde output uit als sign met SHA256 of HMAC-SHA256 met de key.

32 bytes idd. SHA256 zou kunnen, maarja, wat dan idd. Ik zal wat mogelijkheden proberen, een hash van de data ofzo. Ik weet niet echt wat common practices zijn hierin. Data hashen en dan sha256-en?

[DataGhost]

Ummm... SHA256 is zelf al een hash-functie, dus je hoeft je data niet eerst te hashen voordat je 'm "sha256-t". Maar doorgaans pak je gewoon al je data achter elkaar geplakt en hash je dat. Dat kan dus meer zijn dan alleen de JSON die je krijgt na decryptie, daar kunnen timestamps bij zitten, IP's waartussen gecommuniceerd wordt, een salt, eigenlijk alles wat aan beide kanten bekend is. Als ik de decrypted JSON hash met SHA256 of HMAC-SHA256 krijg ik niet dezelfde hash als "sign", dus dat betekent dat er meer data is meegehasht. Het probleem daarmee is dus dat je niet weet welke data dat precies is, en op welke volgorde. Je kan een stapel opties verzinnen en een scriptje schrijven wat alle mogelijke permutaties daarvan probeert.

Hierbij doe ik gewoon de aanname SHA256 volgens grotendeels dezelfde redenering waarmee ik op AES ben uitgekomen. Het kan ook BLAKE256 of een ander 256-bits hashfunctie zijn, of een grotere hashfunctie waarvan alle bits op 256 na zijn weggegooid, maar die opties zijn allemaal ietsjes minder waarschijnlijk.

[geerttttt]

Got it!
Het blijkt het volgende te zijn:

code:

base64_encode(hex2bin(hash("sha256", $enc_data.$IV)))

Combi van de encoded data met daarachteraan de IV in het originele base64 formaat geplakt dus

[Anoniem: 160587]

Ik volg je topic met aandacht, is het wellicht een idee een tweakblog of ergens anders precies te omschrijven hoe je uiteindelijk het voor elkaar hebt gekregen? Denk dat je veel mensen ermee kan inspireren :-) (of een github repo met instructies bijv.)

[DataGhost]

geerttttt schreef op donderdag 5 december 2019 @ 15:34:
Combi van de encoded data met daarachteraan de IV in het originele base64 formaat geplakt dus

Dat is wel heel letterlijk "al je data (die aan beide kanten bekend is) achter elkaar geplakt" Ook wel logisch, anders kreeg je bij dezelfde plaintext dezelfde signature als bijv. de iv niet werd meegehasht. Dan kon je daaraan afleiden dat beide berichten hetzelfde waren, ook al heb je dezelfde ciphertext. Daar had ik wel iets eerder aan mogen denken. Top dat het gelukt is!

[geerttttt]

We gaan nog even door voor de koelkast. We zijn nu op het punt uitgekomen dat de server mij twee files stuurt, een video en een png plaatje. Deze sla ik netjes op maar zijn helaas wederom versleuteld!

Laatste hobbel dus, hoe ontsleutelen we dit nu weer. De data:
https://we.tl/t-JxvfppQ0BF

Dit is de file, hier de metadata die meekomt met de transfer:

code:

"iv":"kiWfo5SAQkG6wsCuuTtjsQ",
"signature":"4wf11h0hCCYOR3Cb7-mPSVwmf7PQos_LChu6w_70oMg",
"fileId":"0e4EPYOjIdSPAlzpYaoNjLaAutQaxr_KImkz1PqWWDQ",
"fileType":"X1Nlze5Wt_zq7Qx30lf4_w",
"offset":"ERpVS-M5-m2pTyDAs1IMDA",
"expireTime":"i1BweHQbFuUiulWWHB3rHQ",
"model":"HJaeh8hiSy_tBFrGLIdiHmoE6gQ7F4Y_MrgfgQHBTgg",
"videoSign":"K4DbT5SS0OCC6copPbHjqlfP9T1u9ThTs6N3yg6r3TJ7ne_dHTE3ahdIvd_jLIOs",
"imgSign":"NkcSI9ioyfQcJWUU0dChyM2NsijwvGL1Nwkt3OGtVSBfYqZTRMnUIDBjblFyBSt_"

Ik heb de IV geprobeerd met de imgSign als key, maar de imgSign is geen 16 of 32 bits code... dat is raar.
De signature heb je ook nog, probeerde ik ook, is wel de goede lengte, maar helaas, de data die ik krijg lijkt niet echt op een PNG'tje.

Iemand tips wederom?

[I_IBlackI_I]

Misschien ook een idee om het topic een iets specifiekere titel te geven? Wellicht: Xiaomi (netwerkverkeer) encryptie kraken.

Erg interessant om dit te volgen. Het einddoel is om dus een selfhosted back-end te maken waarmee je de apparaten aan kan sturen / uit kan lezen?

[Ryanirin]

geerttttt schreef op donderdag 5 december 2019 @ 16:54:
We gaan nog even door voor de koelkast. We zijn nu op het punt uitgekomen dat de server mij twee files stuurt, een video en een png plaatje. Deze sla ik netjes op maar zijn helaas wederom versleuteld!

Laatste hobbel dus, hoe ontsleutelen we dit nu weer. De data:
https://we.tl/t-JxvfppQ0BF

Dit is de file, hier de metadata die meekomt met de transfer:

code:

"iv":"kiWfo5SAQkG6wsCuuTtjsQ",
"signature":"4wf11h0hCCYOR3Cb7-mPSVwmf7PQos_LChu6w_70oMg",
"fileId":"0e4EPYOjIdSPAlzpYaoNjLaAutQaxr_KImkz1PqWWDQ",
"fileType":"X1Nlze5Wt_zq7Qx30lf4_w",
"offset":"ERpVS-M5-m2pTyDAs1IMDA",
"expireTime":"i1BweHQbFuUiulWWHB3rHQ",
"model":"HJaeh8hiSy_tBFrGLIdiHmoE6gQ7F4Y_MrgfgQHBTgg",
"videoSign":"K4DbT5SS0OCC6copPbHjqlfP9T1u9ThTs6N3yg6r3TJ7ne_dHTE3ahdIvd_jLIOs",
"imgSign":"NkcSI9ioyfQcJWUU0dChyM2NsijwvGL1Nwkt3OGtVSBfYqZTRMnUIDBjblFyBSt_"

Ik heb de IV geprobeerd met de imgSign als key, maar de imgSign is geen 16 of 32 bits code... dat is raar.
De signature heb je ook nog, probeerde ik ook, is wel de goede lengte, maar helaas, de data die ik krijg lijkt niet echt op een PNG'tje.

Iemand tips wederom?

Je hebt een key nodig. Had je niet eerder ook een keer een key nodig?

Voor de leuk verder een leuke tool die je goed voor dit soort dingen kan gebruiken om te 'spelen' met parameters en opties enzo; CyberChef. Dit is bijvoorbeeld de eerste 'challenge' die je gaf als cyberchef recept:

https://gchq.github.io/Cy...Gh6Skd4RUNkbG9VRjZOTFVPYQ

[geerttttt]

Ryanirin schreef op donderdag 5 december 2019 @ 17:31:
[...]


Je hebt een key nodig. Had je niet eerder ook een keer een key nodig?

Voor de leuk verder een leuke tool die je goed voor dit soort dingen kan gebruiken om te 'spelen' met parameters en opties enzo; CyberChef. Dit is bijvoorbeeld de eerste 'challenge' die je gaf als cyberchef recept:

https://gchq.github.io/Cy...Gh6Skd4RUNkbG9VRjZOTFVPYQ

Dat is een leuke tool, heb een paar varianten geprobeerd maar helaas nog geen succes...

Eerder had ik idd ook een key nodig, die heb ik ook geprobeerd, maar ook met die optie krijg ik rommel als output

Tevens zit er nog een token.cfg in het filesystem van de deurbel die mogelijk hier iets mee te maken heeft?

code:

320de55719e86e1d0f35df9d79db8395

lastig!

[Ryanirin]

geerttttt schreef op donderdag 5 december 2019 @ 17:37:
[...]

Dat is een leuke tool, heb een paar varianten geprobeerd maar helaas nog geen succes...

Eerder had ik idd ook een key nodig, die heb ik ook geprobeerd, maar ook met die optie krijg ik rommel als output

Tevens zit er nog een token.cfg in het filesystem van de deurbel die mogelijk hier iets mee te maken heeft?

code:

320de55719e86e1d0f35df9d79db8395

lastig!

Mijn vorige opmerking was bedoeld als hint naar de oplossing!
Ik heb in ieder geval een werkend plaatje eruit gekregen Wellicht gaat er iets mis met je code. Ik heb enkel cyberchef en de AES Decrypt functie gebruikt. Verder kun je een bestand uploaden als input en de output weer downloaden als bestand.

[geerttttt]

Jaa ik heb hem!
https://gchq.github.io/Cy...put=%5Bobject%20Object%5D

[geerttttt]

Ryanirin schreef op donderdag 5 december 2019 @ 17:42:
[...]


Mijn vorige opmerking was bedoeld als hint naar de oplossing!
Ik heb in ieder geval een werkend plaatje eruit gekregen Wellicht gaat er iets mis met je code. Ik heb enkel cyberchef en de AES Decrypt functie gebruikt. Verder kun je een bestand uploaden als input en de output weer downloaden als bestand.

Haha, die hint had ik niet helemaal begrepen. Ik heb hem bij toeval nu ook, heb idd verschillende opties geprobeerd. Bijzonder dat er een JFIF uit komt, als ik het goed herriner is dat een jpeg, geen png... Maar mooi! nu nog verwerken in mijn script!

[geerttttt]

Tijd om even wat Q&A te doen:

Anoniem: 160587 schreef op donderdag 5 december 2019 @ 15:49:
Ik volg je topic met aandacht, is het wellicht een idee een tweakblog of ergens anders precies te omschrijven hoe je uiteindelijk het voor elkaar hebt gekregen? Denk dat je veel mensen ermee kan inspireren :-) (of een github repo met instructies bijv.)

Ha leuk! Misschien leuk om idd een keer een wrap-up te schrijven van hoe alles werkt Leuk dat je het graag leest.

I_IBlackI_I schreef op donderdag 5 december 2019 @ 17:17:
Misschien ook een idee om het topic een iets specifiekere titel te geven? Wellicht: Xiaomi (netwerkverkeer) encryptie kraken.

Erg interessant om dit te volgen. Het einddoel is om dus een selfhosted back-end te maken waarmee je de apparaten aan kan sturen / uit kan lezen?

Klopt, dan kan ik de data lokaal opslaan en met een eigen app de afgelopen meldingen bekijken. Bovendien krijg ik nu een melding op telegram als iemand op de deurbel drukt (dat vang ik af via het 433 signaal dat hij stuurt). Nu kan ik daarna ook een fototje meesturen via Telegram zodat ik direct weet wie er belt.

Plus, de Xiaomi app zuigt vrij hard... Voor de stofzuiger die ik van hun heb werkt hij goed, hiervoor echt totaal niet. En de cloud opslag is maar 3 dagen.

DataGhost schreef op donderdag 5 december 2019 @ 16:22:
[...]

Dat is wel heel letterlijk "al je data (die aan beide kanten bekend is) achter elkaar geplakt" Ook wel logisch, anders kreeg je bij dezelfde plaintext dezelfde signature als bijv. de iv niet werd meegehasht. Dan kon je daaraan afleiden dat beide berichten hetzelfde waren, ook al heb je dezelfde ciphertext. Daar had ik wel iets eerder aan mogen denken. Top dat het gelukt is!

Ja had ik zelf ook wel wat eerder mogen bedenken dat dit een optie is dan eerst van alles aan andere dingen te proberen. Maar hoera, ik krijg nu de afbeeldingen keurig door