LR4DINC4PA3DCXDYG42FY6BSGBOHQNSDLR4DMOK4PA3DOXDYG42FY6BSGBOHQNRVLR4DMNK4PA3EKXDYGIYFY6BWGJOHQNRVLR4DMNK4PA3TIXDYGZAVY6BWGVOHQMRQLR4DMMK4PA3DCXDYGZCVY6BSGBOHQNRYLR4DMNK4PA3TIXDYGIYFY6BWGROHQNSGLR4DMNK4PA3EGXDYGJBVY6BSGBOHQNSELR4DMMK4PA3DCXDYG4ZFY6BSGBOHQNRZLR4DMQS4PAZDAXDYG43FY6BWHFOHQNSFLR4DMNC4PAZDAXDYGU2VY6BVGROHQNBWLR4DERC4PAZTQXDYGIYFY6BWGFOHQNSDLR4DONC4PA3DSXDYGZAVY6BWGROHQMRQLR4DON24PA3DKXDYGZBVY6BSGBOHQNRWLR4DMOK4PA3ECXDYGZCVY6BSGBOHQNZWLR4DMRS4PA3EMXDYG4ZFY6BSGBOHQMRSLR4DMN24PA3DKXDYG43VY6BWIZOHQNSFLR4DMNK4PAZDEXDYGIYFY6BXGROHQNRVLR4DMQS4PA3TGXDYG42FY6BWGVOHQNSFLR4DERI=

;-)

K5UWKIDENF2CA3DFMVZXIIDJOMQGOZLLBIFEO33FOJXWK2DPMVSGUZLT

JFVSA5DXNFVGMZLMMRSSA3TPM4QG2ZLUEBBECU2FGY2C4ICNMFQXEIDENFSSA2L
TEBRWC43FEBZWK3TTNF2GSZLWMUXA====

Edit: de code laat geen returns toe, maar zonder returns valt de tekst weg zoals bij de 1e anoniem. Heb nu returns toegevoegd om alles in het veld te krijgen. Dat zal ook de reden van de edit bij Vixen geweest zijn.

https://gchq.github.io/CyberChef/ is een leuke tool om de berichtjes in de poll en comments te onderzoeken

JJQSYIDJMRSC4LROEBHG633JOQQGKZLSMRSXEIDCMFZWKMZSEBXG6ZDJM4QGOZLIMFSCYIDNMFQX
EIDUN5RWQIDXMVSXEIDXMF2CA5TPN5ZCAJ3UEBSWK4TTOQQGOZLEMFQW4IDWMFXGIYLBM4XC4LQK

I5SWS3TJM4QHI33PNR2GUZJAIRQW42LFNRDSYIDWMVZGIZLSEBVGC3LNMVZCA5TBNYQGIZJAN5XHU2LONZUWOZJAOZZGCYLHFYQEOZLMOVVWW2LHEBUGKYRANFVSA53FNQQGKZLSON2CAZ3FNRSXUZLOEBSW4IDEMFQXE3TBEBQWY43ON5TSA3TJMV2CAZ3FON2GK3LEEA5S2KI=

You've got me ;-)

Dit was mijn password, goed geraden.

KN2XAZLSORXWMIDENF2CC

k vi vl r, als je dit vind ;-)-h3ca1b4g6gt8b6b4d7i3cy0clinj6h4uo8bwi

UiP9AV6Y

JBSWKLBAMRQXIIDJOMQG42LFOQQGCYLSMRUWOIIK

KRUWUZBAOZXW64RAMVSW4IDXN5ZHG5DFNZRHE33PMRVGKIDEMFXCA3LBMFZCAORJ

Leg dit eens op een simpele manier uit ,ik heb n.l geen verstand van cryptografie.

Jullie ook de beste wensen voor 2017

https://en.wikipedia.org/wiki/Binary-to-text_encoding

Wikipedia heeft er een artikel over wat het veel beter uit kan leggen dan ik. ;-)

Duidelijk Base32 , geen twijfel mogelijk .

En ik heb niet een echte favoriet eerlijk gezegd .

IFWGYZLFNYQGOZLLNNSW4IDFNYQGI53BPJSW4IDTMNUHE2LKOZSW4IDPOAQGIZLVOJSW4IDFNYQGO3DBPJSW4===

NJSSA3LPMVSGK4RB

Het gaat hierbij niet om cryptografie, maar om coderen en decoderen.

Zo hebben wij op de basisschool leren "coderen" hoe je de letter a schrijft, uitspreekt en in woorden gebruikt. Computers hebben niets met letters maar werken met nullen en enen genaamd bits - meestal in groepjes van 8 (zo'n groepje noemen we een byte).

Voordat er computers waren werd er al serieel, bit voor bit dus, informatie overgedragen. Die informatie (meestal tekst) moest worden gecodeerd (in de juiste nullen en enen, en in de juiste volgorde) en aan de kant van de ontvanger weer worden gedecodeerd. Om dat reproducerend te kunnen doen werden afspraken gemaakt welk bitpatroon een bepaalde letter, cijfer of leesteken voorstelde.

Een uit dat tijdperk, maar nog steeds veelgebruikte standaard, is ASCII (American Standard Code for Information Interchange [1]). Elk "teken" in die "karakterset" is 7 bits breed, en dat past natuurlijk prima in een byte (van 8 bits).

Helaas verspil je daarbij elke keer een bit, en doordat een aantal "tekens" helemaal geen letters, cijfers of leestekens zijn, verspil je nog meer ruimte: de eerste 32 codes zijn namelijk non-printable besturingscodes waarvan er enkele nog veel worden gebruikt:

Daarnaast zijn er tekens die, bij seriële overdracht, aangeven wanneer het bericht begint (STX, Start of Text) en wanneer het hele bericht is ontvangen (ETX, End of Text) - maar die worden nauwelijks nog gebruikt.

Met ASCII kun je, zei het wat verspillend bij 8 bits per karakter, prima platte tekst uitwisselen (en opslaan). Deze ASCII encoding werd al toegepast bij de eerste computers met o.a. MS-DOS en Unix, maar ook bij de eerste internetprotocollen waaronder UUCP, Telnet, FTP en SMTP.

En dat gaf al snel problemen, want er zijn veel talen met karakters die buiten de ASCII tekens vallen, en ook (andere) "binaire" data (waarbij alle 256 combinaties van bits in elke byte kunnen voorkomen, zoals bij foto's of MP3tjes) kun je niet zonder meer uitwisselen via een ASCII verbinding, iets dat nog steeds geldt voor SMTP (e-mail).

Om een binair bestand via e-mail te verzenden is een truc nodig: je moet bytes uit het bestand vóór verzending omzetten in een stroom "leesbare" ASCII tekens (leesbaar in de zin van dat je een nietszeggende reeks van letters, cijfers en leestekens ziet). De ontvanger moet het omgekeerde doen. Ook deze processen heten resp. coderen en decoderen (niet in de zin van versleutelen, maar omzetten of vertalen).

Daar zijn verschillende protocollen voor uitgevonden, waaronder uuencode [2]. Dat werkt, vereenvoudigd, als volgt:
- neem 3 bytes van het binaire bestand, 24 bits dus
- splits dit in 4 groepjes van 6 bits, en plaats deze in een buffer (tijdelijk stukje geheugen) van 4 bytes
- tel bij elk van die bytes decimaal 32 op
- verzend de 4 bytes (elk met een decimale waarde tussen 32 en 95, beide inclusief)
- herhaal dit tot het hele bestand verzonden is (indien het bestand geen veelvoud van 3 bytes lang is, gebruik je "vulbytes" en stuur je de werkelijke lengte er achteraan).

De ontvanger doet het omgekeerde en verkrijgt zo een exacte kopie van het binaire bestand. Als de ontvanger naar de "source" van de e-mail zou kijken, zou zij, in plaats van de bijlage, zo'n onsamenhangende reeks van letters, cijfers en leestekens zien.

Overigens is dit behoorlijk bandbreedte- en opslagruimteverspillend en het is exact de reden waarom e-mails met een grote bijlage (zoals een niet in-aantal-pixels verkleinde digitale foto) ca. anderhalf keer zo groot zijn (in MegaBytes) als de bijlage zelf op schijf.

En nu maar stemmen!

[1] https://en.wikipedia.org/wiki/ASCII
[2] https://en.wikipedia.org/wiki/Uuencoding

Ik heb nu ook gemerkt dat je de tekst die je niet ziet, wel kunt kopiëren. Jouw tekst decodeert perfect leesbaar, maar die van de 1e anoniem levert bij mij:
Gebruikte site voor decoderen: https://emn178.github.io/online-tools/base32_decode.html

Gebruik een string (de)escaping tool en je kunt zijn of haar bericht zien.

En daarmee heb je zojuist zonder het door te hebben een belangrijk security risico herontdekt.

Namelijk dat what you see is not necessarily what you get.
Omdat tekst buiten de gedefinieerde opmaak kan vallen en eronder doorloopt.

Daar kan bijvoorbeeld goed misbruik van worden gemaakt met terminal commands.

Wat oude waarschuwingen
https://www.reddit.com/r/netsec/comments/1bv359/dont_copypaste_from_website_to_terminal_demo/
https://news.ycombinator.com/item?id=10554679
https://blog.malwarebytes.com/threat-analysis/2016/05/clipboard-poisoning-attacks-on-the-mac/

Hoewel een browser als bijvoorbeeld Firefox het zelf niet aangeeft kun je in die browser met commando "cmd U" de html pagina code opvragen en zijn de hele antwoorden te lezen en ook daarna te kopiëren.

Let erop, er is soms meer dan wat je ziet!


@ Erik dank voor de interessante uitleg rondom o.a. email bijlagen.

QmFzZTY0LCBtYWtrZWxpamssIGVjaHQgd2VsLiBFbiBkZSBiZXN0ZSB3ZW5zZW4gdm9vciAyMDE3IGFsbGVtYWFsISA6LSk=

Base64 een simpele manier om binaire code te converteren naar ASCII.
K5QXIIDJOMQGU33VO4QGMYLWN5ZGSZLUMUQGK3TDN5SGS3TH

Gewoon UTF-8

Malware....

Nee, dank je. Geen interesse

FYXC4RLOEBUGCYLMEBSGCYLSNZQSA2DFOQQHEZLTOVWHIYLBOQQGI33POI5CAW3VOJWF22DUORYDULZPO53XOLTSMFYGSZDUMFRGYZLTFZRW63JPMNXW45TFOJ2C63TVNVRGK4RPNBSXQLLUN4WWC43DNFUS42DUNVNS65LSNROSA===

Anoniem 14:46: Dat is de verkeerde codering omdat de gevraagde alleen hoofdletters en cijfers bevat.

Anoniem 17:17: Ik wist al 99% zeker dat het excaped hex ascii code was. Ik had alleen geen zin om dat handmatig over te tikken om te lezen. Met jouw link ging dat nu als een speer.

\x57\x61\x74\x20\x69\x73\x20\x6A\x6F\x75\x77\x20\x66\x61\x76\x6F\x72\x69\x65\x74\x65\x20\x65\x6E\x63\x6F\x64\x69\x6E\x67