iMessage-csatolmányok karbantartása azok készülékedről való automatikus törlésével

Mint tudjuk, a videók rengeteg felesleges tárhelyet foglalhatnak a készülékeinken, főleg ha az ismerőseinkkel gyakran üzenünk egymásnak rövid klippek formájában.

image

Az iOS 8 megjelenése óta azonban rendkívül egyszerűen és gyorsan beállíthatjuk, hogy a beszélgetéseinkben küldött videók egy idő után automatikusan törlődjenek, ezáltal rengeteg hasznos tárhelyet felszabadítva.
Tovább olvasom

iSamurai iPhone szerviz akció

Pod2G: megkerülhető az iMessage titkosítása

A neves jailbreakfejlesztő és biztonsági szakértő, Cyril Cattiaux, közismert nicknevén @Pod2G, közzétett egy cikket, amiben elmondja, hogy az iMessage protokoll nem is annyira biztonságos, ahogyan azt az Apple állítja. Nevezetesen mind az Apple, mind egy, a készülékünkhöz fizikailag hozzáférő támadó olvasni és módosítani tudja az üzeneteinket.

IMG_5484

A Hack In The Box elnevezésű IT-biztonságtechnikai konferencián tartott előadás anyagában Pod2G elmondja: ő és csapata nem állítják, hogy az Apple elolvassa az iMessage-einket, csupán azt, hogy erre neki (és másoknak) lehetősége van. Szerintük a legvalószínűbb, hogy erre csak akkor kerülne sor, ha az Apple-t erre utasítanák (például az amerikai kormány vagy egyéb jogi szervezetek – az NSA-botrány óta mindenki erre gondol elsősorban).

Mit csinálsz, Apple? Avagy egy biztonsági intézkedés hiánya

Készült egy videó is, amiben a hackerek bemutatják, hogy nemcsak az Apple, de elvileg bárki, aki egyszer hozzáfért a készülékünkhöz, elolvashatja és megváltoztathatja az iMessage-ek tartalmát. A támadás – nagyon leegyszerűsítve – annyiból áll, hogy magukat az Apple szervereinek kiadó, „hamis” kulcsokat és aláírásokat telepítenek az iPhone-ra vagy iPadre. A sebezhetőség lényege, mondják a szakértők, az úgynevezett „certificate pinning” technológia hiánya. Ez azt jelenti, hogy a protokoll bármilyen olyan SSL-tanúsítványt érvényesnek fogad el, amit egy ismert (ebben az esetben hamisított és a készülék Keychain-jéhez adott) tanúsítványkiállító (Certificate Authority, CA) adott ki (és azokat a tanúsítványokat is érvényesnek tekinti, amelyeket ezzel a hitelesnek vélt tanúsítvánnyal írtak alá). A certificate pinning technika alkalmazása esetén csak konkrét tanúsítványokat fogad el a rendszer, tehát nem az aláíró személye és identitása számít, hanem csak az, hogy egy bizonyos tanúsítványról már eldöntöttük-e egyszer, hogy érvényes.

A hamisítást egyébként az Apple által kiadott iPhone Configuration Utility nevű alkalmazással végezték. Ennek a programnak a használatakor amikor egy készüléket első alkalommal csatlakoztatnak a számítógéphez, akkor az automatikusan rátölt egy új CA-t. Ennek az a további, „érdekes” következménye, hogy egy olyan cégnél, ahol külön IT-csoport felügyeli az iOS-készülékeket, az első használat előtt be tudnak állítani egy proxy-t, és ezzel le tudják hallgatni a készülék teljes internetes forgalmazását…

Az iMessage lehallgatása

Az Apple azt állítja, hogy az iMessage egy, az elejétől a végéig titkosított („end-to-end” titkosítással rendelkező) csatorna, ezért az üzeneteinket sem az Apple, sem egy jogosulatlan kívüálló nem tudja olvasni. Ez azonban nem igaz: a teljes titkosítás ellenére is lehetséges a fent leírt támadás.

Amikor a biztonsági szakértők kicsit mélyebbre ásták magukat a protokollba, néhány kellemetlen meglepetés érte őket. Az SSL-en keresztülmenő adatok tartalmazzák a küldő fél Apple ID-ját és a hozzá tartozó jelszót. Igaz, hogy az SSL protokoll ugye titkosítva van, de azon belül miért kell vajon plaintextben küldeni a jelszót? Az azonosításhoz elég lenne egy hash is. Íme, egy ehhez hasonló property list fájlt küld a Messages alkalmazás az Apple-nek (nyilván az adatok itt a példában nem valódiak):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>password</key>
    <string>Icandoaproperkeynote</string>
    <key>username</key>
    <string>tim_c@icloud.com</string>
</dict>
</plist>

A protokollok: a kliens, a Push és az ESS-szerverek

Az iMessage-üzenetek a Push protokollon keresztül jutnak el a feladótól a címzetthez. A protokoll TLS-alapú (tehát titkosított), az 5223-as porton át folyik, és az adatokat a [0…255]-courier.push.apple.com szerverek valamelyike továbbítja. A hitelesítéshez egy úgynevezett klienstanúsítványt („client certificate”-et) használnak. Ez a tanúsítvány nagyon érzékeny, mert minden Push-kommunikációt ezzel írnak alá. A klienstanúsítványt az Apple (az albert.apple.com című szerveren lévő „Apple iPhone Device CA” nevű certificate authority) állítja ki akkor, amikor a készüléket aktiválják.

A rendszer szerveroldali működését csak az Apple ismeri, viszont a kliensoldalon is sokmident figyelhetünk meg. Üzenetküldéskor a Messages alkalmazás az Apple ESS szerveréről kér le néhány adatot: egy úgynevezett „Push-Token”-t és két titkosítási kulcsot.

A Push-Token egy készülékpárhoz (feladó és címzett) tartozó egyedi azonosító, ami autentikációs és útválasztási (routing) információt is tartalmaz. Generálási algoritmusát ismét csak az Apple tudja, mint ahogyan a pontos felhasználás módját is. Egy érdekesség mindenesetre a kliensoldalról is látszik: a Push-Token egyetlen készülékpárhoz tartozik. Ha tehát a címzettnek több iMessage-képes készüléke van ugyanahhoz az Apple ID-hoz rendelve, akkor mindegyikre külön-külön elmegy az üzenet, így – gyakorlatilag – egy gombnyomással több üzenetet is küldünk. Az üzenetek a fent már ismertetett módon az Apple Push Notification Service (APNS) nevű szolgáltatáson keresztül mennek el. Íme az OS X-en futó iMessage alkalmazás hálózati forgalmazása:

root@joker:~>> ps aux |grep apsd
root 90 0.0 0.1 2467868 8052 ?? Ss Thu09AM 0:06.06 /System/Library/PrivateFrameworks/ApplePushService.framework/apsd
root 20295 0.0 0.0 2432768 588 s003 S+ 3:08PM 0:00.00 grep apsd

root@joker:~>> lsof -p 90 |grep TCP
apsd 90 root 9u IPv4 0x667b30bc14a94f93 0t0 TCP joker.lan:65158->17.172.232.179:5223 (ESTABLISHED)

root@joker:~>> whois 17.172.232.179
NetRange:       17.0.0.0 - 17.255.255.255
CIDR:           17.0.0.0/8
OriginAS:
NetName:        APPLE-WWNET
NetHandle:      NET-17-0-0-0-1
Parent:
NetType:        Direct Assignment
RegDate:        1990-04-16
Updated:        2012-04-02
Ref:            http://whois.arin.net/rest/net/NET-17-0-0-0-1
OrgName:        Apple Inc.
OrgId:          APPLEC-1-Z
Address:        20400 Stevens Creek Blvd., City Center Bldg 3
City:           Cupertino
StateProv:      CA
PostalCode:     95014
Country:        US
RegDate:        2009-12-14
Updated:        2011-03-08
Ref:            http://whois.arin.net/rest/org/APPLEC-1-Z
...

(Az első sorban látható apsd program a készüéken vagy a számítógépen futó Push daemon.)

Habár a Push hivatalos dokumentációjából nem derül ki, kicsit a sorok között olvasva arra a következtetésre juthatunk, hogy a készülékek folyamatos kapcsolatban vannak az APNS-szerverrel, ezért lehetséges egy-egy Push-Token segítségével eldönteni, hogy mely eszközökre kell elküldeni az üzeneteket.

Man in the middle

A Man-in-the-middle típusú támadás végrehajtásához először is – a már említett módon – hozzá kell adnunk a készüléken lévő Keychainhez egy Certificate Authority-t, hogy egy proxy-szerverre irányíthassunk át minden, a hálózaton átmenő adatot. Továbbá, mivel a hitelesítés kétoldli (tehát nemcsak az Apple szerverei ellenőrzik a készülék identitását, hanem fordítva is), ezért a Push-szerverekkel is el kell hitetnünk, hogy a „proxy valójában a készülék”. Ezt úgy oldjuk meg, hogy kibontjuk a készülék által küldött adatokból a Push-tanúsítvány privát részét, és azt telepítjük a proxy-ra is.

Így már nem nehéz lehallgatni a kommunikációt. Amit találtunk:

0a                    >> Message Type
XX XX XX XX           >> Next Length
04 00 04 XX XX XX XX  >> Identifier (4 bytes)
01 00 14 XX .. .. XX  >> Topic Hash (20 bytes)
02 00 20 XX .. .. XX  >> Push-Token (32 bytes)
03 XX XX ...          >> iMessage payload

(az XX-szel jelölt bájtok változnak, mert az üzenet hosszától és tartalmától függenek.)

Mivel a kommunikáció az elejétől a végéig titkosított, a titkosítási kulcsokat a felek vagy közvetlenül eljuttatják egymáshoz, vagy létezik egy úgynevezett „kulcskönyvtár” (key directory), ahol ezeket biztonságosan tárolják, és hitelesítés ellenében kiadják. Valóban, az Apple-nek léteznek úgynevezett ESS-szerverei (maguk a hackerek sem tudják, mit jelenthet ez a rövidítés), amik kulcskönyvtárként működnek. Üzenetküldéskor tehát a Messages app először ide küld egy lekérést, a következő formátumban:

GET /WebObjects/QueryService.woa/wa/query?uri=tel:+33123456789
'Host': service1.ess.apple.com
'Content-Type': application/x-apple-plist
'x-id-cert': [Provision Certificate]
'x-id-nonce': [Random Nonce with Timestamp]
'x-id-sig': [Query Signed with Provision Cert.]

Láthatjuk, hogy itt a +33123456789 URI-hez (ez egy Apple ID-hoz kötött (készülék)azonosító, ami lehet telefonszám vagy e-mail cím is) kéri a kulcsokat. Ez a lekérés szintén titkosított, és egy Provision nevű certificate-tel van aláírva. A Provision tanúsítványt pedig egy Apple IDS Realm CA nevű tanúsítványhatóság írja alá. Ez egy hónapig érvényes.

A szerver válasza egy XML property list, amit a könnyebb olvashatóság kedvéért JSON-ra konvertáltunk nektek:

{
  'push-token': [PushToken]
  'client-data':
  {
    'show-peer-errors': True,
    'public-message-identity-version': 1.0,
    'public-message-identity-key': [Public Keys Buffer]
  }
}

Minden egyes Push tokenhez tartozik egy ugyanilyen válasz. A két, már fentebb említett nyilvános kulcs egyike az ECDSA, egy 256-bites kulcs, ami a címzett válaszát hivatott ellenőrizni. A másik egy 1280-bites kulcs, ami a kimenő üzenetet kódolja.

A ténylegesen elküldött adat ismét egy property list, ezúttal bináris formában. A következő kulcs-érték-párokat tartalmazza:

D:   True
E:   'pair'
P:   <variable length binary data> (iMessage payload, deflate compressed)
U:   <128bit binary data> (iMessage UID)
c:   100
i:   <32bit integer> (messageId, same as in PUSH header)
sP:  mailto:tim_c@icloud.com  (sender URI)
t:   <256bit binary data> (sender Push-Token)
tP:  mailto:mark_z@facebook.com (receiver URI)
ua:  [Mac OS X,10.8.5,12F37,MacBookPro10,2] (sender OS and hardware version)
v:   1

A „P” mező a tényleges iMessage payload. Ez titkosított és tömörített (igen, először titkosított, és csak azután tömörített…). A következő információ található benne:

(byte)     0x02          version?
(short)    ciphertext    length
(data)     ciphertext    RSA / AES-CTR data : ciphered with the RSA public key of the recipient
(byte)     signature     length
(data)     signature     ECDSA signature of <ciphertext> : computed with the ECDSA private key of the emitter

A titkosítást feloldva újabb property list fájlt kapunk:

p: array of URIs in the discussion group
t: iMessage text (for iOS)
v: version (1)
x: iMessage html (attachments, and style - for OS X)

A tényleges támadás

A man-in-the-middle támadás esetén a „középen” lévő ember háromféleképpen helyezkedhet el: vagy a küldő és a Push-szerver között, vagy a Push-szerver és a címzett között, vagy mindkét helyen egyszerre.

Álljon még itt egy pár kép arról, hogy mit is lehet elérni az egyes támadástípusok esetén:

Man-in-the-middle 1

Itt a támadó a feladó és az Apple szervere között helyezedik el, így az elküldött üzeneteket valamint a feladónak érkező válaszokat tudja olvasni és módosítani. (Nyilván ugyanez igaz a feladóoldali elrendezésre is, a kommunikáció szimmetrikus.)

Még ennél is nagyobb hatalmat kap a támadó, ha mindkét oldalon be tud avatkozni az üzenetváltásba:

mitm2

Ekkor mindkét fél üzeneteit tudja olvasni és módosítani. De mi a helyzet akkor, ha mégegy lépéssel tovább megyünk? Ha egészen egyszerűen lemásoljuk az Apple kulcsait, és teljesen megkerüljük a Push-szervereket? Ekkor egy klasszikus, egyszerű MITM-támadássá avanzsál a módszer:

mitm3

Ez egyben azt is bizonyítja, hogy a támadó helyére betehetjük magát az Apple-t is. Mivel a szerverek rendelkeznek minden szükséges kulccsal, az end-to-end titkosítás ellenére tudják olvasni és manipulálni az üzeneteket. (Ehhez az eljáráshoz szükséges mindkét fél titkos és nyilvános kulcsa, hiszen a titkosított üzenetet ki kell bontatni az olvasáshoz a címzett titkos kulcsával, és módosítás után visszakódolni a nyilvános kulccsal. A másik irányban a feladó kulcsaira igaz ugyanez.)

Demonstráció

A hackerek egy videót is készítettek, amiben konkrétan megvalósítanak egy ilyen támadást. Láthatjuk, amint a „megpatkolt” készüléken küldött és fogadott üzenetek „maguktól” l33tsp34k-ké alakulnak:

Mit tehetünk ez ellen?

Két dolgot. Az egyik dolgot csak az Apple valósíthatja meg: egy átláthatóbb, megbízhatóbb protokollt és titkosítási infrastruktúrát kellene kiépítenie. A másik, amit megpróbálhatunk, az az, hogy egy, az Apple-től független titkosítási réteget használunk, tehát nem sima szövegben (plaintext) küldjük el iMessage-einket, hanem egy olyan kulccsal kódoljuk, amit sem az Apple, sem más potenciális hallgatózó, támadó nem ismer, csak a küldő és fogadó fél.

Ezen felül Pod2G csapata írt egy iMITMProtect nevű alkalmazást, ami megpróbálja a cikk elején leírt certificate pinning hiányát orvosolni oly módon, hogy az első alkalommal, amikor a Push-Tokent és a kriptográfiai kulcsokat megkapja egy készülék, akkor azokat egy helyi adatbázisban tárolják. Ha ezek bármikor megváltoznak, akkor gyanakodni lehet, hogy valaki hallgatózik, tehát az alkalmazás figyelmeztet minket erre. Az app egyelőre csak OS X-re érhető el, de a fejlesztők azt ígérik: amint megjelenik a jailbreak, készítenek belőle cydiás változatot is, iOS-készülékekre.

Nektek mi a véleményetek erről a biztonsági hibáról? Valós problémának tartjátok?

iSamurai iPhone szerviz akció

Így vicceld meg az ismerőseidet iMessage-en!

Mára már biztos sokan ismeritek az iMessage azon funkcióját, amikor valaki ír nektek és mutatja ahogy a másik fél “gépel”. Lehet, hogy elsőre nem ugrik be, de az alábbi kép biztos segíteni fog:

iMessage-hell

@gabriel_whaley kolléga rájött, hogy ezzel akár ismerőseinket is megviccelhetjük. Elkészítette ennek a kis buboréknak a mozgó GIF változatát, amit csak le kell töltenetek a telefonra.

Egyszerűen írjatok egy “nézzétek mit találtam:”-t üzenetet az ismerősnek, majd küldjétek el ezt a képet és várjátok meg, mikor jön rá, hogy csak egy képet lát és nem fog kapni semmi üzenetet. 🙂

bMB7QpX

(A kép a szifon.com alkalmazásból nem tölthető le, használjátok a webes felületünket!)

Ugyan a GIF maga nem tökéletesen ugyanaz, mint ami az iOS 7-ben olyankor látszik, amikor a másik fél éppen ír, ettől még sokaknak nem fog elsőre leesni a turpisság. A másik fontos dolog, hogy a képek között a GIF nem fog mozogni, csak elküldve, illetve csak iOS 7 esetén lehet vele megviccelni a másikat, hiszen korábbi rendszeren még másképp nézett ki a beérkezett üzenet buborékja. 😉

iSamurai iPhone szerviz akció

Az Apple már dolgozik az iMessage-et érintő hiba javításán

Többen jeleztétek nekünk is, hogy az iOS 7-re történt frissítést követően problémák akadtak az iMessage kapcsán, így például az üzenetek megérkeztek, de a válasz elküldése sokszor sikertelen volt, vagy automatikusan átváltott SMS-re vagy MMS-re. Az Apple elismerte a hibát, és már dolgozik a javításán.

iMessage

A cég a The Wall Street Journal újságíróinak kérdésére azt a tájékoztatást adta, hogy tudnak a hibáról, ami a felhasználók egy adott részét érinti, és azt eredményezi, hogy az üzenetek vagy nem küldhetőek el, vagy nem érkeznek meg, vagy pedig iMessage helyett SMS/MMS formában mennek el. Ezek csak egyes iPhone modellek esetén jönnek elő, ha azokon iOS 7 fut:

We are aware of an issue that affects a fraction of a percent of our iMessage users, and we will have a fix available in an upcoming software update. In the meantime, we encourage any users having problems to reference our troubleshooting documents or contact AppleCare to help resolve their issue. We apologize for any inconvenience this causes impacted users.

Tudunk egy problémáról, ami az iMessage-felhasználók töredékét érinti, és ezt a hibát hamarosan javítjuk egy szoftverfrissítésben. Addig is, kérjük a hibát tapasztaló felhasználókat, hogy kövessék a problémamegoldással kapcsolatos dokumentumokban leírtakat a weboldalunkon, vagy keressék fel az AppleCare-t, hogy segíthessünk megoldani ezt a gondot. Minden érintett felhasználó elnézést kérjük a kialakult helyzet miatt.

Így tehát várhatóan hamarosan érkezik az iOS 7.0.3, amiben ezt a hibát (is?) javítja a cég, és ami kapcsán már felröppentek a hírek, hogy már tesztelés alatt áll.

Ugyanakkor nem szükséges megvárni a frissítés megjelenését, mert a tapasztalatok alapján pár egyszerű lépéssel a legtöbb esetben megoldható a gond, ahogyan azt délelőtt már írtuk a facebook oldalunkon is. Először is indítsuk újra a készülékünket, hátha az megoldja. Ha az önmagában nem segített, akkor pedig próbáljuk meg ezt:

  1. kapcsoljuk ki az iMessage-et a Beállítások (Settings) / Üzenetek (Messages) alatt;
  2. töröljük a hálózati beállításokat a Beállítások (Settings) / Általános (General) / Visszaállítás (Reset) alatt;
  3. kapcsoljuk vissza az iMessage-et.

A jelek szerint ez általában megoldja a gondot, de előfordulhat, hogy pár óra múlva ismét jelentkezik a hiba, és újból végre kell ezt a lépéssort hajtani. Ebben az esetben sajnos meg kell várni, hogy az Apple kiadja a frissítést.

Egyéb esetekben is használható általános problémamegoldási lehetőségeket felsoroló cikkünk: Gyakori kérdések: mit tehetünk, ha furcsa dolgokat produkál a készülékünk?

iSamurai iPhone szerviz akció

Nem összeesküvés, hanem furcsa iMessage hiba iPhone és iPod Touch esetén

Az Apple iMessage szolgáltatását elég sok kritika éri mostanában. Több alkalommal akadozott az utóbbi hónapokban, vagy a Mac-es kliense produkál furcsa dolgokat, és így az üzenetek sokszor nincsenek szinkronban az egyes eszközök között. Most egy újabb hiba bukkant fel, aminek utánajártunk.

iPhone-Messages-Icon

A hibát egy reddit felhasználó osztotta meg talán elsőként, majd utána futótűzként kezdett terjedni twitteren is. A jelenség lényege, hogy például a következő két mondat esetén az utolsó szó eltűnik az üzenetből már küldés közben, ha a végére plusz szóköz kerül:

“I could be the next Obama ”
“The best prize is a surprise “

A tesztjeink alapján a probléma csak angol nyelven használt és csak retina kijelzős iPhone és iPod Touch esetén jelentkezik, tehát más nyelven, így például magyarul vagy mondjuk németül használva nem. A nem retina készülékek, így mondjuk az iPhone 3GS nem érintettek, ahogyan az iPad semelyik verziója sem.

Elküldés után mindez így néz ki egy iPhone 4S-en:

iMessage_hiba_01_retina_iPhone

 iPhone 3GS-en ugyanakkor hiba nélkül megjelenik a szöveg:

iMessage_hiba_02_iPhone_3GS

A retina kijelzős iPod Touch 4G esetén látható, hogy csak angolul használva tapasztalható a jelenség, magyarul rendben van minden. Egyúttal az is látható, hogy magyarra állítva a szöveg tördelése is változik, és az egyes buborékok szélessége is más, mint az angolon:

iMessage_hiba_05_retina_iPod_Touch_4G_eng iMessage_hiba_06_retina_iPod_Touch_4G_hun

A Mac-es iMessage sem érintett, a szöveg ott is rendesen megjelenik, itt sincsenek hiányzó szavak:

iMessage_hiba_03_Mac

Ráadásul ha kimásoljuk az ilyen csonka üzenetet, akkor a kimásolt szöveg tartalmazza az így lecsípett szót a mondat végéről is. Tehát az eltűnő szavak végül is ott vannak, csak a készülék nem jeleníti meg őket.

Nem összeesküvés és nem is cenzúra

A problémát valójában nem a mondatok tartalma adja, sem nem az, hogy be van-e kapcsolva a szöveg automatikus javítása vagy sem. Ráadásul csak retina kijelzős iPhone-okon és iPod Touch-okon jelentkezik, és azokon is csak akkor, ha angolra állítva használjuk őket, és már megnyitottuk az adott beszélgetést. Az összes beszélgetésünk listáját böngészve nincs ilyen gond, ott végig megjelenik a szöveg. Többen már összeesküvést és cenzúrát kiáltottak, miközben messze nem erről van szó. 🙂

Az egész oka igen prózai, és valójában a felhasznált betűk szélessége és a mondat karaktereinek a száma együttesen okozza. Az iOS-ben a Messages app szövegbuborékjai esetén a szöveget tartalmazó rész (textbox) maximális szélessége adott, hogy kiférjen a gondosan megtervezett grafikus felületre mindkét fél üzenete, és a dizájn is szépen mutasson. (Érdekes, hogy míg iOS-en a szöveg balra zárt igazítással jelenik meg, addig a Mac-es Messages-ben jobbra zártként: az egységesnek szánt dizájn szempontjából furcsa, hogy egy ilyen “apróság” nem egyezik.)

Az iOS tehát a szöveget bizonyos karakterszám után újabb sorba tördeli tovább, ezzel biztosítva a szövegbuborék maximális szélességének megtartását. Közben a buborék magasságát növeli, hiszen fel-le tudunk görgetni.

A gond például akkor jelentkezik, amikor a karakterek száma talán még nem éri el a kívánt értéket, de a betűk szélessége miatt már nem férne ki az adott sorba a szöveg, így azt a szöveget új sorba kellene tennie. Ehelyett azonban a mondat végi szó egyszerűen eltűnik a szövegbuborékból. Ha Obama vagy a surprise után nem teszünk újabb szóközt, akkor nincs gond, illetve ahogy fentebb már említettük, az adott üzenetdarabot kimásolva az tartalmazza a lecsípődött szövegrészt is.

A betűszélességet, mint okot a legjobban az alábbi példa bizonyítja. Míg a “wtf man my mind is blown ” szöveg kis w-vel kezdve probléma nélkül megjelenik, addig a “Wtf man my mind is blown ” esetén, tehát a szöveget nagy W-vel kezdve már szintén tapasztalható a lecsípődés:

iMessage_hiba_04_retina_iPhone

Természetesen más, hasonló betűszélességet és karakterszámot eredményező mondatokkal is lehet próbálkozni, de minden esetben igaznak tűnik, hogy szóközzel kell zárni a szöveget.

Egy szóval nem kell attól tartani, hogy az Apple cenzúrázná az üzeneteinket, egyszerű szoftveres hibáról van szó.

Ki lesz az első, aki talál egy magyar példamondatot erre a hibára? 🙂

iSamurai iPhone szerviz akció

iMessage és FaceTime problémák T-mobile esetén?

Több levelet kaptunk tőletek az elmúlt két napban annak kapcsán, hogy T-mobile esetén nem működik megfelelően az iMessage és néhány esetben a FaceTime szolgáltatás sem. Ma egy tesztkészüléken mi is kipróbáltuk, és a tapasztalatok alapján sem a hálózati beállítások törlése, sem a készülékszoftver teljes visszaállítása (restore) nem oldja meg a problémát, ráadásul ez igazából még csak tovább ront a helyzeten, mert utána már visszaaktiválni sem lehet. Az aktiváló SMS-t ugyan elküldi a készülék, de a válasz, és így a tényleges aktiválás nem érkezik vissza. Ehelyett jó hosszú várakozás után a sikertelenségről kapunk csak visszajelzést – pont, mint annak idején, amikor a Telenornál volt lehetetlen a mobilszámra történő aktiválás.

Az egyik email írója megkérdezte a T-mobile-os ügyfélszolgálatos kollégákat is, akik azt mondták neki, hogy már több bejelentést kaptak ezzel kapcsolatban, de a hiba nem az ő rendszerükben van, így sajnos csak közvetett módon tudnak segíteni: felvették az Apple-lel a kapcsolatot. Remélhetőleg tehát hamarosan megoldódik a probléma.

Akinek jelenleg működik a szolgáltatás, annak azt javasoljuk, hogy ne kapcsolja ki, mert gondja lehet a visszakapcsolásnál. Ha pedig bármi ok miatt restore-ra kényszerülünk, akkor a backupból való visszaállítás elvileg az aktiválást is visszateszi, ugyanakkor jailbreakelt eszközről készült backup visszaállítása továbbra sem javasolt.

Nálatok mi a helyzet?

iSamurai iPhone szerviz akció

Csak Mountain Lion esetén lesz elérhető a Messages app?

Az Apple február 16-án váratlanul közzétette a Mac OS X új verziójának fejlesztőknek szánt előzetesét, és ezzel együtt több új funkcióról is lerántotta a leplet. A Mountain Lion névre keresztelt OS X 10.8-ról már írtunk is aznap, így azt most nem ismertetnék újból. Sokkal inkább szót ejtenénk viszont az iMessage-támogatást a Mac-re is elhozó Messages appról, amit aznap mindenki számára elérhetővé tettek, persze csak beta állapotban, ahogyan azt annak idején a FaceTime for Mac app esetén is tették.

Az Apple ezzel az alkalmazással egyúttal az iChat-et is felszámolja majd, és integrálja az új appba, egyúttal iMessage-et is küldhetünk vele iOS eszközökre, és a FaceTime-ot is elérhetjük belőle egyetlen kattintással.

Persze nem eszik azt a kását olyan forrón. Már maga a Mountain Lion sem lesz elérhető minden olyan gépre, amin a Lion elfut. Csak azokra lesz jó, amelyekben 64bites, legalább Core 2 Duo, vagy annál jobb processzor van, és újabb típusú grafikus chipsettel rendelkeznek. Az Apple a következő Mac-eket tehát már nem fogja támogatni a Mountain Lion-nal:

  • Intel GMA 950 vagy x3100-as grafikus kártyával rendelkező modellek
  • ATI Radeon X1600-as grafikus kártyával rendelkező modellek
  • 2008 előtti MacBook modellek
  • 2007 előtti Mac Mini-k
  • 2007 előtti iMac-ek
  • első kiadású MacBook Air

Várható volt a váltás, de azért mégis kellemetlenül érinti majd az adott modellek tulajdonosait. Sajnos azonban ezzel nincs vége a rossz híreknek.

A Consomac felfedezése szerint a Messages app csak beta állapotában támogatja a Lion-t, a Mountain Lion megjelenésével viszont nem fog már többet működni az app a sima Lion esetén:

Annak idején a FaceTime app megvásárolható volt még Snow Leopard alatt is a Mac App Store-ból, és nem volt hozzá feltétlenül szükséges a Lion, de a fentiek alapján úgy tűnik, a Messages esetén ez sajnos másképp lesz. Így amennyiben támogatott géppel rendelkezünk, akkor meg kell majd vásárolnunk a Mountain Lion-t, ha továbbra is használnánk a Messages-t.

Ha viszont nem tudunk frissíteni, mert nem támogatja a gépünket az új rendszer, a jelek szerint a Messages appot sem fogjuk tudni használni majd. A fenti kép szövege ugyanis egy olyan hibaüzenetet mutat, amelyet akkor kaphatunk majd, ha Lion-t használunk, de a Messages app bétatesztje már lezárult, és a Mountain Lion már megvásárolható. És mivel az üzenet az új rendszer megvásárlására kéri a felhasználót a további használat érdekében, így sejthető, hogy meg is szűnik majd működni az app Lion esetén.

iSamurai iPhone szerviz akció

Lehetséges a FaceTime és az iMessage aktiválása Telenoron!

Pár perce kaptuk a tippet, hogy lehetővé vált a FaceTime és az iMessage aktiválása a Telenoron használt iPhone-ok esetén is! Ez azért nagy jelentőségű hír, mert nagyjából azóta, hogy megjelent az iOS 4.1, erre nem volt lehetőség: a készülék csak annyit írt ki, hogy várakozás, majd bizonyos idő után azt, hogy sikertelen.

Az iOS5 megjelenéséig viszont semmi módon nem lehetett aktiválni a FaceTime-ot Telenoron, még csak jailbreak után sem, és erre nem volt semmi magyarázat, hogy miért nem.

Az iOS5-ben viszont lehetővé vált az Apple ID alapú aktiválás, ami egy köztes megoldás csak, hiszen így egy újabb azonosítót kellett megadni másoknak, hogy azon elérjenek, hiszen mobilszám alapján nem ment a dolog. Ez főleg az iMessage esetén volt bosszantó solog, hiszen ott az SMS-t ugye alapból mobilszámra küldjük, viszont ilyenkor a rendszer automatikusan felismeri, ha egy szám regisztrálva van az Apple központjában, és akkor automatikusan átvált az ingyenes iMessage-re (mobilnet vagy wifi szükséges).

Most viszont elérhetővé vált Telenoron is az SMS-alapú, mobilszámra történő aktiválás, így mostantól a Telenoros kollégák is elérhetőek lesznek FaceTime-on, és iMessage-en keresztül a mobilszámuk segítségével! 🙂

 

Teendők: pöccintsd át a készüléked menüjében az aktiválás gombot, és várj pár percet, míg az Apple központjából visszaérkezik az aktiválási válasz. Az iMessage-re akár több percet is kell várni, míg aktiválja!

Figyelem: ha kiveszed a kártyát a készülékből, miközben az be van kapcsolva, akkor utána újra kell majd aktiválni. Ha kikapcsolt állapotában veszed ki a kártyát, és nem kapcsolod vissza közben, akkor elvileg nem kell újra aktiválni.

Azt sajnos nem lehet tudni egyelőre, hogy ez meddig marad így, de jelenleg működik, és reméljük, így is marad.

Tipp: ha olyan valakinek próbálsz iMessage-t küldeni, aki most aktiválta, de nálad nem kékül be az üzenet a küldésnél, és így SMS-ként megy el, akkor indítsd újra a készüléked, és onnantól mennie kell. Az iMessage ugyanis “megjegyezte”, hogy az adott számra nem tud küldeni, de egy újraindítás után ezt ismét leellenőrzi. (A készülék újraindítása után az iMessage-et és a FaceTime-ot nem kell újból aktiválni!) Ha továbbra sem akar bekékülni, akkor nyiss egy új üzenetet, és úgy próbáld meg – ezt az új üzenetet az iOS automatikusan hozzácsapja a korábbi üzenetváltáshoz, de így biztosan újra leellenőrzi a rendszer, hogy el tudja-e küldeni iMessage-ként, vagy nem.

(Ennél a cikknél minden más, OFF-topic hozzászólást törölni fogunk.)

iSamurai iPhone szerviz akció