Privébericht met onbekend teken kan PlayStation 4 in bootloop zetten

PlayStation 4-gebruikers maken melding van een privébericht dat hun console een bootloop in stuurt. Het probleem is te voorkomen door berichten van alleen vrienden of helemaal niemand toe te staan.

Het bericht bevat volgens Redditposters een teken dat niet weergegeven kan worden, waarna in- en outputs uitvallen en herstarten een bootloop oplevert. Volgens de meldingen kan het probleem voorkomen worden door het bericht op de console ongeopend te laten en te verwijderen via de PS4-berichtenapp. Voor wie het bericht al geopend heeft, lijkt een factory reset de enige remedie, eventueel gevolgd door een database rebuild vanuit safe mode.

De problemen lijken zich sinds dit weekend voor te doen. In sommige gevallen worden hele groepen spelers tegelijk getroffen door het probleem door middel van een groepsgesprek. Waarschijnlijk doet het probleem zich voor op iedere variant van de PlayStation 4, aangezien ze dezelfde firmware draaien. Sony heeft nog niet gereageerd op verzoeken tot commentaar van bijvoorbeeld Kotaku.

Reacties (130)

Ook gewijzigd, dit ging als volgt:
Playstation.com, inloggen --> Profiel bewerken
Onder Playstion network --> Privacyinstellingen van PSN
Persoonlijk informatie | Berichtenfunctie -> Berichten --> Alleen vrienden/Niemand

Ook bij vriendverzoek / friendrequest is het mogelijk een bericht mee te sturen. Dus die moet je ook blokkeren.

"Alleen Vrienden" werkt totdat een "vriend" een geintje uit wil halen.

Dan pak je de auto en wissel je bij hem de Playstation om.

Tenzij je wereldwijd vrienden hebt:-)

Ah oke ja die mensen heb je natuurlijk ook. Ik heb dan weer geen onbekende in mijn (xbox) vriendenlijst.

wie heeft het over onbekenden?

Of je loopt of vliegt

En het nut is? ga je op die PS4 naar je PSN, open je per ongeluk het bericht en dan heb je hetzelfde gezeik.

Mission completed, ps4 weer terugbrengen

of je zorgt dat het bericht eerst verwijderd is?

Met zulke vrienden heb je geen vijanden nodig...

God beware me voor mijn vrienden, met mijn vijanden reken ik zelf wel af.

Dit hebben we op meerdere devices inmiddels gezien. Toch apart dat er sowieso tekens geschreven kunnen worden die niet in ASCII / UNICODE staan. Sta zo'n teken dan überhaupt niet toe, of negeer het.

Het is waarschijnlijk niet een enkel teken, maar een combinatie. Unicode bevat ook modifiers voor tekens.
Bijvoorbeeld e (U+0065) gevolgd door ́ (U+0301) wordt é.
Voor de westerse scripts zijn er voor vrijwel alle tekens met accenten ook aparte code-points aangemaakt, waarmee er dus verschillende mogelijkheden zijn om een é te coderen, als accent gevolgd door teken, en als een enken teken. Voor de complexere scripts worden soms wel meerdere modifiers toegepast om een teken te maken.

Wat gebeurt er als je een chinees teken gevolgd door een westers accent plaatst. (of in het algemeen, een modifier van een ander script) Beide tekens afzonderlijk zijn geldige unicode-tekens, maar de combinatie klopt niet. Het is dan is de meeste gevallen met unicode-problemen ook de render-engine die op zijn bek gaat.

Dit soort zaken gebeuren, als je alleen maar richt op leuke extra's en niet verder na denkt.

We hebben nu al ruim 10 jaar UTF8 in gebruik, waarom komen dit soort bugs dan nog steeds voor?

Waarschijnlijk omdat Unicode steeds wordt uitgebreid. Er zijn nieuwe scripts toegevoegd, met hun eigen modifiers, en ook zaken die er misschien weinig te zoeken hebben, zoals emoji's met modifiers voor kleur.
Hierbij komen ook complexe scripts, waarbij hoe een teken gerenderd wordt af hangt van het teken dat ervoor of erna staat. (Denk hierbij aan letters die aan elkaar geschreven worden)
Bovendien zijn er ook nieuwe render-engines geschreven met nieuwe bugs.
Zie ook https://modelviewculture....-but-i-cant-write-my-name

Weer wat geleerd, wist niet dat dat de letters zich aanpassen, aan de reeks waarin ze gebruikt worden.
Maar als het probleem is, de verschillende mogelijkheden, combinaties en uitbreidingen.

Is dan het fundament waar op ze bouwen niet verkeerd?
Ik zie dit soort ellende al sinds de DNS servers en Browsers IDN gebruiken.

De basis van Unicode is erg solide, en UTF-8 is zo mogelijk de meest briljante hack ook ontworpen.

Het probleem is dat menselijk schrift en iconografie erg complex is, wat Unicode ook complex maakt.
Je kan debatteren over of bepaalde toevoegingen het waar waren, maar nergens zijn echt hele rare beslissingen gemaakt.

Kijk bijvoorbeeld hoe Emoticons en huidskleur in Unicode zijn gekomen:

1. Wingdings, pictogrammen als ☢ en Japanse emoji-fonts (en Hieroglieven etc) bestaan al voordat Unicode bestaat
2. Doel van Unicode: encode elk (digitaal) menselijk schrift volgens één standaard
3. Bestaande emoji's en alle dingen uit 1 krijgen een code-point en worden opgenomen in Unicode, want anders lukt 2 niet. Er zitten nu pictogrammen en Emoji's in Unicode
4. Mensen willen extra emoji's. Het verweer "we doen alleen wat een Japanner in 1992 ooit arbitrair in een font heeft gestopt in Unicode" is erg slecht. Uitgebreide library van emoji's zit nu in Unicode
5. Mensen willen meer emoji's, en mensen klagen over dat hun huidskleur niet gerepresenteerd is. Men leent een trucje van de encoding van didactische karakters, en maakt een "huidskleur" modifier. Huidskleur modifiers zitten in Unicode, en Unicode is weer lastiger

Als je ergens aan bovenstaande stappen een duidelijke misttap ziet met betere oplossing kan je per direct aan de slag bij het Unicode consortium...

Het enige correcte aan jouw rant is dat er Japanse emojis toegevoegd geweest zijn aan unicode en dat de collectie uitgebreid geweest is, met als redenering dat dit veelgebruikt is voor communicatie.

Er bestaan geen "huidskleur modifiers" in unicode. Je hebt wel control characters die het eerder getype character kan modifyen, maar deze control characters zijn echt niet uitgevonden om emojis bruin te maken. Ze bestaan voor de tientallen speciale schriften die niet kunnen weergegeven worden door ze eenvoudigweg op te lijsten in een codetabel.

Control characters bestonden reeds vanaf dag 1. Op een dag besloot men dat het ook gebruikt kon worden om emojis te modifyen ipv enkel tekst. 100% optionele modifiers trouwens. Het mooie aan dit systeem: Als je besturingssysteem geen bruine smiley ondersteunt, toont hij gewoon de gele, zonder dat hij zelfs moet weten dat de bruine bestaat.

[Reactie gewijzigd door boe2 op 15 oktober 2018 09:55]

Die Japanner was Shigetaka Kurita van NTT.
Hij is de teamlead van het team dat de emoji ooit heeft ontwikkeld voor Documo

Het probleem is niet de UTF-8 encoding, maar wat je met de gedecodeerde Unicode-codepoints aanmoet. Unicode is behoorlijk complex en het renderen ervan is nog vele malen complexer. Dit is echt zoiets dat op het eerste gezicht niet zo lastig lijkt maar hoe meer je je er in verdiept hoe complexer het wordt.

De Youtuber Tom Scott heeft hier een aantal goede en begrijpbare video's van gemaakt: https://www.youtube.com/results?search_query=tom+scott+utf8

Bijvoorbeeld degene over de Android crash bij bepaalde berichten: https://www.youtube.com/watch?v=jC4NNUYIIdM

omdat er steeds meer bij komt, en voor elke bugfix wordt wel weer een nieuwe bug gevonden.

Kans is vrij groot dat dit gewoon Unicode is. Dat is vaak het probleem.

Aan de andere kant snap ik niet dat je van een berichtje als dit een bootloop kan krijgen. Dat er een stuk van de software crashed okee, maar dat het hele apparaat niet meer bruikbaar is...

Heb het meermaals gehad op mn iphone. Rete irritant maar was altijd wel een weg omheen te vinden op het apparaat zelf.

Aan de andere kant snap ik niet dat je van een berichtje als dit een bootloop kan krijgen.

Dat is simpel: de software krijgt een bericht en probeert het vreemde teken weer te geven maar door de bug crasht alles. Dan reboot je de PS4 maar bij het opstarten wil hij waarschijnlijk het bericht wat je hebt ontvangen opnieuw weergeven, en crasht hij meteen weer. En elke keer als je reboot gebeurt hetzelfde...

Nog simpeler is fatsoenlijke exception-handling toepassen bij het parsen van de data. Als je dan een exception krijgt, geef je een standaard teken weer. Scheelt crashen van een heel apparaat/OS.

Dit wordt Input Validatie genoemd en zou toch niet vreemd mogen zijn voor een bedrijf als Sony.

[Reactie gewijzigd door Anoniem: 470811 op 14 oktober 2018 18:39]

maar wie zegt dat je bij de input al een exception krijgt? het gaat hier om valide unicode characters, die pas bij het renderen problemen opleveren.
ik denk dat input validation ook lastig toe te passen is, met al die verschillende combinaties. zo simpel is dit niet.
bij ios komt het ook nog wel eens voor, en dan wordt het gefixed, maar later is er weer een vergelijkbare bug. het zal ongetwijfeld ook bij android voorkomen, maar door het grote aantal verschillende android roms zal dit niet zo snel wijdverspreid voorkomen.

Ja en nee. Input Validatie doe je bij het ontvangen van de input. Dan ga je kritisch kijken welke tekens je accepteert (en hier zijn prima libraries voor te vinden). En dan heb je ook nog het parsen/renderen deel, en er is altijd exception handling mogelijk. Naast specifieke exceptions, kun je ook een generieke hebben die het afvangt. Levert het renderen een exception? Laat dan een X zien (zoiets).

Dus aan de voorkant zorg je ervoor dat je geen input ontvangt dat je in de eerste helemaal niet kan verwerken. En bij het renderen zorg je ervoor dat specifieke combinaties van tekens niet lijdt tot een volledige crash.

En dit valt prima te unit-testen. Dit is geen nieuw vraagstuk en hier zijn al veel meer zaken voor gedaan. De kern-problematiek zit in dat hele Agile-gebeuren waarbij vaak (en overigens zeer onterecht) gedacht wordt: dat fixen we later wel (wat dan niet gebeurt).

dan zou je op al die mogelijke combinaties moeten gaan checken voordat je er iets mee gaat doen. dat kost alleen maar tijd. als dit zo simpel op te lossen was dan kwamen deze bugs allang niet meer voor

Dat kan je afvangen.

en dat zal sony wel met een firmware update oplossen, maar proactief is dat dus al moeilijk te doen, anders was de bug al opgelost geweest

Blijkbaar is het wél een valide unicode character (als het ASCII was zou het wel worden weergegeven aangezien die beduidend minder characters heeft dan UTF-8), maar misschien zit er geen ondersteuning voor dat character in het lettertype dat gebruikt wordt, dan zie je vaak van die vakjes met de hexadecimaal of een vraagteken.

de afzonderlijke characters zullen wel valide zijn, maar de combinatie niet. die vakjes krijg je alleen bij valide combinaties, die niet ondersteund worden door je huidige taalinstellingen. bij zo'n invalide combinatie zal het anders afgevangen moeten worden denk ik

Blijft apart dat zo'n vooraanstaand platform zulke 'makkelijke' bugs bevat. Van een berichtje naar een bootloop, damn.

Helemaal niet. Het is ergens de schuld van welke tekens we vandaag allemaal mogen sturen. In de tijd dat berichten beperkt werden tot gewoon tekst was het nog eenvoudig. Vandaag hebben we opmaak, emojies, animaties,... en moeten we het ook nog eens vanuit ontelbare platformen kunnen sturen.

Wat een onzin. In plaintext kon je ook gewoon SQL injection doen.

Dit heeft dan ook niets te maken met SQL injection of plaintext. Wat @Blokker_1999 waarschijnlijk bedoelde was dat men vroeger enkel met ASCII tekst werkte,waar alle tekens een simpele betekenis hebben (met uitzondering van enkele control characters, die makkelijk te filteren zijn).

Nu met Unicode zijn er miljoenen meer dan honderdduizend verschillende tekens, waarvan sommigen met speciale effecten. Zo zijn er emoji's, karacters die de leesrichting veranderen, karacters die het volgende teken een accent geven, vele karakters zonder lengte of zelfs met negatieve lengte (zie deze youtube video van Tom Scott over de Effective Power bug). Unicode is gewoon zo een clusterfuck dat het ongelooflijk moeilijk is om alles juist te behandelen in code.

EDIT: geen miljoenen maar ~137 000 verschillende tekens.

[Reactie gewijzigd door JustHoLLy op 14 oktober 2018 16:55]

Nu met Unicode zijn er miljoenen verschillende tekens,

Beetje overdreven, er zijn welgeteld 1,114,112 mogelijke tekens in Unicode, en daarvan zijn er meer dan 700,000 die (nog) nergens voor dienen. Dat dikke miljoen is dan nog netjes onderverdeeld in "planes", dus filteren zou echt niet zo moeilijk moeten zijn.

De exacte hoeveelheid maakt niet echt uit, het zijn er een pak meer dan de 128 die ASCII heeft en een karakter kan invloed hebben op de andere karakters. Je kan ook niet gewoon het hele Arabisch plane blokkeren, want de PS4 ook gebruikt wordt in landen waar deze taal gebruikt wordt en dan zal je deze gebruikers uitsluiten.

In ASCII had je ook karakters die invloed konden hebben op andere karakters, en dat was ook niet altijd simpelweg een kwestie van 'alles onder 32 uitfilteren' hoewel dat wel een redelijk 'fool proof' oplossing was.

Welke zouden dit dan zijn? Volgens asciitable.com zijn enkel tekens 0-31 en teken 127 speciale characters, al de rest heeft niets van special behandeling nodig. Ter herinnering: alles boven 127 zijn niet gezien als standaard.

Je kan sowieso 0x0D en 0x0A niet zomaar weglaten. CR LF is niet onbelangrijk.

Het blijft een lastig iets, je kan als dev voor een chat toepassing, moeilijk karakters gaan filteren, want weet jij veel hoe iemand in het Tibetaans zijn naam schrijft. Dus degene die de input handler schrijft zal zoveel mogelijk tekens willen toestaan en alleen een klein deel van de control chars niet toestaan.

Degene die de render engine moet maken heeft vervolgens de schone taak om ervoor te zorgen dat die unicode goed parsed en gerenderd wordt. En de QA tester die moet kijken of de boel hufter-proof is. En daar is je valkuil. Wat als je QA tester niet weet dat er rare dingen in andere schriften zitten, omdat je per toeval geen vage interesse hebt in linguistiek? Ik weet dat van Tibetaans ook alleen maar omdat NativLang een keer in mijn YouTube suggesties stond.

Sterker nog je hoeft niet eens zo ver weg te zoeken als Tibet. Mijn naam heeft 5 letters, toch typ ik er 6, probeer maar eens een lange ij te typen. Ik denk dat zelfs de meeste NL testers daar niet eens bij nadenken. Iedereen typt toch wel i j.

En het is inderdaad juist vaak de renderengine die eruit klapt.
Meestal zit beeldrendering en fontrendering redelijk diep in de core van een besturingssysteem en heeft een crash daarvan helaas ook grote consequenties voor het systeem.

Het alleen filteren van een enkel codepoint is vaak niet genoeg. Ook alle interacties van meerdere codepoints kunnen een probleem opleveren. Modifiers op modifiers zijn gewoon legaal, maar dat is iets wat bijna geen enkel OS goed ondersteunt. Unicode is meer dan alleen een tabelltje met karakters. De basis standaard van 5.0 was ongeveer 1200 pagina's. Succes met verwerken ervan in een OS, laat staan een simpele teksteditor. Want wat doe je? vertrouw je het OS op de correcte rendering van je tekst of bouw je je eigen 'renderer'... en zo worden er weer meer bugs geintroduceerd.
Het veiligste is dus je te beperken tot 1 plane en alleen bekende modifier/karakter paren toe te staan.
Alleen ben je dan al niet meer "Unicode compliant"

Dat zeg ik toch? Alles onder 32 uitfilteren is een oplossing als je die tekens niet nodig hebt voor het een of ander. Verder was 255 min of meer standaard en kon voor problemen zorgen.

Niet voor niets dat ook de grote software jongens zoals een Apple, Google of MS hier ook wel eens problemen mee hebben.
iPhones die onderuit klappen, Powershell die vastloopt. Android dat onderuit klapt.

Sony is geen software reus maar een hardware bouwer.

Dat zegt vandaag de dag al lang niets meer. Amazon was een boekenverkoper en zit vandaag net zo goed in de software en zijn ook nog eens de grootste cloud aanbieder in de wereld. Sony is wat betreft Software/game development net zo'n een reus. Als Microsoft de mensen niet in huis heeft voor een bepaalde software die ze willen maken of een cloud dienst, dan is Microsoft ook niks.

Sony is geen software reus maar een hardware bouwer.
Daar ben ik het niet helemaal mee eens. Ze maken veel hardware inderdaad, waaronder TV's, camera's en spel computers, maar de meeste inkomsten en resources voor de spelcomputer divisie gaat naar hun software.
Die TV's en camera's hebben ook gewoon software nodig natuurlijk, maar dat is van een andere divisie van de playstation waarvoor ze veel in house spellen maken, het operatingsysteem zelf hebben gemaakt (waarschijnlijk gebouwd op BSD), daarvoor een eigen graphics API, hun PSN en tools om daar software voor te schrijven etc.
En als je dan kijkt hoe belabberd hun hardware in elkaar zit moet je je ook afvragen of ze wel weten wat ze doen. (voorbeeld: de SoC heeft HDMI en DP uit, Sony heeft ervoor gekozen om niet direct de HDMI naar de achterkant te sturen, maar de DP te pakken, daar een actieve HDMI converter tussen te zetten en die naar de achterkant te sturen. Hun harde schijf zit op het moederbord via een USB controller naar SATA adapter ipv de aanwezige SATA controller etc.)
Het gros van hun inkomsten met de spelcomputers komt dan ook van royalties en PSN subscriptions, en maar een deel van de spelcomputers zelf.

Er zit nog steeds een groot verschil tussen een partij als Microsoft, die volledig om software development heen draait. En een Sony, welke primair hardware verkoopt. Apple valt er een beetje in het midden en Google is ook eigenlijk puur software.

Allemaal doen beide, MS en Google doen ook hardware, en Apple en Sony doen ook software. Maar het is maar net waar je focus ligt. Sony en Apple leveren geen software (of zo goed als geen) voor hardware die niet van hun is.

Van dit soort partijen mag je nog een beetje verwachten dat 'simpele' fouten er door heen schieten. Maar als zelfs de grootmeester van de software dit soort fouten maakt, kun je daar de hardwareboeren niet op afrekenen IMO.

MS en Google zijn kleine jongens op hardwaregebied, kleiner op hardware dan Sony is op software. Sony zit een beetje tussen een pure hardwareboer met alleen wat embedded producten, en Apple in. Het is niet alleen een televisiefabrikant die per ongeluk met Android te maken krijgt omdat dat nou eenmaal op een televisie moet staan, maar een echte computerfabrikant met een eigen architectuur en een eigen afdeling voor de ontwikkeling daarvan. Met net iets meer nadruk op hardware dan software, maar software wel op een professioneel niveau met afdelingen die dat al jaren doen en zo nu en dan overnames van kleinere partijen.

[Reactie gewijzigd door mae-t.net op 15 oktober 2018 17:54]

Wat iets totaal anders is dan random tekens sturen in een poging om bugs te vinden die het systeem doen crashen. SQL injectie is dan ook iets dat nog relatief eenvoudig is af te vangen. Maar als je soms de tekststrings bekijkt of de handellingen die mensen doen om bugs te vinden die een systeem doen crashen of je voorbij een lock krijgen dan spreken we niet langer van het niet escapen van een karakter.

Het is complexer, maar het principe van zorgvuldig omgaan met invoer en verwerking van user input blijft wel staan.

maar hoe wil je dat dan doen? er zijn 1.114.112 mogelijke combinaties (utf-16), waarvan er 137,439 gebruikt worden bij versie 11.0. dit soort problemen komt door combinaties die geen valide character opleveren. dit kan erg veel verschillende resultaten opleveren. je kunt onmogelijk alles af gaan vangen.

het is niet alleen complexer, maar ook compleet anders. sql injectie is heel simpel op te vangen door gewoon alle variabelen als string te behandelen (prepared statements).

dat heeft er totaal niks mee te maken. plain text zal geen problemen opleveren bij het renderen, wat je ook invoert.
dit probleem komt doordat er meerdere characters gecombineerd worden die niet gecombineerd kunnen worden, waar de software niet mee om kan gaan.

Mja, het blijft toch maar een zooi pixels, toch.
Voor een systeem lijkt mij er niet veel onderscheid te zijn tussen het weergeven van een Z of een complexer teken uit een Sanskrit-taal, of een emoji, of zo.

Ik snap het in ieder geval niet helemaal.

Unicode rendering is een zeer complex beestje, bijna een programmeertaal op zichzelf. Het heeft als doel om alle talen in de wereld te kunnen weergeven, dus ook degenen die van rechts naar links schrijven, van boven naar onder en compleet andere schrijfstijlen waar alles aan elkaar hangt ipv aparte tekens. Om dit te bereiken zijn er een hoop onzichtbare control characters die het gedrag van je font on the fly kunnen wijzigen, middenin je tekst.
Die tekst correct renderen is al een uitdaging, maar dat maakt het ook een grote uitdaging om de tekst te "meten": weten hoe breed/hoog de tekst is, zorgen dat hij correct in zijn container staat, met linebreaks op de juiste plaatsen. Als je intuitieve linebreaks KAN doen tenminste.

Het zijn die onzichtbare control characters die voor kwetsbaarheden zorgen. Niemand kan blijkbaar garanderen dat alle edge-cases correct opgevangen zijn aangezien je hier schier oneindig veel combinaties hebt en sommige bugs bedoelt zijn om de renderer in een oneindige loop te brengen.

De mensen die hier roepen "test gewoon op alle tekens" beseffen dan ook niet dat het probleem helemaal niet met enkele tekens te maken heeft. Natuurlijk is er getest op alle individuele tekens, hier zijn geautomatiseerde tests voor. Het probleem stelt zich met de modifiers die erop zitten.

[Reactie gewijzigd door boe2 op 15 oktober 2018 09:44]

Klasse reactie.

Nee, het zijn geen zooi pixels. Echter, het zijn een zooi Unicode code points: https://en.m.wikipedia.org/wiki/Code_point

Ok, dus het gaat bij deze exotische symbolen al voor de weergave-fase fout? In de CPU?

CPU heeft hier niks mee te maken. Het OS slaat er van op hol. Het is juist bij de weergave, aangezien t pas gebeurt als je t bericht gaat bekijken.

[Reactie gewijzigd door chimnino op 14 oktober 2018 21:07]

Dit is in dit geval niet helemaal waar, er zijn ook meldingen geweest waar bij spelers de notificatie krijgen en al vast lopen, je hoeft de berichten dus niet direct te openen i nde birechten app om de vastloper te krijgen.

De notifications is ook al een probleem punt in dit geval, want die geeft een deel van het bericht weer en als daar dus precies een teken in zit waarvan je os klapt ben je al de sigaar.

alles wat je op je scherm ziet is weergave. ook meldingen.
op het moment dat zo'n teken gerenderd wordt loopt de boel vast, dan maakt het niet uit of je een bericht opent of gewoon de melding ziet. dit gebeurt ook alleen als het teken ook in het stukje tekst zit wat in de melding staat. het kan ook zijn dat je in een melding maar 1 regel ziet, en het teken staat op regel 2, maar dit wordt wel gerenderd, zodat je de melding kunt "uitklappen"

[Reactie gewijzigd door mjz2cool op 15 oktober 2018 15:53]

Een cpu verwerkt bits, lettertekens zijn bits (gegroepeerd in bytes) die door de cpu worden verwerkt. Wat je op het scherm ziet zijn pixels.
Een programma verwerkt bits/bytes. Een crash is dus gelieerd aan bits/bytes, niet aan de pixels...

Helemaal niet. Het is ergens de schuld van welke tekens we vandaag allemaal mogen sturen. In de tijd dat berichten beperkt werden tot gewoon tekst was het nog eenvoudig. Vandaag hebben we opmaak, emojies, animaties,... en moeten we het ook nog eens vanuit ontelbare platformen kunnen sturen.

Ik denk dat je niet weet hoe dat werkt? Het probleem is in het nu gebruikte unicode zelfs kleiner dan vroeger met ASCII codepages. Elke codepage had andere tekens, dus dat moest je dan maar net goed in kunnen stellen op je apparaat. Unicode is gestandaardiseerd, dus je krijgt in principe op elk apparaat hetzelfde teken. Een apparaat kan ervoor kiezen om niet alle tekens weer te geven, dan krijg je een vierkantje of een andere foutmelding ter grootte van een teken. Kennelijk is er in de PS4 op dat punt iets misgegaan. Natuurlijk zitten er in Unicode vreemde dingen, zoals je vroeger ook lage ASCII-tekens had die je er even uit moest filteren of moest vervangen door iets dat de computer goed weer kon geven, maar dat is een kwestie van goed opletten. Zelfs als er iets onverwachts inzit (rare lengte of onverwacht teken) zou je foutafhandeling niet tot een bootloop moeten leiden.

En in geval van twijfel geldt de vuistregel die bij andere 'tricky' dingen zoals rekenen met datum en tijd ook geldt: gebruik een goede library (en test op edge cases die inmiddels toch wel ruimschoots bekend zijn).

[Reactie gewijzigd door mae-t.net op 14 oktober 2018 16:44]

In de tijd dat berichten beperkt werden tot gewoon tekst

Daar zijn ze toch zelf bij? Als je een encoding voor je chat accepteert zorg je dat je daar een fatsoenlijke standaard voor hebt (gewoon unicode lijkt me een goed begin, heb je ook meteen emojies in 'gewoon tekst'). En gegeven een fatsoenlijke standaard voor een encoding is het niet echt lastig om een parser te maken, de kunst van parsing is toch wel uitgekristalliseerd. Er zijn genoeg tools/libraries om gewoon een parser te genereren die niet crasht.

Voetnoot: dit gaat er wel vanuit dat het in de parsing zit, en niet in de weergave.

[Reactie gewijzigd door bwerg op 14 oktober 2018 12:02]

tja, probeer tegen dat soort dingen maar eens tests op te stellen

Berichten in een sandbox verwerken en je hebt (als het goed is) maar 1 test nodig...

en dan wordt het teken gerenderd in de sandbox en crashed je systeem alsnog

Als ze werken met unittests zal iemand wel moeten.

Ik ben geen programmeur maar het moet toch een koud kunstje zijn om volledig geautomatiseerd alle mogelijke karakters te testen.

En om het vervolgens te filteren .match('/[0-9a-zA-Z\.,]'/) evt aangevuld met wat je nog meer wilt toestaan. Of op een slimmere manier

[Reactie gewijzigd door floorcula op 14 oktober 2018 10:54]

Misschien crashed je regexp functie/library wel op dit onbekende teken.
Dus daar ga je met je regexp.

Ofwel de library specificeert gewoon dat je er bepaalde dingen niet in mag stoppen en dan moet je dat zelf controleren, ofwel het is een heel erg matige library die je überhaupt niet had moeten gebruiken. Hoe dan ook is een parser nou niet bepaald high-tech.

Ja, we weten allemaal dat je je library bugloos moet maken en er niets in moet stoppen dat hij niet aan kan. En we weten ook dat er in simpele code bugs kunnen zitten die de meest desastreuze gevolgen kunnen hebben.

En we weten ook dat er in simpele code bugs kunnen zitten

Dat is een beetje een dooddoener. Regexen herkennen (waar je het specifiek over had) is een relatief oud en simpel probleem in de informatica met ook relatief weinig haken en ogen. Correcte weergave van unicode is bijvoorbeeld al een stuk complexer, en daar zijn een stuk meer valkuilen te verwachten.

Maar uiteraard, zonder de details te kennen zijn uitspraken over de domheid van het probleem natuurlijk niet echt zinvol.

[Reactie gewijzigd door bwerg op 14 oktober 2018 12:17]

Maar uiteraard, zonder de details te kennen zijn uitspraken over de domheid van het probleem natuurlijk niet echt zinvol.

Dat is een beetje een dooddoener... je roept zelf dat het allemaal zo simpel is met de juiste library, en dat het afgevangen kan worden met simpele regexen, dat het allemaal niet hightech is...
zonder kennis van de details.

[Reactie gewijzigd door Zer0 op 14 oktober 2018 22:31]

Wat de boer niet kent, dat lust hij niet. Dus: exception afvangen en het karakter waarop gecrasht wordt, en desnoods het hele bericht waarin dat karakter staat, verwijderen. Berichten die niet aankomen omdat er een of ander obscuur teken in zit is nog altijd beter dan je apparaat in een bootloop zien hangen.

Maar wat @dakka zegt is wel correct: hoe knullig het probleem (van vreemd teken naar bootloop) ook is, hierop test je doorgaans niet.

Wat de boer niet kent, dat lust hij niet. Dus: exception afvangen en het karakter waarop gecrasht wordt, en desnoods het hele bericht waarin dat karakter staat, verwijderen.

Zo simpel is het niet, de systeemsoftware van de PS4 zal waarschijnlijk in C of C++ geschreven zijn en gezien wat het gevolg is zal dit niet een geval van een niet afgevangen exception zijn. Een buffer overflow of andere vorm van memory corruption is waarschijnlijker. In C/C++ kan je een heleboel hele foute dingen doen die op geen enkele manier een exception gooien (C kent niet eens exceptions) en het is niet eens noodzakelijk dat de crash plaatsvind op de plek waar de bug zit.

Memory corruption is in C ook absoluut niet nodig, al zijn er nog wel steeds leerboeken en sites in omloop waar je niet leert hoe het moet.

Het probleem is dat mensen fouten maken. Beter is zorgen dat de fout helemaal niet gemaakt kan worden.

Als dat zo is dan is dit niet alleen een bug die de console kan doen crashen, maar ook nog eens een gapend beveiligingsgat.

Het feit dat de machine in een bootloop terecht komt betekent al dat er ergens geschreven werd in geheugen waar uitvoerbare code hoorde te staan, of er een jump gedaan werd naar een uitvoerbaar gedeelte.

Beide situaties wil je uit beveiligingsoogpunt niet, want dat zou de gebruiker toelaten om eigen code uit te voeren op het systeem.

Als dat zo is dan is dit niet alleen een bug die de console kan doen crashen, maar ook nog eens een gapend beveiligingsgat

Klopt, maar het ligt er aan met wat voor rechten de UI draait. Het kan best zijn dat de UI gewoon als beperkte user draait maar dat de console zichzelf reboot als de UI crashed.

[...]

Klopt, maar het ligt er aan met wat voor rechten de UI draait. Het kan best zijn dat de UI gewoon als beperkte user draait maar dat de console zichzelf reboot als de UI crashed.

Dat verklaart alleen niet waarom de console dan in een bootloop eindigt, tenzij er óf een brakke controle plaatsvindt op de integriteit van de UI-bestanden tijdens het booten (en er geen read-only backup is waaruit hersteld kan worden), óf de UI zo slecht geprogrammeerd is dat ie altijd ongevraagd de privé-berichten laat zien waardoor het probleem zich dus blijft herhalen.

De vraag is ook of dat bericht op de disk van de PS4 wordt opgeslagen of alleen in de cloud, in dat geval zou het loskoppelen van de PS4 van het netwerk het probleem (tijdelijk) oplossen.

Waar jij nu rekening mee houdt zijn alleen westerse characters. What about japanese? Korean? Mongolien? Smileys? Onkruid houd je niet tegen

Trust me, er zijn buiten een library om om die karakters af te kunnen handelen nog 80 dingen er omheen, het is vaak een component van partij a, groep b, hacker c die in dit soort dingen gaan

Dus wat je zegt is dat ik iig het probleem heb opgelost voor iedereen die zijn Playstation op een westerse taal heeft staan. Niet slecht voor 20 seconden werk

PS, waarom zo onaardig?

Niet onaardig, gewoon een Nederlands woord. De kern van mijn comment is duidelijk, je kunt niet een makkelijke fix bouwen voor dit soort dingen. Er komen altijd edge cases die gewoon niet met dit soort makkelijke regex' op te lossen zijn. Is ook totaal niet performant. Ik hou er gewoon niet van als amateurs professionele programmeurs onderuit halen door te zeggen dat het een "koud kunstje" is om zoiets op te lossen. Heb toch een beetje respect voor die professionals, en denk niet dat je het beter weet.

Je bedoelt de professionals die deze fout hebben gemaakt. Die er niet aan dachten de input goed te valideren.

Ik snap dat een regex te simpel is (lees mijn opmerking maar) maar het idee van ongefilterde input moet toch ook voor een 'professional' vloeken in de kerk zijn.

Bovendien merk ik dat ik in de meeste chat applicaties geen rare tekens mag versturen. Dus het idee is zo gek nog niet. Ik zeg dus bullshit en laat me zeker de mond niet snoeren door jou als 'professional'

Daarbuiten zeg ik dat het creëren van alle mogelijke tekens een koud kunstje zou moeten zijn. Niet het oplossen dus maar het testen.

[Reactie gewijzigd door floorcula op 14 oktober 2018 12:30]

Ik heb je originele post gemist, maar refereer je aan white-listen van een beperkte set tekens? Klinkt als een simpele oplossing voor een complex probleem.

nee, want dan stuurt je chinese vriend een vreemd teken, die vervolgens bij die regexp geheugenproblemen oplevert waardoor je systeem crashed.

De mensen die hier roepen "test gewoon op alle tekens" beseffen dan ook niet dat het probleem helemaal niet met enkele tekens te maken heeft. Natuurlijk is er getest op alle individuele tekens, hier zijn geautomatiseerde tests voor. Het probleem stelt zich met de modifiers die erop zitten.

Sorry, maar dit is 100% onzin. Unicode control characters zijn echt niet uitgevonden om emojis bruin te maken. Ze bestaan voor de tientallen speciale schriften die niet kunnen weergegeven worden door ze eenvoudigweg op te lijsten in een codetabel.

Control characters bestonden reeds vanaf dag 1. Op een dag besloot men dat het ook gebruikt kon worden om emojis te modifyen ipv enkel tekst. 100% optionele modifiers trouwens. Het mooie aan dit systeem: Als je besturingssysteem geen bruine smiley ondersteunt, toont hij gewoon de gele, zonder dat hij zelfs moet weten dat de bruine bestaat.

[Reactie gewijzigd door boe2 op 15 oktober 2018 09:49]

Die emoticons zelf zijn het probleem niet echt, de 'gevaarlijke' tekens zijn besturingstekens zoals die voor rechts-links en tekens met 0 of negatieve lengte die er ongeacht gebruik bij emoticons al gewoon inzaten.

UTF-8 is nooit vrij simpel geweest. Het moet voor de programmeurs altijd duidelijk zijn geweest dat je dat niet met shortcuts kan parsen.

Leuk dat je Chinees erbij haalt, welke het Hanzi alfabet gebruikt... Elke taal heeft een alfabet (anders is het ongeordende zooi). Ik begrijp je punt verder en ben het met je eens.

Het Hanzi is een schrift - een grafisch systeem om een taal weer te geven -, geen alfabet in de strikte zin van het woord. Hoewel al die definities inderdaad voor discussie vatbaar zijn, is het maken van een onderscheid tussen schrift, alfabet, abugida enz. toch zinvol; het Hanzi definiëren als alfabet kan onnodig verwarring scheppen.

die modifiers zijn er om ëéêè etc. te encoden. al lang voordat emoji's werden geïmplementeerd.

Ondersteuning voor unicode wordt dan vaak wel toegevoegd, maar er is geen team bestaande o.a. uit Chinees, Mongool, Thaise, Indiër en Inuit om alles grondig te testen.

Voor de -1'ers hier. Het Mongools kent ook een eigen karacterset. Niet iedereen die het woord "Mongool" schrijft is anderen aan het beledigen.

Zo stuur ik wel eens een Mongoolse Klinker Seperator, U+180E. Dit is om de een of andere mij niet bekende reden de enige 'whitespace' character die niet gezien word als whitespace, waardoor je leeg-ogende berichten kan sturen.

https://en.wikipedia.org/wiki/Whitespace_character

Voorbeeld: ]᠎[

(Wat overigens wel weer een heerlijk subtiele manier is om mensen stiekem te beledigen )

[Reactie gewijzigd door dj__jg op 14 oktober 2018 14:04]

Zo stuur ik wel eens een Mongoolse Klinker Seperator, U+180E. Dit is om de een of andere mij niet bekende reden de enige 'whitespace' character die niet gezien word als whitespace, waardoor je leeg-ogende berichten kan sturen.

Dat kon/kan ook met ALT-0160, de non-breaking space, die werd door software vaak ook niet als spatie herkend. In Unicode zelf zitten er trouwens nog wel een stuk of tien andere spaties (en-space, em-space, punctuation space, thin space etc...), je hoeft er echt niet het Mongools voor te gebruiken.

[...]


Dat kon/kan ook met ALT-0160, de non-breaking space, die werd door software vaak ook niet als spatie herkend. In Unicode zelf zitten er trouwens nog wel een stuk of tien andere spaties (en-space, em-space, punctuation space, thin space etc...), je hoeft er echt niet het Mongools voor te gebruiken.

Die specifieke mongoolse glyph wordt gebruikt omdat het er uit ziet als witruimte, maar in Unicode expliciet niet in de categorie witruimte opgenomen is, omdat het in de originele taal die rol niet vervult.

Er zijn een boel parsers voor o.a. forum-software die bijv. regels met enkel witruimte detecteren om zaken af te dwingen als een maximaal aantal witregels tussen paragrafen tekst. (Tweakers doet dat vziw ook.) Veel van zulke parsers kijken alleen naar de categorie van witruimte glyphs en niet daarbuiten. U+180E is dan een weg om die parsers heen.

Het Mongools wordt tegenwoordig gewoon met (een variant van) het Cyrillische alfabet geschreven. Er is wel een oud Mongools alfabet dat van boven naar beneden geschreven wordt, en vreemd genoeg alleen nog in een deel van China gebruikt wordt. In Mongolië zelf gebruikt men bijna uitsluitend het Cyrillisch.

Gelukkig kost dit geen berg geld.
Tesla ( ook zo'n vooraanstaand platform) gooit regelmatig firmware updates on air, waar je parkeer sensors opeens in de zonder waarschuwing in de slaapstand gezet kunnen worden, met als resultaat een flinke beschadiging aan je bumper.
Dan valt zo'n bootloopje wel mee, die je met een reset kan fixen.

Tja 100% vertrouwen op je sensors... Dan was je zelf ook al flink in slaapstand.

Ja, een bootloop in een PS4 zal niet van levensbelang zijn en geen schade toebrengen aan het apparaat zelf of aan de gebruiker of andere voorwerpen, maar als jij iedere keer dat je zo'n bericht ontvangt je PS4 mag gaan resetten en je games opnieuw downloaden/installeren/updaten dan wordt je toch ook niet echt blij hoor.

Je kunt alles wel vergelijken met willekeurig andere apparaten die ook softwarefouten bevatten, maar dat slaat eigelijk nergens op.

Sorry, maar dergelijke sensors zijn een hulpmiddel, geen vervanging voor de kijkkunsten van de chauffeur. Je zult dus altijd zelf moeten kijken en niet de sensors dat werk voor je moeten laten doen.

Whatsapp en iphone hebben ook zulke bugs gehad...waar je met bepaald bericht de telefoon liet bootloopen

Achja, vervelend, maar niet het enige vooraanstaand platform hoor, Apple had het bv ook..

Meteen naar even aangepast naar 'alleen vrienden'.
Ik heb ook wel eens spam berichten op PSN gehad, ik ga het risico niet nemen.

Het scheelt wel dat alle data tegenwoordig aan je PSN account hangt, je zult dus niet zo snel data verliezen maar alles opnieuw instellen gaat zeker wel wat tijd kosten.

“Alleen vrienden” zou sowieso de default moeten zijn. Wie wil er nou weer berichten ontvangen van accounts die je niet kent? Dat kan toch alleen maar troep zijn?

Genoeg games waar je iemand tegen komt en even met diegene kort wil chatten, voornamelijk op de console gezien je geen Discord of Voice chat standaard aan hebt staan in de meeste gevallen. In Destiny of GTA kom ik geregeld mensen tegen tijdens een missie of patrol die bijvoorbeeld iets samen willen doen, dan sturen ze mij een message of ik mee wil doen. Of nadat je een potje Fifa/Tekken hebt gewonnen van iemand en de "good game" bericht wil sturen.

Ik kan mij in iedergeval genoeg scenario's bedenken waar ik iemand die niet in mijn friends list zit een message wil sturen en andersom iemand mij iets wil laten weten als ik met ze in de game zit, zonder gelijk vrienden te hoeven zijn.

Ik heb het normaal open staan, maar vanwege deze bug helaas uit moeten zetten. Maakt het in bepaalde situaties wel lastiger (online games met vreemden).

Volgens mij heb jij het over iets heel anders hier. Jij hebt het over ingame berichten, terwijl het hier gaat over PSN berichten (buiten de game om). Ik denk niet dat je iemand PSN berichten gaat sturen om even “gg” te zeggen...

In-game berichten heb je niet in de meeste games op consoles. In online games als Division, COD, Destiny, FIFA, Tekken, Battlefield en denk 90% van alle online games heb je geen mogelijkheid om even in-game een bericht te sturen. Daar gebruik je PSN berichten voor. Je highlight de speler in de game en drukt op profiel, waarna zn PSN profiel opent en je een bericht opstelt en verstuurt, via PSN messages dus.

Mijn berichtenlijst is het bewijs dat je na een potje FIFA/Tekken wel een “gg” message stuurt en ontvangt. En voor andere games probeer je daar contact te leggen met randoms die je tegen komt, vanwege het ontbreken van een in-game message client. Er zijn een select aantal games die dat wel hebben, zoals FFXIV (MMORPG). Die zijn echter zeer schaars.

[Reactie gewijzigd door ASNNetworks op 14 oktober 2018 17:22]

Jawel, want in 9/10 console games is het niet eens mogelijk om in-game berichten te sturen. Dit gaat over het algemeen via PSN.

Hier een filmpje van Tom Scott, destijds over iets vergelijkbaars op Android.

En ook iOS heeft er last van gehad: nieuws: Speciaal Indiaas teken laat Messages en WhatsApp op iOS en macOS crashen.

Ben benieuwd of Windows en MacOS ook zoiets hebben gehad.

Beveiliging blijft een kwestie van verschillende lagen. Als er een bericht in een applicatie de render engine kan crashen, en als deze dan de driver en zelfs het OS mee weet te nemen dan weet je dat er iets serieus mis is in je design. Maar misschien is dit wel een dat een bug/vulnerability in de driver door de render engine wordt getriggered. Dat zou de escalatie van het probleem kunnen verklaren: drivers draaien bij Windows immers op hetzelfde niveau (ring) als de kernel.

Natuurlijk zijn game-platformen nogal prestatie gericht. Het meeste zal dan ook wel in C/C++ geschreven zijn. Dat zijn platformen die geen tot weinig memory protectie hebben. Het kan dan makkelijk zijn dat een lokaal probleem uitgroeit tot een groter probleem door memory-corruption. Statische analyse van de broncode is er tot nu toe niet in geslaagd om dit een probleem van het verleden te laten zijn.

Hoewel het renderen van Unicode inderdaad een lastig probleem is, zou het niet moeten kunnen dat fouten in het renderen het hele systeem op z'n knieen kan krijgen. Op z'n hoogst zou het bericht of liever dat ene character niet moeten renderen. Er zijn dus twee problemen om te fixen: de handling van foutieve Unicode / rendering en de escalatie van de bug.

[Reactie gewijzigd door uiltje op 14 oktober 2018 18:04]

Toch gebeurde dit ook op iOS & Android, en zelfs op Chrome op Windows.

[Reactie gewijzigd door MrFax op 15 oktober 2018 01:32]

Maar hoelang gaat het duren voordat ze dit fixen?

Ik heb alles dicht gemaakt op mijn PSN accounts.

Ook een manier om te winnen en cheaters uit een game te kicken. Ik zeg niet fixen maar gebruiken om campers te booten.

En je verwacht niet dat die cheaters/campers dit zelf dan gaan gebruiken?

Hier geen last van.

Ooit geprobeerd te google'n? https://status.playstation.com/nl-NL/