En el módulo BillingService, ¿qué necesita modificarse para aumentar la seguridad?

Estoy trabajando en esto en este momento y mi enfoque, hasta ahora, es el siguiente:

1. Estoy utilizando el BillingReceiver, el servicio de facturación, PurchaseObserver y ResponseHandler.
2. He movido todas las Constantes en mi propia clase de Constantes y todas las clases anteriores están incluidas en mi propio paquete.
3. He eliminado la clase PurchaseDatabase y las partes integradas de ella en mi propia base de datos SQLite, DBAdapter y clases de acceso a datos.
4. He cambiado CatalogEntry en mi propio objeto de modelo y mi interfaz de usuario será muy diferente al ejemplo, por ejemplo, RadioButton grupo en lugar de Spinner para productos (sólo tengo 4).
5. Se dice en la clase de seguridad 'Para una implementación segura, todo este código debe implementarse en un servidor que se comunique con la aplicación'. Estoy "afortunado" de que mi aplicación tiene que ponerse en contacto con mi servidor de todos modos, así que voy a implementar estas medidas de seguridad en el servidor y voy a estar haciendo mi propia validación de la información de compra pasó al servidor. Estoy buscando para asegurar esta parte de las comunicaciones mediante SSL y ya necesito un nombre de usuario / contraseña anterior (hash y salado) que se almacena en mi servidor.
6. Estoy cortando cualquier otro código superfluo que no estoy usando, por ejemplo, la edición de carga.
7. Algunos de los métodos tienen 5 o 6 parámetros en su firma, por ejemplo, onPurchasestateChanged () – Estaba pensando en combinar estos en un solo objeto wrapper (pero aún no lo han hecho).
8. Lo estoy probando lentamente y completamente, para que entienda lo que está pasando y siguiendo las recomendaciones. Utilicé la muestra completa al principio para asegurarme de que funcionó y probé las respuestas estáticas. Entonces comencé a hacer mis propios cambios mientras seguía haciendo pruebas estáticas. Todavía estoy probando con respuestas estáticas y seguiré el flujo de mensajes para entender los intercambios en curso. Una vez que esté contento con esto, probaré con mis propias ID de producto e intentaré satisfacerme en los datos y en su seguridad.
9. He pensado que la cadena de developerPayload también podría ser firmado y encypted y cuando se devuelve a mi servidor, descifrado y comprobado la integridad.
10. Por último, voy a ofuscar el código con ProGuard y seguir algunos de los consejos para hacerlo que están disponibles en StackOverflow.

Espero que esto ayude.

No hay buenas noticias aquí: Necesitas cambiar cualquier cosa que puedas, además de usar Proguard. Esto incluye fusionar clases, dividirlas, mover ciertos métodos de un módulo a otro y en particular cifrar la información de compra almacenada en la base de datos, como sugiere la descripción de la clase PurchaseDatabase :

Debe utilizar un obfuscator antes de almacenar cualquier información en el almacenamiento persistente. El obfuscator debe utilizar una llave que sea específica al dispositivo y / o al usuario. De lo contrario, un atacante podría copiar una base de datos llena de compras válidas y distribuirla a otros.

La razón es que con herramientas como AntiLVL es muy fácil comparar su código descompilado (obfuscated!) A la muestra original y deducir de ella todo lo necesario para comprometerlo. Es imposible evitar completamente el agrietamiento, pero debe tratar de hacerlo lo más difícil posible.

Lo explican de la siguiente manera:

La aplicación de ejemplo de facturación en la aplicación está distribuida públicamente y puede ser descargada por cualquier persona, lo que significa que es relativamente fácil para un atacante realizar ingeniería inversa de la aplicación si utiliza el código de ejemplo exactamente como se publica. La aplicación de ejemplo está destinada a ser utilizada sólo como ejemplo. Si utiliza cualquier parte de la aplicación de ejemplo, debe modificarla antes de publicarla o liberarla como parte de una aplicación de producción.

En particular, los atacantes buscan puntos de entrada conocidos y puntos de salida en una aplicación, por lo que es importante que modifique estas partes de su código que son idénticas a la aplicación de ejemplo.

Esto significa que no use el código como se indica, cambie parte de él para que los hackers no puedan saber qué código usa.

Básicamente, no pienso que significaron el servicio de facturación sí mismo, pero la manera que usted lo utiliza en su uso.