Hello,

Oops.

Seems that while checking why my cashed out coins did not appear on my balance (in fact it was cashed out but never showed in the Android app, because the wallet did not find any peers but showed to be fully synchronized...), I accidentally "hacked" the script that handles the cashouts... (not really, but I accidentally made it pay me more than I wanted/deserved...)

https://prohashing.com/explorer/Bellacoin/883c18f0740ad589463d6e61b0ab901244228fcb6d5a27498055a3f9244137c1/

Feeling guilty like a little boy who accidentally broke the sandcastle built by his peers, I decided to return 98% of that 10000 BELA back to your announced Donations address:

https://prohashing.com/explorer/Bellacoin/d34e16a2f35a20993824f519973d4f02631172c916b6246039e8bf60bcce300b/

Hope you are fine that I keep 200 BELA for the hassles I had.

I won't describe in more detail what I did (if you want details, please drop me a private message) but in general check the input parameters of your script better for consistency. [Against a truly malicious attacker, certificate pinning would also help.]

It might also improve the user experience if the included wallet was of the "light" kind (only downloads transactions for its own address) instead of "full" (downloads all blocks), and especially if it showed an error in case it was not able to sync (instead of just showing 0 BELA).

[I used the Windows cliend linked in this thread - which took some hours to sync - to refund the amount, that's why it took so long...]

Regards, and good luck with your project anyway,

mihi

When and how often do you process payments? I have not found anything about it in the app...

my IRC name was mihi, but I dropped it again.


Reason: I don't like to win any more...


Short review: As a person who played IRC gambling games in 2003 already (anybody here remember yodelbank and their video poker bot on InvisibleIRC?), I have to admit that the bot is quite well done. The output uses color sensibly (not too distractive, but making the output readable and emphasizing the most important parts), and the commands are easy and simple to use. Negative point: it seems to be impossible to update or cancel a bet in Roulette, there is no provable fair (would require some work for dice, but should be easy to add for Roulette), and deposits/withdrawals are manual (require to chat to an op in the channel instead of via the bot). But all in all quite a nice experience.

99.99998% certain this is a scam.

- Written with Visual Basic.NET (so ILSpy is your friend with reversing)
- Crashes at shutdown (after telling me that all settings are saved)
- The withdraw button shows a nice progress bar and then reduces your balance by the withdrawal amount (exactly same as when you lose it with gaming), but does not withdraw anything...

Apart from that it seems quite functional (deposit is implemented, email is implemented, and the faucet and game seem to be "fair").

But...

- Email is implemented by logging into recipient gmail account and sending email from there (password for email account is hardcoded in binary, so in case you want to read all those emails you can...)
- User data, including balance is kept in publicly reachable MySQL database (database password is hardcoded in binary)
- Database stores plaintext passwords of the users (!)

So: Stay away! (I'll trash the VM I've installed it on now )

This comment attracted my curiosity and I had a quick look at your game (my Game GUID is 1A2C710F-B024-4E07-A98C-75269F3C786D and I'm not interested in your Bitcoins, so feel free to block that user if you want to ).

Games like these are hard (or even impossible) to make hacker-proof (if you have solved all levels once, you can probably quickly solve them again; so can a computer), but you can at least make it a lot harder than currently (if you wireshark the traffic of completing 2 levels you basically know how to complete all 40 without requiring any reversing of the game code at all...).

A few hints, sorted by effectiveness (top ones are easy to implement and mildly effective, bottom ones harder to implement but more effective):

• Use HTTPS, if your ISP provides it. This one is quite easy to get (certificates are damn cheap or even free in case of LetsEncrypt) and an attacker will at least have to mess with a proxy to be able to still sniff the traffic. I don't know if Unity supports certificate pinning, but if it does, it gets even harder to bypass.
• Validate your HTTP headers (like User-Agent). This won't stop any determined skilled attacker, but may provide enough hassles to let a typical script kiddie give up, as request cannot be easily replayed in a browser.
  
• Add some dynamic authentication into your game. For example, take the game GUID together with the game data, add some long constant string (hard coded in the game) and build a SHA hash of them and add to the saveGameData request. Don't forget to verify it on server side. This is not infallible, but it will at least prevent replaying (if you have solved all levels once, you cannot replay the requests from another computer and/or with another game ID to instantly solve all levels too). Note that the effectiveness of this method depends on how easy it is to reverse the code of your program (no experience with Unity here, but I guess there are obfuscators for Unity too that make it harder).
  
• Add some proof of work. Currently the game data just contains 1: true, 2: true, etc. Replace the true by a string depending on gameplay (e. g. a matrix where you code where the player placed an arrow or a bomb or anything) and verify the strings server side (just hard-code the correct solution(s) on the server). That prevents an attacker who has reversed the code (see point above) to instantly solve all levels, but won't help against an attacker who has already solved all levels at least once.
  
• As I did not get to the payout process, I cannot say if you already do it, but consider including a captcha in the payout process (I'd also include one when initially setting up an account, but it depends on acceptance by the users). That way, even if a skilled attacker is able to complete hundreds of games automatically, he will still have to enter many Captchas to be able to pay out (assuming he can get 0.001 BTC per game easily, it would still require 300 Capchas to get 0.3 BTC paid out).
  
• Probably most effective: Add some rate limiting. Each IP will host probably less than 100 unique players on any given day (if your geoip provider provides information whether an IP is shared by multiple parties like on some mobile networks, use that to adjust these measures). Each level takes some time to play through (for watching the intro, watching the animation of the level, and watching the ad), so measure this time, subtract a few seconds for safety and validate the achievements against the elapsed time (i. e. if a user jumps from 2 solved levels to 40 solved levels in less than a minute, he must be cheating and probably should be blocked). Also, limit the number of possible payouts per IP per day (lower than the number of unique players per IP).
  

Hope this helps and good luck,


mihi