Base64 decoding

[ZeroHero]

Tweakers,

Ik heb een e-mail in een .txt bestand doorgestuurd gekregen. In de oorspronkelijke e-mail zaten 6 afbeeldingen in de bijlage. Deze heb ik nu als ik het goed begrijp als base64 in het bestand staan. Als de begeleidende tekst van de e-mail in het .txt bestand eindigt start het volgende

Content-Type: application/octet-stream; name="IMG_20160326_133316.jpg","IMG_20160326_133317.jpg", "IMG_20160327_125880.jpg","IMG_20160325_133310.jpg", "fileEv2bfWYMAAAArecubthmayb5.jpg","fileFT5hHU7hreYG7la23YEt8zT.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment /9j/4AAQS.................

Op de plaats van de puntjes gaat het nog pagina's lang door met base64. Aangezien het om chantage en eventueel gevoelige informatie gaat kan ik de volledige code zelf helaas niet delen.

Als ik nu deze complete code in een online base64 decoder gooi, dan komt daar na een tijdje een bestand uit met bovenaan een gedeelte van een afbeelding en verder een grijs vlak. Ik heb het idee omdat het hier om meerdere afbeeldingen gaat dat ik ze wellicht afzonderlijk in de decoder moet invoeren. Ik heb echter geen idee waar een afbeelding start of eindigt. Zijn er misschien standaard begin en eindtags zodat ik ze kan scheiden en het vervolgens in kan voeren?

Met andere woorden, hoe kom ik van alle base64 naar 6 afbeeldingen die ik kan zien?

Ik hoop dat jullie mij kunnen helpen.

[begintmeta]

Het gaat om jpeg-bestanden zo te zien? Misschien heb je iets aan de beschrijving in Wikipedia: JPEG/Wikipedia: JPEG File Interchange Format

[ Voor 43% gewijzigd door begintmeta op 14-06-2016 15:19 ]

[ZeroHero]

Dank begintmeta. Het lukt me echter nog steeds niet. Begrijp ik het goed dat de afbeeldingen beginnen met 4A?

[Ventieldopje]

ZeroHero schreef op dinsdag 14 juni 2016 @ 15:33:
Dank begintmeta. Het lukt me echter nog steeds niet. Begrijp ik het goed dat de afbeeldingen beginnen met 4A?

Nee, de afbeeldingen beginnen met FF D8 (start of image) maar daar heb je weinig aan als de afbeeldingen base64 encoded zijn natuurlijk

Enfin, eerste stap is om base64 om te zetten in de originele data, dat doe je dus inderdaad met zo'n base64 decoder (online of offline, stelt niet veel voor). Daarna kun je met een hex editor op zoek gaan naar de SOI en EOI (start / end of image) en de bestanden daar op te splitten (kan als het goed is ook met bijv. WinHex).

Met een beetje geluk heb je dan gewoon je foto's weer terug al kun je natuurlijk niet garanderen dat de foto's onbeschadigd zijn verzonden.

(psst. het lijkt gewoon op een EML bestand. Waarom niet het EML bestand openen met een email client?)

[ Voor 5% gewijzigd door Ventieldopje op 14-06-2016 15:44 ]

[CyBeR]

Inderdaad, hernoem dat ding naar .eml en laat je mail viewer het openen.

[ZeroHero]

Als ik hem naar .eml vernoem krijg ik dezelfde tekst incl de base64 alleen dan in mail viewer.

Totaal geen verstand van programmeren of coderen, maar met jullie hulp en wat Googlen heb ik het volgende gedaan. Ik heb de base64 online naar een .bin file omgezet en deze nu geopend met een Hex Editor. Ik vind nu 10x FF D8 (SOI) en 15x FF D9 (EOI). Op zich al vreemd lijkt mij?

Naast de HEX notitatie in de editor zie ik een kolom met andere tekens. Hoe moet ik dit nu splitten en waar moet ik deze code in plakken?

[P.O. Box]

ZeroHero schreef op dinsdag 14 juni 2016 @ 15:13:
Tweakers,

Ik heb een e-mail in een .txt bestand doorgestuurd gekregen. In de oorspronkelijke e-mail zaten 6 afbeeldingen in de bijlage. Deze heb ik nu als ik het goed begrijp als base64 in het bestand staan. Als de begeleidende tekst van de e-mail in het .txt bestand eindigt start het volgende

Content-Type: application/octet-stream; name="IMG_20160326_133316.jpg","IMG_20160326_133317.jpg", "IMG_20160327_125880.jpg","IMG_20160325_133310.jpg", "fileEv2bfWYMAAAArecubthmayb5.jpg","fileFT5hHU7hreYG7la23YEt8zT.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment /9j/4AAQS.................

Op de plaats van de puntjes gaat het nog pagina's lang door met base64. Aangezien het om chantage en eventueel gevoelige informatie gaat kan ik de volledige code zelf helaas niet delen.

Als ik nu deze complete code in een online base64 decoder gooi, dan komt daar na een tijdje een bestand uit met bovenaan een gedeelte van een afbeelding en verder een grijs vlak. Ik heb het idee omdat het hier om meerdere afbeeldingen gaat dat ik ze wellicht afzonderlijk in de decoder moet invoeren. Ik heb echter geen idee waar een afbeelding start of eindigt. Zijn er misschien standaard begin en eindtags zodat ik ze kan scheiden en het vervolgens in kan voeren?

Met andere woorden, hoe kom ik van alle base64 naar 6 afbeeldingen die ik kan zien?

Ik hoop dat jullie mij kunnen helpen.

Als het goed is komt er in je bestand 6x het volgende voor:
"Content-Type: application/octet-stream; "

wat je nu in je base64 decoder moet gooien is alles vanaf "/9j/" (inclusief /9j/") tot de eerste lege regel die je tegenkomt... daarna zal weer een blok komen met Content-Type... dat proces herhaalt zich 6 x

[ZeroHero]

Ik zie een keer die tekst en daarna de hele base64 code. Niet verschillende alinea's met Content.

[Onbekend]

ZeroHero schreef op dinsdag 14 juni 2016 @ 15:13:
Als ik nu deze complete code in een online base64 decoder gooi, dan komt daar na een tijdje een bestand uit met bovenaan een gedeelte van een afbeelding en verder een grijs vlak. Ik heb het idee omdat het hier om meerdere afbeeldingen gaat dat ik ze wellicht afzonderlijk in de decoder moet invoeren. Ik heb echter geen idee waar een afbeelding start of eindigt. Zijn er misschien standaard begin en eindtags zodat ik ze kan scheiden en het vervolgens in kan voeren?

Met andere woorden, hoe kom ik van alle base64 naar 6 afbeeldingen die ik kan zien?

Ik hoop dat jullie mij kunnen helpen.

Weet je zeker dat het 1 groot blok van base64-data is? Niets gescheiden door een spatie, backslash of een ander bijzonder teken?
Het oorspronkelijke e-mailbericht moet namelijk ook weten waar de andere afbeeldingen beginnen, want anders zou deze eerst de rest moeten decoderen voordat deze de betreffende afbeelding kan laten zien..

[Compizfox]

Misschien mis ik iets, maar een foto (een JPEG tenminste) zou toch Content-Type: image/jpeg moeten hebben in plaats van application/octet-stream?

In elk geval, als je meerdere foto's in die email hebt, dan zou je inderdaad meerdere blokken met base64 moeten hebben, elk voorafgegaan van een boundary aangegeven in de header van de mail (zoek naar Content-Type: multipart/mixed; boundary=) en wat headers.

[ Voor 46% gewijzigd door Compizfox op 14-06-2016 23:15 ]

[DJMaze]

Ik keek even naar de headers en het probleem zit hem in de volgende header

code:

Content-Type: application/octet-stream; name="IMG_20160326_133316.jpg","IMG_20160326_133317.jpg", "IMG_20160327_125880.jpg","IMG_20160325_133310.jpg", "fileEv2bfWYMAAAArecubthmayb5.jpg","fileFT5hHU7hreYG7la23YEt8zT.jpg"

Het is maar 1 bestand, niet 6 zoals jij denkt.
Ook bestaat een "comma separated" lijst helemaal niet, zie http://tools.ietf.org/html/rfc2045#section-5.1

[P.O. Box]

kan het zijn dat boven je ge-paste content-type nog iets staat m.b.t. encryption?
bijv:
Content-Type: application/pgp-encrypted; name="msg.asc"

quote: https://en.wikipedia.org/wiki/MIME

Encrypted
A multipart/encrypted message has two parts. The first part has control information that is needed to decrypt the application/octet-stream second part. Similar to signed messages, there are different implementations which are identified by their separate content types for the control part. The most common types are "application/pgp-encrypted" (RFC 3156) and "application/pkcs7-mime" (S/MIME).

ik krijg namelijk het vermoeden dat er twee keer een encoding overheen gegaan is om 6 afbeeldingen in 1 blok te encoden. En omdat je aangeeft dat het om gevoelige info gaat dacht ik, misschien is het encrypted?

overigens zie ik dit ook wel eens gebeuren als de mailclient de headers niet snapt... heb je hem al eens geprobeerd te openen in een andere mailclient? (of vragen of de verzender het mailtje naar een ander adres kan sturen bijv. hotmail, of juist niet hotmail)

[ Voor 27% gewijzigd door P.O. Box op 15-06-2016 00:03 ]

[RobIII]

Is het niet gewoon een zipfile (of ander container type) met daarin de 4 betreffende bestanden?

[Compizfox]

P.O. Box schreef op woensdag 15 juni 2016 @ 00:01:
kan het zijn dat boven je ge-paste content-type nog iets staat m.b.t. encryption?
bijv:
Content-Type: application/pgp-encrypted; name="msg.asc"


[...]


ik krijg namelijk het vermoeden dat er twee keer een encoding overheen gegaan is om 6 afbeeldingen in 1 blok te encoden. En omdat je aangeeft dat het om gevoelige info gaat dacht ik, misschien is het encrypted?

overigens zie ik dit ook wel eens gebeuren als de mailclient de headers niet snapt... heb je hem al eens geprobeerd te openen in een andere mailclient? (of vragen of de verzender het mailtje naar een ander adres kan sturen bijv. hotmail, of juist niet hotmail)

PGP/MIME? Kans lijkt me klein. Bovendien, als de boel encrypted was dan zou TS geen gedeelte van een plaatje kunnen decoden met die base64 decoder.

Met "gevoelig" bedoelde TS denk ik eerder "niet bedoeld om met het hele internet te delen".

[ Voor 5% gewijzigd door Compizfox op 15-06-2016 00:08 ]

[P.O. Box]

Compizfox schreef op woensdag 15 juni 2016 @ 00:05:
[...]

PGP/MIME? Kans lijkt me klein. Bovendien, als de boel encrypted was dan zou TS geen gedeelte van een plaatje kunnen decoden met die base64 decoder.

goed punt... maar toch denk ik dat de headers boven de ge-paste headers nog wel eens voor verheldering kunnen zorgen

[Mijzelf]

ZeroHero schreef op dinsdag 14 juni 2016 @ 15:13:
Zijn er misschien standaard begin en eindtags zodat ik ze kan scheiden en het vervolgens in kan voeren?

Een base64 encoded block eindigt met 1 of 2 '=' tekens. Deze komen verder niet voor in het block.

[Creepy]

Is het heel gek om aan diegene van wie je het bestand hebt gehad te vragen wat je er mee moet? Nu moet iedereen blijven gokken. Diegene die het heeft gemaakt weet vast hoe het in elkaar steekt

[RobIII]

Mijzelf schreef op woensdag 15 juni 2016 @ 09:36:
[...]
Een base64 encoded block eindigt mogelijk met 1 of 2 '=' tekens. Deze komen verder niet voor in het block.

FTFY
De = is padding; die wordt alleen toegevoegd wanneer de lengte van de input niet deelbaar is door 3 (en er zijn zat implementaties die de padding gewoon achterwege laten, werkt ook meestal, maar dat terzijde).

[ Voor 9% gewijzigd door RobIII op 15-06-2016 10:44 ]

[SaphuA]

.

[ Voor 104% gewijzigd door SaphuA op 31-01-2022 14:46 ]

[DJMaze]

ZeroHero schreef op dinsdag 14 juni 2016 @ 17:33:
Ik vind nu 10x FF D8 (SOI) en 15x FF D9 (EOI). Op zich al vreemd lijkt mij?

Dat is niet vreemd. Een afbeelding kan metadata bevatten (exif, ifd, iptc, etc.).
In die metadata is een optie voor "thumbnail" wat de zelfde afbeelding is, maar dan kleiner.

Na de FF D8 komen de data markers, eventueel met voorloop FF.
Bijvoorbeeld: FF D8 FF E0 00 10

• E0 betekend JFIF/JFxx
• 00 10 is vervolgens de lengte in bytes (32bit unsigned short) inclusief de "size/lengte". De metadata is dus 16 - 2 = 14 bytes lang. En maximaal 65535 - 2 bytes lang

Daarna komt een nieuw metadata blok, het ziet er dan uit als:

code:

FF D8
FF E0 00 10 4A 46 49 46 00 01 02 00 00 01 00 01 00 00
FF FE 00 04 2A 00
FF E2 02 1C ......
.....
FF DA [hier is de gecomprimeerde afbeelding]
FF D9

Ik denk dat je hiermee een heel eind komt


Zie ook mijn vorige post: DJMaze in "Base64 decoding"

Zonder de daadwerkelijke bron is iedereen nu wel aan het koffiedik kijken.

[ Voor 66% gewijzigd door DJMaze op 16-06-2016 12:07 ]