Mobi-Forum.de

Hallo Mitnutzer,

hier im Forum schon öfter angesprochen, aber nicht endgültig gelöst: beim Empfang einer SMS mit Sender-Synonym (vornehmlich verwendet von kommerziellen Diensten wie Banken [smsTAN], Netzprovider [Konfigurationsnachrichten], o.Ä.) im e-Plus-Netz kommt es reproduzierbar zum Absturz des SMS-Programmes. Im Log finden sich dem unten Gezeigtem ähnliche Einträge...
Dies ist entgegen anders lautender Zitate des PEARL-Supports ein behebbares Software-Problem (das kann euch anhand des Logs jeder Android-Entwickler bestätigen). Das Problem lässt sich sogar relativ einfach beheben, wenn man über den Quelltext verfügt (d.h. wahrscheinlich nur von Simvalley). Leider sieht es auch noch so aus, als würde das Synonym UNMODIFIZIERT in eine Datenbankabfrage geschrieben - ein möglicher Angriffspunkt für eine sogenannte SQL-Injection.
Weiterhin ist es nicht empfehlenswert, Apps von Drittanbietern zu installieren: das mehrfach angepriesene "Handcent SMS" wurde mittlerweile (aus mir nicht bekannten Gründen aus dem Markt genommen), fordert unter anderem für ein SMS-Programm unerklärliche Rechte (z.B.: Netzwerkkommunikation, Netzwerkkonnektivität ändern, Telefonnummern direkt anrufen, DRM-Content installieren, Ändern von Hintergrundbildern) und wird von folgendem Unternehmen vertrieben (Auszug aus "whois handcent.com"):

Handcent Corporation (HK) Limited
Room 705-706,7/F China Insurance Group
Building,NO.141 Des Voeux Road Centernal
HongKong 852
Hong Kong

Das klingt alles höchst zwielichtig!!! Wer hiermit Banking-TANs empfängt, dem wünsche ich Hals- und Beinbruch Ich empfehle euch, euch nicht von halbherzigen Aussagen des PEARL-Supports abspeißen zu lassen, sondern auf Nachbesserung zu pochen! Ein als Handy angepriesenes Produkt muss SMS empfangen können - egal von welchem Sender und aus welchem Netz! Hier darf es kein Herausreden seitens PEARL geben. Ich habe PEARL natürlich bereits informiert, aber einer allein macht denen wohl noch keine Sorgen

Auch wenn es sich jetzt vielleicht nicht so anhört: bis auf diese Sache bin ich mit dem SP-40 aber voll und ganz zufrieden...



Auszug aus dem Log des SP-40 beim SMS-Empfang

10-17 16:49:42.159: ERROR/DatabaseUtils(254): Writing exception to parcel
10-17 16:49:42.159: ERROR/DatabaseUtils(254): android.database.sqlite.SQLiteException: no such column: smsTAN: , while compiling: select * from black_list where PHONE_NUMBERS_EQUAL(phone_number,smsTAN) and block_type in (1,3) order by _id ASC
10-17 16:49:42.159: ERROR/DatabaseUtils(254): at android.database.sqlite.SQLiteCompiledSql.native_compile(Native Method)
10-17 16:49:42.159: ERROR/DatabaseUtils(254): at android.database.sqlite.SQLiteCompiledSql.compile(SQLiteCompiledSql.java:122)
10-17 16:49:42.159: ERROR/DatabaseUtils(254): at android.database.sqlite.SQLiteCompiledSql.<init>(SQLiteCompiledSql.java:95)
10-17 16:49:42.159: ERROR/DatabaseUtils(254): at android.database.sqlite.SQLiteProgram.<init>(SQLiteProgram.java:111)
10-17 16:49:42.159: ERROR/DatabaseUtils(254): at android.database.sqlite.SQLiteQuery.<init>(SQLiteQuery.java:77)
10-17 16:49:42.159: ERROR/DatabaseUtils(254): at android.database.sqlite.SQLiteDirectCursorDriver.query(SQLiteDirectCursorDriver.java:73)
10-17 16:49:42.159: ERROR/DatabaseUtils(254): at android.database.sqlite.SQLiteDatabase.rawQueryWithFactory(SQLiteDatabase.java:1376)
10-17 16:49:42.159: ERROR/DatabaseUtils(254): at android.database.sqlite.SQLiteDatabase.rawQuery(SQLiteDatabase.java:1346)
10-17 16:49:42.159: ERROR/DatabaseUtils(254): at com.android.providers.contacts.ContactsProvider2.queryBlackList(ContactsProvider2.java:5300)
10-17 16:49:42.159: ERROR/DatabaseUtils(254): at com.android.providers.contacts.ContactsProvider2.query(ContactsProvider2.java:5023)
10-17 16:49:42.159: ERROR/DatabaseUtils(254): at android.content.ContentProvider$Transport.bulkQuery(ContentProvider.java:181)
10-17 16:49:42.159: ERROR/DatabaseUtils(254): at android.content.ContentProviderNative.onTransact(ContentProviderNative.java:142)
10-17 16:49:42.159: ERROR/DatabaseUtils(254): at android.os.Binder.execTransact(Binder.java:319)
10-17 16:49:42.159: ERROR/DatabaseUtils(254): at dalvik.system.NativeStart.run(Native Method)
10-17 16:49:42.159: WARN/dalvikvm(572): threadid=8: thread exiting with uncaught exception (group=0x4001d7d
10-17 16:49:42.179: ERROR/AndroidRuntime(572): FATAL EXCEPTION: SmsReceiverService
10-17 16:49:42.179: ERROR/AndroidRuntime(572): android.database.sqlite.SQLiteException: no such column: smsTAN: , while compiling: select * from black_list where PHONE_NUMBERS_EQUAL(phone_number,smsTAN) and block_type in (1,3) order by _id ASC
10-17 16:49:42.179: ERROR/AndroidRuntime(572): at android.database.DatabaseUtils.readExceptionFromParcel(DatabaseUtils.java:189)
10-17 16:49:42.179: ERROR/AndroidRuntime(572): at android.database.DatabaseUtils.readExceptionFromParcel(DatabaseUtils.java:145)
10-17 16:49:42.179: ERROR/AndroidRuntime(572): at android.content.ContentProviderProxy.bulkQueryInternal(ContentProviderNative.java:361)
10-17 16:49:42.179: ERROR/AndroidRuntime(572): at android.content.ContentProviderProxy.query(ContentProviderNative.java:397)
10-17 16:49:42.179: ERROR/AndroidRuntime(572): at android.content.ContentResolver.query(ContentResolver.java:276)
10-17 16:49:42.179: ERROR/AndroidRuntime(572): at com.android.mms.transaction.SmsReceiverService.handleSmsReceived(SmsReceiverService.java:547)
10-17 16:49:42.179: ERROR/AndroidRuntime(572): at com.android.mms.transaction.SmsReceiverService.access$100(SmsReceiverService.java:119)
10-17 16:49:42.179: ERROR/AndroidRuntime(572): at com.android.mms.transaction.SmsReceiverService$ServiceHandler.handleMessage(SmsReceiverService.java:256)
10-17 16:49:42.179: ERROR/AndroidRuntime(572): at android.os.Handler.dispatchMessage(Handler.java:130)
10-17 16:49:42.179: ERROR/AndroidRuntime(572): at android.os.Looper.loop(Looper.java:154)
10-17 16:49:42.179: ERROR/AndroidRuntime(572): at android.os.HandlerThread.run(HandlerThread.java:91)
10-17 16:49:42.189: INFO/Process(119): Sending signal. PID: 572 SIG: 9
10-17 16:49:42.189: WARN/ActivityManager(119): Process com.android.mms has crashed too many times: killing!

Also zuerst einmal ein dickes Lob an dich!
Nicht nur daß du sinnigerweise mal einen eigenen Thread für das SMS-Problem eröffnet hast (der SP-40/60 "Sammelthread" den ich mir gerade noch mal angesehen habe ist ja wirklich eine Ungeheuerlichkeit, als Moderator sieht man das jetzt mit anderen Augen
du hast das Problem schon recht gut analysiert. Und Logfiles etc. helfen auch immer gut weiter...

Zitat von »Chronos«

beim Empfang einer SMS mit Sender-Synonym (vornehmlich verwendet von kommerziellen Diensten wie Banken [smsTAN],

so was hab ich noch nicht gesehen: Es gibt also SMS bei der keine Nummer sondern eine Zeichenkette als Absender übertragen wird?
Das ist natürlich eine nette Fehlerquelle für Programmierer...

Zitat von »Chronos«

entgegen anders lautender Zitate des PEARL-Supports ein behebbares Software-Problem

Das ist typisch... Es handelt sich ja offensichtlich um ein Softwareproblem, und so was ist immer "behebbar", zumindest vom Hersteller der Software...

Zitat von »Chronos«

Leider sieht es auch noch so aus, als würde das Synonym UNMODIFIZIERT in eine Datenbankabfrage geschrieben - ein möglicher Angriffspunkt für eine sogenannte SQL-Injection.

Nach dem was ich darüber rausgefunden habe ist das nicht ganz das Problem, aber du hast wohl recht damit....
Eine differenziertere Prüfung der Eingaben wäre schönerer (und unangreifbarerer) Code und schont die Exception-Library

Zitat von »Chronos«

10-17 16:49:42.159: ERROR/DatabaseUtils(254): android.database.sqlite.SQLiteException: no such column: smsTAN: , while compiling: select * from black_list where PHONE_NUMBERS_EQUAL(phone_number,smsTAN) and block_type in (1,3) order by _id ASC

So wie ich das bei meiner Recherche verstanden habe liegt hier der Hund begraben: der Wert smsTAN wird irrtümlicherweise für einen Spaltennamen gehalten (wie phone_number), da er nicht in Anführungszeichen (Single Quote) steht.
Bei Zahlen parst SQLITE automatisch richtig.

Zusätzlich wäre dann noch interessant zu wissen wie die SQLITE-Funktion PHONE_NUMBERS_EQUAL mit Strings als Paramter umgeht.

Wie Chronos sagt, ein Softwareproblem und sicher nicht allzu schwer zu beheben...

Zitat von »Chronos«

fordert unter anderem für ein SMS-Programm unerklärliche Rechte (z.B.: Netzwerkkommunikation, Netzwerkkonnektivität ändern, Telefonnummern direkt anrufen, DRM-Content installieren, Ändern von Hintergrundbildern)

Öha, das klingt wirklich SEHR dubios....
Die "Netzwerkkommunikation" ist überhaupt ein sehr nerviges Recht unter Android ... Viele Anwendungen wollen es, da sie sich über (nachgeladene) Werbung finanzieren. Trotzdem läßt sich diese "geöffnete Tür" dann leider auch für andere Zwecke ge- bzw. mißbrauchen.

Aber als Zwischenlösung bleibt dir glaub ich nichts anderes übrig als auf eine alternative SMS-App deines Vertrauens zu setzen
Oder du nutzt ein anderes Handy für Online-Banking...

Zitat von »Blackthorne«

so was hab ich noch nicht gesehen: Es gibt also SMS bei der keine Nummer sondern eine Zeichenkette als Absender übertragen wird?
Das ist natürlich eine nette Fehlerquelle für Programmierer...

Jup; als kommerzieller Anbieter kauft man sich iDR einen Zugang zu sogenannten SMS-Gateways und kann nicht nur den Absender BELIEBIG (!) auswählen, sondern eben auch Zeichenketten verwenden... Heißt für den Programmierer: aufgepasst!

Zitat von »Blackthorne«

Öha, das klingt wirklich SEHR dubios....
Die "Netzwerkkommunikation" ist überhaupt ein sehr nerviges Recht unter Android ... Viele Anwendungen wollen es, da sie sich über (nachgeladene) Werbung finanzieren. Trotzdem läßt sich diese "geöffnete Tür" dann leider auch für andere Zwecke ge- bzw. mißbrauchen.

Das Thema Sicherheit ist unter Android nicht ohne... Schlimmer: vermeintliche Kompetenzen geben gerne ungefragt Ratschläge, die sie besser nicht geben sollten. In diversen Android-Zeitschriften liest man, man könne Apps, die schon oft heruntergeladen wurden, beruhigt installieren. DAS IST EINFACH FALSCH! Am Ende kommt es fast ausschließlich auf die Berechtigungen an. (Niemand hält mich davon ab, eine tolle, kostenlose App zu bauen, die erst nach einem Jahr anfängt, Unfug zu treiben...) Wenn eine App Berechtigungen fordert, die sie zur Erledigung ihrer Aufgabe nicht benötigt, sollte man sie mit aller Macht des Verbrauchers bestrafen: mit konsequentem Nicht-Download

Werbung ist leider in vielen Anwendungen nötig, um die Entwicklung zu finanzieren: Programmierer muss essen! Um dem Missbrauch des Internet-Rechts vorzubeugen, müsste Android ein explizites Werbe-Recht einbauen... Dann wären aber die Fragen: welche Werbe-APIs werden unterstützt? Wer prüft deren Seriösität? Und werden die kleinen Werbeplattformen nicht unverhältnismäßig benachteiligt?

Zitat von »Blackthorne«

Aber als Zwischenlösung bleibt dir glaub ich nichts anderes übrig als auf eine alternative SMS-App deines Vertrauens zu setzen
Oder du nutzt ein anderes Handy für Online-Banking...

Für Online-Banking benutze ich in der Tat ein anderes Handy

Update bzgl. PEARL: Der PEARL-Kundenservice teilt mir leider mit, "dass es derzeit keine Alternative zur genannten Software gibt. Ihre Angaben wurden zur Prüfung an die zuständige Abteilung weitergeleitet." Weiterhin: "Selbstverständlich bieten wir Ihnen eine Rücknahme des Produktes an."

Ich denke, ich werde denen jetzt eine Minderung anbieten und mich woanders nach einer Lösung (= SMS-App) umsehen...

Zitat von »Chronos«

Jup; als kommerzieller Anbieter kauft man sich iDR einen Zugang zu sogenannten SMS-Gateways und kann nicht nur den Absender BELIEBIG (!) auswählen, sondern eben auch Zeichenketten verwenden... Heißt für den Programmierer: aufgepasst!

Dann stell ich mal eine Frage: es könnte ja einen SMS-Strandard geben, der davon ausgeht, dass der Absender sich auch mit einer Telefonnummer meldet - einer gültigen versteht sich - dass die hier dafür missbraucht wird, dass keiner dem TAN-Server antwortet, ist eine andere Sache. Also doch ein (Sicherheits-) Feature .

Weltweit muss ja nicht jeder das Verhalten deutscher Banken kennen - mal sehen, ob es ein Update hierzu gibt.

Zur Programmierung: wenn ich eine Zahl erwarte und meine Datenbank in einer Spalte nur Zahlen zulässt, sollte ich dies prüfen - das relativert natürlich das Feature von oben. Es könnte dann eine Meldung kommen: von dieser "Nummer" akzeptiere ich keine SMS, weil sie dem SMS-Standard wiederspricht (nur fiktiv: keine Ahnung ob es so einen Standard überhaupt gibt). Eine Exception ist nur blöd, zumal das Laufzeitverhalten hier nicht interessiert.

Wie dem auch sei, Pearl kann nichts dafür, der Programmierer wird jede Schuld von sich weisen (in China gibt es so was nicht) und der arme Anwender sollte sich ein anderes Programm (oder besser einen anderen Handy ) zulegen.

Günter

Zitat von »guenter«

Dann stell ich mal eine Frage: es könnte ja einen SMS-Strandard geben, der davon ausgeht, dass der Absender sich auch mit einer Telefonnummer meldet - einer gültigen versteht sich - dass die hier dafür missbraucht wird, dass keiner dem TAN-Server antwortet, ist eine andere Sache. Also doch ein (Sicherheits-) Feature .

Weltweit muss ja nicht jeder das Verhalten deutscher Banken kennen - mal sehen, ob es ein Update hierzu gibt.

Es gibt einen Standard dazu - und Zeichenketten sind valide Eingaben. Erfunden haben es auch nicht die deutschen Banken Es gibt sicherlich hunderte Dienste weltweit, die dieses Einsetzen...

Zitat von »guenter«

Wie dem auch sei, Pearl kann nichts dafür, der Programmierer wird jede Schuld von sich weisen (in China gibt es so was nicht) und der arme Anwender sollte sich ein anderes Programm (oder besser einen anderen Handy ) zulegen.

Neee, Pearl kann natürlich nichts dafür; aber sie sind ja sehr guter Kunde von Simvalley und sollten da im Interesse ihrer Kunden mal etwas Druck machen. Sie haben ja auch Rücknahme angeboten. Was wirklich ärgert ist nur, dass sie das Programm eines Drittanbieters empfehlen, ohne sich ernsthaft Gedanken darüber zu machen

Zitat von »Chronos«

Es gibt einen Standard dazu - und Zeichenketten sind valide Eingaben

Hast du einen Link zum Thema, würde mich interessieren.

Günter

Irgendwo hier sollte es drin stehen:

http://www.etsi.org/deliver/etsi_ts/1230…040v100000p.pdf

Es reicht aber auch, darüber nachzudenken, warum die Android-API an dieser Stelle überhaupt Strings zulässt...

Zitat von »Chronos«

warum die Android-API an dieser Stelle überhaupt Strings zulässt

du meinst NICHT zuläßt oder?

Für mich ist eher die Frage wieso SMS-Absender überhaupt Strings sein dürfen....

Zitat von »Blackthorne«

Zitat von »Chronos«

warum die Android-API an dieser Stelle überhaupt Strings zulässt

du meinst NICHT zuläßt oder?

Für mich ist eher die Frage wieso SMS-Absender überhaupt Strings sein dürfen....

Zitat von »Blackthorne«

Zitat von »Chronos«

warum die Android-API an dieser Stelle überhaupt Strings zulässt

du meinst NICHT zuläßt oder?

Für mich ist eher die Frage wieso SMS-Absender überhaupt Strings sein dürfen....

Nein, ich meinte schon "zuläßt"...

Mittlerweile habe ich mir ein anderes Gerät besorgt, dass die gewünschten Dienste verrichtet, das Alcatel 918D: auch kein Smartphone-Wunder, aber Dual-SIM und hat keine Probleme mit dem SMS-Empfang...

Wäre es nicht möglich eine eigene Ersatz SMS.apk zu compilieren? (quasi eine gepatchte) und einfach die alte überschreiben?

quellcode der von SmsReceiverService.java ist ja frei zugänglich s.h.:

[url]http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android-apps/2.1_r2/com/android/mms/transaction/SmsReceiverService.java/[/url]

kann man daraus eine .apk machen?

oder muss man gar reverse-engineeren?

http://code.google.com/p/android-apktool/