A common scam in the world of Binance Smart Chain tokens is to launch a new token/contract that to the average person looks enticing, but when buyers purchase the tokens, they soon find that they are unable to sell them, and thus have lost their money.
I have heard it said that the developers of the token accomplish this by “blacklisting” all other wallets except their own from selling, but I am not sure how accurate (or how literal vs euphemistic) that explanation is.
Some people try to avoid this type of scam by making a test purchase/sale of a negligible amount to make sure the tokens is able to be sold.
My question is: are there particular functions/settings in the contract that could be scanned for and checked to identify whether or not a coin is this type of scam, instead of having to make a test purchase to find out?
Yes,
if owner set swapandliquify to false all the swaps could be locked. some people reported that scammers are using uniswapv2pair same way.
compiler version 0.5.17 has a lot of exploits/bugs too.
we at cointutu have an everyday challenge fighting against BSC scams.
Related
i'm new to solana development and working on a personal project using the anchor framework.
I fould some resources like solana escrow example and some youtube videos on solana PDA but not able to understand it completely. What i want to achive is:
Let's sat there are two players A & B, both pay same amount (ex: 0.01 SOL) to the contract, based on a condition or i invoke a function (not sure how it's done) one of the player is paid the amount (winner).
How can i achive this using the solana (Anchor), i would really appreciate some resource.
Thanks 🙂
Couple things going on here -
Think of a PDA, 'Program Derived Address', as an account address derived from the address of your program and whatever you salt it with, instead of a random address. This is useful for storing some data that you'd like to be able to grab later without having to remember the address, and rather just needing to remember what you salt this with. In your case, you'd likely want to create an account with a PDA salted with some kind of GameID or player (for instance, player A creates a game, and you generate a PDA with your program address and player A's pubkey).
PaulX's Escrow Program is a excellent resource, however he is not using Anchor framework and is instead implementing it natively, which sounds out of scope for what you're working on.
I think my dutch token auction program may be of some use for you, as far as PDA's go. Additionally, check out the Solana Cookbook, or more specifically the section on sending SOL, which is a method within the SystemProgram.
Solana/Anchor is awesome, but it's difficult without scouring the docs. The Solana Cookbook and the Anchor Discord Server are your friends!
I recently made a simple game where user can submit his/her high scores online.
It is very easy to hack the game by increasing high score by using software such as Cheat Engine. High score is stored in an integer. Should I store encrypted high score instead of an integer and decrypt it to show in the game?
I was wondering what are the best practices since I'm new in these things (hacking).
This question over at GameDev SE has what you're looking for:
https://gamedev.stackexchange.com/questions/4181/how-can-i-prevent-cheating-on-global-highscore-tables
Another discussion on SO about the topic:
Suggestions for (semi) securing high-scores in Flash/PHP game
The summary is that while there are many methods to make cheating difficult, eventually somebody with enough time in their hands will bypass your security measures. The only way to make leader boards hacker proof is to run the game logic on the server.
Best practise would probably be to send the scores over an encrypted connection to your server using some kind of authentication. This is non-trivial and you would likely need to refer to your platform for any crypto/security functionality it makes available.
It is the essence of security research to be able to share a secret over the ether (net). Essentially both parties need to know how to encode/decode the messages but the method for doing that has to be kept secret from the "Man in The Middle".
I'd refer to Tanenbaum's book on Internetworks or have a look at "Trusted Computing Module".
We were having a beer talk and have something to clear out.
Is the following conclusion correct:
When I put a facebook-like-button-box on my page, does facebook know
every time I'm on that page, even if i'm not logged in.
basically the same as google analytics
if this nis correct, it should be possible to sandbox, the like-button until someone will use it. Then facebook gets only informations when the user actively confirms that.
cheers endo
No, they can't directly track you if you are not logged in and you view an external "like" button. They can, however, set a tracking cookie that identifies you when you sign in, which would allow them to match the tracking data in the current session to you.
One of Facebook's primary revenue streams comes from the analysis and sale of market trend information. They can analyse the likes and comment keywords of certain user clusters (e.g. middle-aged American females, teenagers in college, etc) and use these to produce statistics about market patterns and trends. They can also use keyword analysis to tell a company how many people are talking about something, e.g. "how many people have mentioned my latest blockbuster film?"
You could simply move the image and JavaScript code away from the Facebook servers and host it locally to avoid them from tracking your users.
In pre-emption of the "FACEBOOK = EVIL" arguments:
In the end, though, is it really a big issue? Some people see Facebook as this massive life-infringing uncaring supercorporation, but in reality they're just making a buck through completely anonymous statistics. No human being (or sentient robot) views your preferences, browser tracking data, or personal information. Everything is anonymised and turned into a bunch of numbers relating to a group. Sure, they could screw everyone over and be evil, but why bother when you already make that much money legitimately?
I've got a rather large database of location addresses (500k+) from around the world. Though lots of the address are duplicates or near duplicates.
Whenever a new address is entered, I check to see if it is in the database already, and if so, i take the already existing lat/long and apply it to the new entry.
The reason I don't link to a separate table is because the addresses are not used as a group to search on, and their are often enough differences in the address that i want to keep them distinct.
If I have a complete match on the address, I apply that lat/long. If not, I go to city level and apply that, if I can't get a match there, I have a separate process to run.
Now that you have the extensive background, the problem. Occasionally I end up with a lat/long that is far outside of the normal acceptable range of error. However, strangely, it is normally just one or two of these lat/longs that fall outside the range, while the rest of the data exists in the database with the correct city name.
How would you recommend cleaning up the data. I've got the geonames database, so theoretically i have the correct data. What i'm struggling with is what is the routine you would run to get this done.
If someone could point me in the direction of some (low level) data scrubbing direction, that would be great.
This is an old question, but true principles never die, right?
I work in the address verification industry for a company called SmartyStreets. When you have a large list of addresses and need them "cleaned up", polished to official standards, and then will rely on it for any aspect of your operations, you best look into CASS-Certified software (US only; countries vary widely, and many don't offer such a service officially).
The USPS licenses CASS-Certified vendors to "scrub" or "clean up" (meaning: standardize and verify) address data. I would suggest that you look into a service such as SmartyStreets' LiveAddress to verify addresses or process a list all at once. There are other options, but I think this is the most flexible and affordable for you. You can scrub your initial list then use the API to validate new addresses as you receive them.
Update: I see you're using JSON for various things (I love JSON, by the way, it's so easy to use). There aren't many providers of the services you need which offer it, but SmartyStreets does. Further, you'll be able to educate yourself on the topic of address validation by reading some of the resources/articles on that site.
I wish to implement my software on a shareware basis, so that the user is
given a maximum trial period of (say) 30 days with which to try out the software. On purchase I intend the user to be given a randomly-generated key, which when entered
enables the software again.
I've never been down this route before, so any advice or feedback or pointers to 'standard' ways of how this is done would be much appreciated.
I do not anticipate users cheating by changing the system date or anything like that, though this is probably worth considering. Apologies if this topic has appeared before.
With regards to a random-generated key, how will you verify a key is legit or if a key is bogus if it is actually random? Have a look at the article "Implementing a Partial Serial Number Verification System" as it is quite good and is easy to implement in any language.
With regards to time trials, as basic solution would be to compare your main executable files creation time to the current system time and act on the difference. This assumes your installer sets the files creation time to the time of install as opposed to preserving the time you compiled it! :)
Also watch out for the time changing radically, if the current date is magically less than the install date and such.
One way to get around this type of datelock is to change your date before you install to be years in the future. So you should check that the date today is not less that the install date.
If your software is really useful, you'll certainly find cracked copies on P2P before you see your first order. This will happen no matter how sophisticated is the license enforcement code you are going to implement.
That said, just store first-run date somewhere (may be registry, if on Windows) and after 30 days refuse to start, or just open a reminder window.
Don't worry about cheaters, they'll find a way around your restrictions no matter what. Worry about your honest customers and try hard not to make their life harder.
Eric Sink has written more about this here (section 4).
On the first start, you can store the actual date somewhere.
Each following start, you look for the stored date, if it exist you read it an if it is more than 30 days after the first start, you stop the program.
Please see this library.
Description:
Convert any application into time-limited shareware. Generate serial numbers to register it. A function library offering a flexible locking system with solid encryption. Easy to implement. Support for VB, C++, Delphi, other languages.