[iOS] iAP Receipt Verification

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • [iOS] iAP Receipt Verification

    Ich möchte mich kurz fassen, jedenfalls gibt es seit kurzem einen Tweak in Cydia, der da heißt 'iAP Cracker', mit dem In-App Käufe ohne Kosten freigeschaltet werden können, wenn man denn keine server-seitige Receipt Verification durchführt.
    Glaubt mir, die meisten Anwendungen machen dies nicht, weil es ein Haufen Arbeit macht, obwohl Apple dies dringend empfiehlt.
    In einer Google Gruppe kristallisierte sich recht schnell heraus, dass die meisten entweder gar keinen Server besitzen oder aber nicht in der Lage sind, ein Script zu schreiben, um die Receipts zu überprüfen.
    Also habe ich mich im eigenen Interesse daran gesetzt und letztendlich ist daraus ein Service geworden, der sich noch in der Beta-Phase befindet.
    Dieser Service nimmt dem Entwickler den 'Haufen Arbeit' ab, er muss lediglich noch den Code zum Freischalten in eine andere Methode kopieren.
    Außerdem steht eine API zur Verfügung um in Echtzeit die Zahl an Käufen abzufragen.
    Der Service ist und bleibt kostenlos, eine PayPal-Spende in Höhe von $1 oder mehr wird aber vorausgesetzt, um auf die 'Whitelist' zu kommen.
    Was soll ich sagen, wir haben den Dienst nun schon länger getestet und sind sehr zufrieden.
    Bei Interesse schreibt mir doch eben eine PN. Eine beispielhafte Implementierung findet sich auf GitHub: github.com/iosdeveloper/iAPVerification.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von DroneDeveloper ()

  • Wie funktioniert das eigentlich genau? Wird nach dem der in-app kaufe abgeschlossen ist irgendwo ein License File abgespeichert oder wird die Receipt Verification immer durchgeführt sobald eine Internet Verbindung verfügbar ist? Das ganze klingt sehr interessant, aber wenn die License nach der Receipt Verification in der ipa abgespeichert wird hätte man ja eigentlich nix gewonnen oder? Bei den normal app's ist es ja auch so, dass man nach dem Kauf einefach die ipa entpackt und die jeweiligen File's abändert. Das ganze könnte man ja auch nach der Receipt Verification machen oder? Wenn das alledings nicht so einfach ist wie bei den normalen ipa File's könnte man endlich seine App's besser schützen. Das wäre echt genial :)
    in Bearbeitung

  • und dazu braucht es eine library ?

    Na ich weiß nicht....
    Ich traue dem nicht so wirklich. Wenn Du wirkich was für die Community geben möchtest, stell doch alles online. Ansonsten steht da jetzt auch nicht was die sog. "Whitelist" ist (vor allem in Anführungszeichen).

    Nun denn....

    Hier noch ein bisschen PHP-Code für alle die gerne auf Graylists stehen.

    Quellcode

    1. function getReceiptData($receipt, $isSandbox = false)
    2. {
    3. // determine which endpoint to use for verifying the receipt
    4. if ($isSandbox) {
    5. $endpoint = 'https://sandbox.itunes.apple.com/verifyReceipt';
    6. }
    7. else {
    8. $endpoint = 'https://buy.itunes.apple.com/verifyReceipt';
    9. }
    11. // build the post data
    12. $postData = json_encode(
    13. array('receipt-data' => $receipt)
    14. );
    16. // create the cURL request
    17. $ch = curl_init($endpoint);
    18. curl_setopt ($ch, CURLOPT_SSL_VERIFYHOST, 0);
    19. curl_setopt ($ch, CURLOPT_SSL_VERIFYPEER, 0);
    21. curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
    22. curl_setopt($ch, CURLOPT_POST, true);
    23. curl_setopt($ch, CURLOPT_POSTFIELDS, $postData);
    25. // execute the cURL request and fetch response data
    26. $response = curl_exec($ch);
    27. $errno = curl_errno($ch);
    28. $errmsg = curl_error($ch);
    29. curl_close($ch);
    31. // ensure the request succeeded
    32. if ($errno != 0) {
    33. throw new Exception($errmsg, $errno);
    34. }
    36. // parse the response data
    37. $data = json_decode($response);
    39. // ensure response data was a valid JSON string
    40. if (!is_object($data)) {
    41. throw new Exception('Invalid response data');
    42. }
    44. // ensure the expected data is present
    45. if (!isset($data->status) || $data->status != 0) {
    46. throw new Exception('Invalid receipt');
    47. }
    49. // build the response array with the returned data
    50. return array(
    51. 'quantity' => $data->receipt->quantity,
    52. 'product_id' => $data->receipt->product_id,
    53. 'transaction_id' => $data->receipt->transaction_id,
    54. 'purchase_date' => $data->receipt->purchase_date,
    55. 'app_item_id' => $data->receipt->app_item_id,
    56. 'bid' => $data->receipt->bid,
    57. 'bvrs' => $data->receipt->bvrs
    58. );
    59. }
    63. $receipt = $_REQUEST['receipt'];
    64. $isSandbox = (bool)$_REQUEST['sandbox'];
    67. $info = getReceiptData($receipt, $isSandbox);
    68. echo '<pre>';
    69. print_r($info);
    70. echo '</pre>';
    Alles anzeigen
    _____________________________
    Alle Angaben ohne Gewähr :)

    On the internet you can be anything you want. It's strange that so many people choose to be stupid.


    Superbientem animus prosternet

  • Der Code ist nicht öffentlich, um die Sicherheit des Systems zu gewährleisten.
    'Whitelist' heißt in dem Fall einfach, dass nur die Anfragen für die eingetragenen Product-IDs beantwortet werden, um die Stabilität zu gewährleisten und den Server vor zu vielen Anfragen zu schützen.
    UrbanAirship hat ihren Code auch unter Verschluss und dort bezahlst du weitaus mehr, berechnet wird pro In-App Kauf.
    Gedacht ist mein Angebot wirklich für Entwickler ohne eigenen Server und ohne weitere Fähigkeiten im Bereich von PHP u. MySQL und natürlich spart man sich wertvolle Zeit, die Implementierung erfordert gerade mal eine Zeile mehr Code.
    Ich denke wirklich, dass das eine Bereicherung für die Community darstellt.

  • Verstehe mich nicht falsch. Ich will dich nicht kritisieren. Aber ich hätte wohl gleich so begonnen an deiner stelle :) Damit sich diese fragen erst gar nicht stellen. Ich nutze übrigens urbanairship nicht.
    _____________________________
    Alle Angaben ohne Gewähr :)

    On the internet you can be anything you want. It's strange that so many people choose to be stupid.


    Superbientem animus prosternet

  • Für mich stinkt das ein wenig nach "security by obscurity". Man muss davon ausgehen, dass ein Quellcode zu einem bestimmten Zeitpunkt immer ans Licht kommt, auf welchen Wegen auch immer. Deshalb sollte derselbe auch so gut sein, dass eine Umgehung desselben als nicht wahrscheinlich angesehen werden kann.
    Wenn du den Code nicht frei zugänglich machst, verlierst du auch den Spürsinn von vielen anderen, hochtalentieren Menschen, die ansonsten noch einmal über das ganze drüberkucken können und dir wertvolle Hinweise geben können.
    Soll keine vernichtende Kritik sein, sondern nur die Meinung eines Menschen, der die Vorteile von offener Software schätzt ;)

  • Nun ja, man könnte ja theoretisch den Apple-Server, der ja das iAP verifiziert, emulieren - ein einfacher Zertifikatsklau macht's möglich. Wer da nicht anständig prüft (was ich aber dem TE nicht zutraue), wird schnell Opfer von bösen Attacken.
    Wenn ein eigener Server betrieben wird, ist das schon eine Nummer komplexer - Apple's Server-Zertifikate haben eine recht hoch anzusiedelnde Vertrauenskette. Als normaler Endanwender bekommt man an SSL-Zertifikaten im bezahlbaren Bereich auch nur etwas, was durch einen CA-Hack auch wieder ausgehebelt werden kann.
    Letztenendes kann man es eh nicht verhindern. Solange es schön schwer ist, wird's kaum einer cracken.