Hackeando Casinos en Blockchain

¿Cómo ganarle a un casino?

Suena complicado, no? Más bien suena como una de esas cosas que cualquier persona normal diría que es imposible.

Hace algunas semanas se me dio por recopilar, y analizar, lo más posible cada pizca de información disponible en una “sala de azar”.

Como podrán imaginarse, en verdad no me fue como esperaba, pero creo que la experiencia valió la pena, quizás, debería de haber frenado cuando iba ganando.

Aunque quizás sea imposible definir cuando uno “va ganando” con precisión… ganando $1 dólar? ganando $100? miles o decenas de miles?

En fin, la publicación se dividió en varias secciones, a fin de conservar el orden de la narración. Espero que a alguien le sirva de algo!


Casinos en Blockchain

Quizás, una de las principales razones que me lleva a mirar con cariño e interés estos sistemas de apuestas y casinos de bitcoin, es el hecho de que al día de hoy carecen de muchas de las regulaciones aplicables a casinos convencionales y casinos online.

Por el mismo hecho uno podría esperar que el dichoso “azar” no sea el mismo que los que por lo general son aplicados en casinos regulados, uno podría esperar que no usen verdaderos generadores de azar por hardware, sino más bien funciones generadas por la aplicación.

Más allá del azar, la verdad es que armar un casino en linea es ahora más fácil que nunca. Las regulaciones que aún no caen en lugar y las monedas digitales como BTC o ETH hacen posible rápidas dinámicas que no eran posibles hace una década.

El dinero se mueve cada vez más rápido, de las monedas pasamos al papel, del papel a los bancos, dando lugar a fenómenos como visa o american express.

Haciendo que el dinero ya se no pueda agarrar… las monedas del 2018 llevan al nuevo dinero un paso más allá. Invisible, incorpóreo y de valor indefinido y movedizo.


Aviso legal y personal

Dado que no quiero hacerle perder horas a nadie, así que comencemos por aclarar, que la semana pasada perdí $40 mil dolares. Así es. Aún duele un poco.

Se podría decir que la gran mayoría del código publicado en las próximas páginas posee riesgos considerables, y sin lugar a dudas, podría generar perdidas económicas considerables.

Más allá de eso, en verdad creo que algunas secciones del mismo son valiosas o pueden servir como información educacional.

La verdad es que fueron más bien unos 6 BTC, los cuales, para el día rondaban los 40 mil dolares. Primero 3 ganados, luego 3 perdidos, 2 ganados, y 3 perdidos. Luego decidí frenar

Comenzando desde el principio, hace algunas semanas, después de una conversación con desconocidos usuarios de un foro, decidí mirar un poco más de cerca diversos casinos online para realizar apuestas con BTC y otras monedas digitales.

¿Cómo los perdí? En verdad no se que fue lo que me llevó a perder así, dado que había comenzado bien. Para describir el proceso en lineas generales:

Mirando en la db, esperaba que se genere un volumen específico de probabilidad favorable, o por decirlo más claro, esperaba que hubiera un volumen considerable de valores inferiores a 2 en las rondas previas, de manera que el equilibrio de la aplicación buscara comenzar, con valores superiores.

Comenzaba con 1,000 fichas y en caso de perder, 2,000 al próximo, en caso de perder, duplicaba las fichas en la próxima ronda.

Poderes de dos. Genial, creo que ya la conocen, de esa manera, duplicando al perder, con probabilidades de ganar del 49.5%  en cada ronda uno se puede pasar en promedio, algunas horas sin perder.

El problema por obvio que sea, sucede alcanzamos el máximo, de lo que podemos pugnar. El máximo ahora ronda cerca de los 225, lo que equivale a: 33.554.432 unidades. Por lo que llevado a la mesa, equivale a 25 rondas perdidas seguidas.

 


Mecanicas del Casino

Volvamos al casino, hace unas semanas, decidí cargar unos 0,127 BTC en uno de esos nuevos “casinos”, un desafío simple, donde un número comienza a subir desde el 1 hacia el 10,000 y puede frenar en cualquier posición.

Los usuarios ponen el dinero previo a comenzar la ronda, si el número elegido es menor o igual al número final, ganan. Vale la pena hacer algunas observaciones generales sobre la lógica de la aplicación:

  • La probabilidad de ganar decrece cuando la variable de salida crece.
  • Más grande sea la variable de salida elegido por el usuario,
    • más grande el riesgo de perder
    • y más grande la posible ganancia.
  • Recudiendo la variable de salida:
    • suben las chances de ganar,
    • pero del mismo modo disminuyen las posibles ganancias.

De esa forma, si bien podemos ganar el 99% de las veces con un valor de salida cerca del mínimo, al perder una sola vez en 100 rondas, haría que solo esa perdida, superen a las ganancias acumuladas.

Habiendo mencionado eso, anclando la variable de salida en X2, se puede reducir o anular una buena porción de probabilidades inecesarias para la simplicidad un primer análisis .

Con la variable anclada en X2, la lógica queda recudida a poner fichas, siempre que creamos que el número será mayor o igual a 2. Si el número sale menor a 2, hemos perdido las fichas, si sale mayor, las hemos duplicado.

Si desean ver más sobre como funciona, pueden probarlo desde acá.

Bien, habiendo explicado en lineas generales la lógica de la aplicación, paso a hablar sobre lo que hice y probé:


Tecnologías, y aplicaciones usadas

A fines de no olvidar nada, voy a comenzar por anunciar algunas de las aplicaciones, librerías y ideas que fueron aplicadas en forma de un indice:

  1. Selenium
  2. Facebook/php-webdriver
  3. MariaDB
  4. Keras
  5. TensorFlow
  6. Pandas
  7. Numpy
  8. Sklearn
  9. Redes neuronales
  10. Unidades LSTM
  11. XGB
  12. Orange
  13. Regresiones lineales
  14. Naive Bayes
  15. Nash equilibria
  16. Progración en R y diversas yerbas más.

A lo largo de las próximas páginas, espero poder cubrir y explicar el mayor número posible de las pruebas realizadas. Por lo que de ahora en más la comprensión se hace más difícil al incorporar diversas lineas de código.

Recolección de información

Clonando la información de la web. A fines de comenzar a realizar un análisis adecuado, es necesario el mayor volumen posible de información previa.

Usando PHP, Java, Selenium y los webdrivers desarrollados por Facebook, y aprovechando la información pública de cada round publicada acá. Armé un guion para explorar cada una de las rondas y sacar la información.

Acá lo podemos ver funcionar.

  • Valor.
  • Número de round.
  • Clasificación (si fue menor o mayor a 2)
  • Fecha y hora.
  • Dinero en la mesa.
  • Promedio de dinero por usuario.
  • Número de usuarios.
  • Número de ganadores.
  • Número de perdedores.

He aquí una copia del código creado para recopilar la información. La aplicación fue diseñada para almacenar la información en MariaDB por lo que van a precisar una copia de la base si quieren usarla, acá la misma.

Espero que el código les sea agradable para leer, creo que quedó bien organizado. Bien, corriendo curl.php (php -f curl.php) podemos ver como la aplicación comienza a escarbar cada una de las rondas.


Curl.php recompila la información de cada ronda, y las va enviado hacia Mariadb. El guión corre para siempre, a excepción de que sea cancelado a la fuerza, de ser así, al arrancar, resume desde donde debería sin problemas.

Como podemos apreciar, hace uso de Selenium y Facebook Webdrivers para funcionar, al igual que es necesario una conexión a la db para almacenar la información.

Para quienes quieran reproducir mis acciones, descargar una replica de la db ya creada y poner a correr curl.php para sincronizar la db.

Se pueden ver algunas lineas // las cuales pueden ser removidas y añadidas, para modificar la información que el guion busca y almacena.

Espero que comprendan que el código no fue creado de ninguna manera para uso más que personal, por lo que verán que he decidido ahorrarme algunos condicionales, if, else algunas cosas más.

Próxima página: análisis de la información conseguida.

Análisis de la información

Analicé la información en búsqueda de ordenes, probabilidades favorables vinculadas a la hora, probabilidades en base a la información previa, diversas, en verdad muchas funciones calculando el peso de los números, y los valores de las 1,000, 10 mil o incluso 100 mil rondas previas. Logré ganar algunas veces, al final me fui perdiendo. Por ahora.


Mariadb y diversas queries

Pasemos ahora a analizar algunas de las queries hechas a la db, y la información que conseguimos.

Previo a comenzar, asumimos que luckmap.zip fue descargado, descomprimido y cargado en la Mariadb, y que se corrio curl.php a fin de sincronizar la información con la web.

Veamos algunas queries que podemos hacer:

Como podrán ver, analicé diversas formas de abordar el problema. Por razones de disponibilidad horaria, no me fue posible crear modelos que correspondan o prueben cada una de las queries creadas, por lo que me focalicé en probar algunos modelos solo cuando las queries parecían revelar alguna información considerable.

La próxima página incluye diversos guiones armados en PHP, creados para ganarle a la aplicación y generar cada vez más dinero!

Suena demasiado bien, no? Debo avisar, que en verdad, mi experiencia fueron puras perdidas, no logré hacer andar de manera favorable, ninguno de los guiones acá publicados.

Sin embargo, y más allá de mi perdida de dinero, en verdad creo que algunos de ellos podrían generar ganancias, dadas las condiciones necesarias. Pasaré a hacer un análisis de cada uno de ellos y diversas observaciones relacionadas.

Creo que es posible ganar, más allá de que no haya logrado aún hacerlo.


Información aplicada

Pasemos ahora a analizar algunos de los giones PHP creados para operar con la web y procurar ganar dinero sin necesidad de un operador.

Una vez que disponía de un mecanismo para recompilar la información en la db corriendo, y diversas queries en busqueda de alguna clase de orden, decidí crear algunos guiones que usaran la información para procurar, ganar.

Al día de la fecha fueron unos 7 guiones, los cuales paso a explicar como funcionan:

  1. challenger.php
  2. challenger2.php
  3. alpha.php
  4. alpha2.php
  5. android.php
  6. won.php
  7. won2.php

src: challenger.php

Observaciones: si mal no recuerdo, challenger.php fue el primer guión armado. Las primeras lineas no hacen más que definir algunas variables incluyendo, la posición inicial, el nombre de usuario, el password del mismo.

El guión solo coloca fichas en las rondas finalizadas en 1, 3, 7 y 9. Al perder, duplica la posición previa.

La selección de números (1, 3, 7 y 9) fue hecha a fin de procurar (en vano) disipar o crear un espacio a fin de evadir la perdida con largas malas rachas, reduciéndolas a fin de no perder en esas secuencias.

Es claro que no consideré que si solo se ponían fichas en esas rondas, se crearían nuevas malas rachas o lineas.


src: challenger2.php

Observaciones: Challenger2.php es, sin lugar a dudas, una versión modificada de Challenger. Era obvio, no?

La verdad es que no recuerdo que es lo que hace, dado que han pasado algunas semanas de que la armé y usé. Por lo que se puede ver en el código, las lineas originales de Challenger que especifican solo operar en las rondas finalizadas en 1, 3, 7 y 9 fueron anuladas //.

Por lo que se puede ver, no hace uso de ninguna condición horaria o de probabilidad, dado que no realiza selecciones en la db.

De modo que creería que si el guión se corriera como se viene, pondría fichas en cada uno de los rounds.

Al igual que los demás guiones challenger2.php salva información en la base luckmap db, performance. La cual se puede usar para analizar la performance del código.

Sin más preludio, he aquí el código:


src: alpha.php

Observaciones: Alpha es el primer guión que realiza queries a la mariadb, para sacar información previo a poner fichas.

En las primeras lineas de alpha.php se realiza una conexión a la base, y se agrupan las rondas y sus valores en grupos de 60 segundos.

Calculando así los valores mayores a dos y menores a dos en cada min. De esa forma, calcula la diferencia y ve que min. fueron favorables y cuales no.

La información se refresca a medida que alpha funciona, y solo pone fichas cuando las probabilidades favorecen a la hora en curso.

El guión no hace uso de progresiones de ninguna clase. A fin de ganar, dispone solo de la probabilidad horaria como única arma, asumiendo que el seleccionará más valores superiores que inferiores y considerando a la diferencia de los mismos como ganancias.

Original, no?


src: alpha2.php

Observaciones: He aquí una versión modificada y refinada de Alpha. El guión busca poner fichas, solo cuando las probabilidades parecen favorables.

La segunda versión usa la información de las 18 horas previas a fin de calcular las probabilidades favorables.

El guión no hace uso de progresiones de ninguna clase. A fin de ganar, dispone solo de la probabilidad horaria como única arma, asumiendo que el seleccionará más valores superiores que inferiores y considerando a la diferencia de los mismos como ganancias.

En lo personal, creo que alpha2.php es una gran idea, y solo requeriría de alguna clase de mecanismo que haga posible “predecidivinar”, cuales de los min. favorables, deben comenzar a buscar el equilibrio, quizás eso pueda ser llevado a cabo, por medio del análisis de las 30 a 60 rondas previas.

De esa manera sería posible evadir las perdidas generadas cuando la balanza deba acomodarse para esos rangos horarios. Aquí el código:


src: android.php

Observaciones: comienza por espera a que el round finalice en 1, 4 o 5, luego, comienza, enviando 4 fichas (posición mínima definida), en caso de perder duplica, poniendo ahora 8 fichas, en caso de perder, vuelve una vez más a duplicar, siendo 16.

Una vez que gana, comienza de nuevo por la posición inicial (definida en 4).

Una vez que las ganancias alcanzan el máximo definido en $params->salida (de 100 unidades), el guión espera a la medianoche del próximo día para comenzar de nuevo, y ganar sus 100 fichas diarias.

Del mismo modo, el guión se suspende y espera a la próxima medianoche en caso de perder más de 8 veces seguidas.

Vale la pena mencionar que la medianoche que menciono, corresponde a la medianoche definida por la aplicación en UTC. La razón de realizar operaciones a la medianoche UTC, concuerda probabilidades favorables, analizadas y simuladas en la base.