Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: Mobi-Forum.de. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

Beiträge: 7

Handy: Diverse Androids

Wohnort: Berlin

  • Nachricht senden

1

Freitag, 28. Oktober 2011, 15:45

Gestörter SMS-Empfang mit simvalley MOBILE SP-40

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 X(

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=0x4001d7d8)
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!

Blackthorne

Moderator

Beiträge: 992

Danksagungen: 3

  • Nachricht senden

2

Samstag, 29. Oktober 2011, 16:07

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...

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... :P

entgegen anders lautender Zitate des PEARL-Supports ein behebbares Software-Problem
:D Das ist typisch... Es handelt sich ja offensichtlich um ein Softwareproblem, und so was ist immer "behebbar", zumindest vom Hersteller der Software...

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 :P

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...

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... :S

Beiträge: 7

Handy: Diverse Androids

Wohnort: Berlin

  • Nachricht senden

3

Montag, 31. Oktober 2011, 15:06

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... :P


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!


Ö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 :D

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?


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... :S


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...

guenter

Moderator

Beiträge: 736

Handy: Motorola RAZR HD

Danksagungen: 6

  • Nachricht senden

4

Montag, 31. Oktober 2011, 19:08

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 8) - dass die hier dafür missbraucht wird, dass keiner dem TAN-Server antwortet, ist eine andere Sache. Also doch ein (Sicherheits-) Feature :D .

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

Beiträge: 7

Handy: Diverse Androids

Wohnort: Berlin

  • Nachricht senden

5

Montag, 31. Oktober 2011, 20:49

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 8) - dass die hier dafür missbraucht wird, dass keiner dem TAN-Server antwortet, ist eine andere Sache. Also doch ein (Sicherheits-) Feature :D .

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...


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 :thumbdown:

guenter

Moderator

Beiträge: 736

Handy: Motorola RAZR HD

Danksagungen: 6

  • Nachricht senden

6

Montag, 31. Oktober 2011, 23:25

Es gibt einen Standard dazu - und Zeichenketten sind valide Eingaben
Hast du einen Link zum Thema, würde mich interessieren.

Günter

Beiträge: 7

Handy: Diverse Androids

Wohnort: Berlin

  • Nachricht senden

7

Freitag, 4. November 2011, 13:54

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...

Blackthorne

Moderator

Beiträge: 992

Danksagungen: 3

  • Nachricht senden

8

Freitag, 4. November 2011, 18:11

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....

Beiträge: 7

Handy: Diverse Androids

Wohnort: Berlin

  • Nachricht senden

9

Mittwoch, 20. Juni 2012, 13:10

Alternative zum SP-40

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....

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...

Beiträge: 1

  • Nachricht senden

10

Montag, 3. September 2012, 19:45

Hello Its Meee...

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/