[discussion]Technical notes on how to defeat(*) oredetect

sofar
Developer
Posts: 2146
Joined: Fri Jan 16, 2015 07:31
GitHub: sofar
IRC: sofar
In-game: sofar

Re: [discussion]Technical notes on how to defeat(*) oredetec

by sofar » Post

Xudo wrote:What do you think about proposal of Sokomine?
Specifically, I think you mean this part:
Sokomine wrote:My idea would be to leave normal ore generation as it is (coal, iron, copper, tin, even gold), but not to generate mese crystals, mese blocks, diamonds etc. at mapgen time. Those rare ores would be generated randomly when the player diggs stone like already suggested by others. If a stone is digged and the function returns "ore found", the stone behind the just digged stone turns into the ore so that it looks to the player as if he's just revealed that ore block. Other stoneblocks around could be turned into the desired ore at this time as well, simulating a cluster-like distribution. Making the ore emit some light and/or sound could help human players in times of lag. Digging strategies could be rewarded by not "jumping" over corridors and placing the ores closer together, with only stone and never air between two blocks
This is a simpler method/variant where instead of "predetermined" ore spots that become exposed, you're modifying the map after every map update and inserting ores according to a specific 3d noise (I assume). Essentially you forego the need for a map, but you would have to do some lenghty scanning for node exposures. E.g. falling gravel, explosions also would expose new blocks and trigger this mechanism.

There's also the issue of how to handle natural caves - already exposed surfaces could change mysteriously from stone to ore if not properly implemented.

It sounds a bit simpler but player wise relatively the same. Using the mechanism only for rare ores is probably a big efficiency gain as well.

I could foresee this mechanism include per-player modifiers as well - further limiting players ability to collect unreasonable amounts of rare ores in short times, which may be a wanted bonus.

Xudo
Member
Posts: 162
Joined: Wed Nov 09, 2016 16:43
GitHub: akryukov92
In-game: Xudo

Re: [discussion]Technical notes on how to defeat(*) oredetec

by Xudo » Post

sofar wrote:This is a simpler method/variant where instead of "predetermined" ore spots that become exposed, you're modifying the map after every map update and inserting ores according to a specific 3d noise (I assume).
I don't like the idea of running map check and modification after every map update.
It should be triggered on direct players action. Not every map update is a result of direct actions. I consider falling gravel, flowing water, growing trees and explosions (all ABMs) as indirect actions.
Placement of special block, use of special tool are direct actions. Digging is a direct action too, but I believe there is no way at this moment to extend default digging with lua handler.

Sokomine
Member
Posts: 4276
Joined: Sun Sep 09, 2012 17:31
GitHub: Sokomine
IRC: Sokomine
In-game: Sokomine

Re: [discussion]Technical notes on how to defeat(*) oredetec

by Sokomine » Post

sofar wrote: This is a simpler method/variant where instead of "predetermined" ore spots that become exposed, you're modifying the map after every map update and inserting ores according to a specific 3d noise (I assume). Essentially you forego the need for a map, but you would have to do some lenghty scanning for node exposures. E.g. falling gravel, explosions also would expose new blocks and trigger this mechanism.
Not exactly. 3d noise isn't needed. A simple, not necessarily deterministic random function will do the job. The common ores are there from the beginning and need no special effort. If the player diggs a stone (which happens frequently), a random value has to be calculated. Up until that it's just like "random drop from stone". It gets more complicated when the player actually finds some valuable ore. The random-drop-version would just give the player the ore and be done. My idea gives the player cobble - but also does set some ore blocks in a cluster around the position where the "find" happened. The next node the player's pick will point at will most likely be the rare ore, with more of it hidden nearby. The ore cluster ought not jump over air nodes. The ore cluster is a fake - it wasn't there until the player got lucky with that stone block. As rare ores are by definition rare, it doesn't matter too much if the function is a bit more complex. Lag on servers when digging happens, and that has to be taken into account. The mapchange due to the ores appearing might not be fast enough for the client.
sofar wrote: There's also the issue of how to handle natural caves - already exposed surfaces could change mysteriously from stone to ore if not properly implemented.
Already exposed surfaces may change with my idea as well, yes. Could be sold to the player as "must have overlooked it". The effect is limited to a small area around the last dig. As normal ores stay the way they are, there's no need to handle cave walls specially. Adding a bit more ores might help to make them look intresting. There's no shortage of ore mods. Some have very nice textures.
sofoar wrote: It sounds a bit simpler but player wise relatively the same. Using the mechanism only for rare ores is probably a big efficiency gain as well.
It ought to look and feel similar to normal ore distribution to the player.
sofar wrote: I could foresee this mechanism include per-player modifiers as well - further limiting players ability to collect unreasonable amounts of rare ores in short times, which may be a wanted bonus.
As the triggering of the ore cluster generation is random there ought to be no such need for a player modifier. Subgames that add experience and skill might wish to make ore finds more likely with higher skill, but that should not be exaggerated. Making ore creation depend on a minimum skill might work in subgames. Changing the chances more would annoy players too much at the start and be too strong in the end.
A list of my mods can be found here.

wilkgr76
Member
Posts: 832
Joined: Wed Feb 18, 2015 02:44
GitHub: wilkgr76

Re: [discussion]Technical notes on how to defeat(*) oredetec

by wilkgr76 » Post

I accidentally posted this in the wrong thread beforehand:

This is a slightly more complicated version, and may use more data, but this solves it for the most part. This is does modify the way the data is sent however.
  • The server only tells the client the csm_group of nodes outside a particular radius - this allows ambiance mods to still continue working
  • The client can use a "default" texture for blocks outside this radius. This does, however, mean that ores will appear suddenly.
  • I propose a 3-block radius - this means only about 392 nodes (including where the player is) are exposed to the client, and by extension, the client modding api.
This does modify the way data is sent to the server, so this could theoretically be implemented in the client until the next major breaking protocol change.
N/A

sofar
Developer
Posts: 2146
Joined: Fri Jan 16, 2015 07:31
GitHub: sofar
IRC: sofar
In-game: sofar

Re: [discussion]Technical notes on how to defeat(*) oredetec

by sofar » Post

wilkgr76 wrote:I accidentally posted this in the wrong thread beforehand:

This is a slightly more complicated version, and may use more data, but this solves it for the most part. This is does modify the way the data is sent however.
  • The server only tells the client the csm_group of nodes outside a particular radius - this allows ambiance mods to still continue working
  • The client can use a "default" texture for blocks outside this radius. This does, however, mean that ores will appear suddenly.
  • I propose a 3-block radius - this means only about 392 nodes (including where the player is) are exposed to the client, and by extension, the client modding api.
This does modify the way data is sent to the server, so this could theoretically be implemented in the client until the next major breaking protocol change.
Csm oredetect doesn't bother scanning this far, so this doesn't defeat oredetect I think, it would remain fully functional.

The idea of limiting CSM in this(or some) way isn't bad, it's probably useful actually. However, it is outside of the scope of the discussion.

User avatar
cd2
Member
Posts: 562
Joined: Mon Jun 01, 2015 06:30
GitHub: cdqwertz
In-game: cd cd2
Location: Linux
Contact:

Re: [discussion]Technical notes on how to defeat(*) oredetec

by cd2 » Post

I think that "defeating" oredetect just does not make much sense. When the minetest community decides to add new features to the client side modding API, more client side mods and cheats will be created. There are already some examples for other "cheats":
Note: I do not want to blame any of the developers of these mods, they most likely created these mods in the hope that they will be useful to someone (and they are imo).

These mods give players an advantage over other players (in most environments) and can be therefore considered cheats. When we "defeat" oredetect, other cheats will still exist, players will use them. A possible solution for this problem would be to send a signature of every mod to the server (a hash of the source code of the mod) and the server can then decide if the client is allowed to connect based on these signatures (the server has a list of allowed mod signatures). If a developer updates a mod, the server could automatically fetch the source code and add a hash of it to the list after an admin approved the changes. This system is not 100% secure, because it could be disabled in the c++ code of minetest itself (there might be some way to prevent this), but it will keep more people from cheating.

sofar
Developer
Posts: 2146
Joined: Fri Jan 16, 2015 07:31
GitHub: sofar
IRC: sofar
In-game: sofar

Re: [discussion]Technical notes on how to defeat(*) oredetec

by sofar » Post

cd2 wrote:I think that ...
This is outside the scope of the discussion of this topic, because it clearly falls in the "modify XXX to prevent CSM" category. Please stay on topic, thanks.

wilkgr76
Member
Posts: 832
Joined: Wed Feb 18, 2015 02:44
GitHub: wilkgr76

Re: [discussion]Technical notes on how to defeat(*) oredetec

by wilkgr76 » Post

sofar wrote:Csm oredetect doesn't bother scanning this far

Code: Select all

.oredetect radius 100
Or you can set it to 1000...
Image

(NB: No, I don't use it on servers. I really only play on servers where I moderate, and I therefore have no need for oredetect, apart from detecting "moderator-only" blocks)
Attachments
screenshot_20170728_083209.png
screenshot_20170728_083209.png (273.5 KiB) Viewed 988 times
N/A

sofar
Developer
Posts: 2146
Joined: Fri Jan 16, 2015 07:31
GitHub: sofar
IRC: sofar
In-game: sofar

Re: [discussion]Technical notes on how to defeat(*) oredetec

by sofar » Post

wilkgr76 wrote:
sofar wrote:Csm oredetect doesn't bother scanning this far

Code: Select all

.oredetect radius 100
Or you can set it to 1000...
(NB: No, I don't use it on servers. I really only play on servers where I moderate, and I therefore have no need for oredetect, apart from detecting "moderator-only" blocks)
That will completely make your game unplayable, as one scan would have to scan 4.19×10^9 blocks (yes, that's 4.19 billion nodes).

but, this discussion is offtopic since this thread isn't about removing/restricting CSM, but defeating oredetect by other means.

wilkgr76
Member
Posts: 832
Joined: Wed Feb 18, 2015 02:44
GitHub: wilkgr76

Re: [discussion]Technical notes on how to defeat(*) oredetec

by wilkgr76 » Post

Of course. My apologies.
N/A

User avatar
cd2
Member
Posts: 562
Joined: Mon Jun 01, 2015 06:30
GitHub: cdqwertz
In-game: cd cd2
Location: Linux
Contact:

Re: [discussion]Technical notes on how to defeat(*) oredetec

by cd2 » Post

sofar wrote:
cd2 wrote:I think that ...
This is outside the scope of the discussion of this topic, because
I do not think so since the discussion is named "Technical notes on how to defeat(*) oredetect" the post (imo) clearly is a technical note.
sofar wrote:it clearly falls in the "modify XXX to prevent CSM" category.
No, it does not. The idea is not to prevent CSM, but restrict the usage of some mods (e.g. oredetect) without changing the gameplay/design of the game. Since server owners can also decide to disable the feature or customize the whitelist/blacklist for mods (the list containing the hashes), it can defeat oredetect, but it also can defeat other cheats.
sofar wrote:Please stay on topic, thanks.

bell07
Member
Posts: 604
Joined: Sun Sep 04, 2016 15:15
GitHub: bell07

Re: [discussion]Technical notes on how to defeat(*) oredetec

by bell07 » Post

The on-topic idea: Disable all ores and use Gravelsieve or ores-enabled lava cooling like in unternull. You see it is a gameplay related decision how the ores should be handled. So this question should be diskussed by subgame designers for each subgame separately.

The other "off topic" issue should be solved at the first: Get the accustomed and loved "old-style" gameplay back with searching and mining the ores in the caves. A new restriction is required and the server owner should be able to decide which functionality can be used or not.
An other similar issue already solved is the showing minimap. Of course it is possible allways to display them but the client is implemented in the way to do it if the player have the permission only. I think this is the right way: A new permission "oredetect" or "xray_eyes" and the client (or the CSM-mod byself) should respect the permission setting. So

I see two ways at the time:
1: to implement the restriction in oredetect mod byself to respect the player permission. (like other mods respects the protected nodes for example).
2: As proposed before to implement the permission check is in the client and restrict the minetest.get node() result ("ignore" if no line_of_sight to the client player).
On creative servers the oredetect permission can be enabled by default, on survival only if it does match to the gameplay idea.

User avatar
TumeniNodes
Member
Posts: 2941
Joined: Fri Feb 26, 2016 19:49
GitHub: TumeniNodes
IRC: tumeninodes
In-game: TumeniNodes
Location: in the dark recesses of the mind
Contact:

Re: [discussion]Technical notes on how to defeat(*) oredetec

by TumeniNodes » Post

I'm wondering if this discussion has helped toward a solution in any way yet?

Given the guidelines it is a fairly difficult matter to resolve as there are a number of methods but, not sure which seems the most viable.
The other difficult aspect is, the fact that no matter the solution, someone will work on a means to bypass it. As is the cat and mouse game of the coding world.
The chatter which caused a need for such a discussion seems to have calmed a bit lately? Maybe not so many instances of it being used lately? Maybe the thrill of the new tool lost it's appeal in the player's?

But I know it still remains an area which needs some form of solution, and I'm hoping some items here have been at least a bit helpful or sifted through towards finding the right solution for both sides.
It would be nice to see more people involved with the topic though.

Anyway, just thought I'd ask.
A Wonderful World

sofar
Developer
Posts: 2146
Joined: Fri Jan 16, 2015 07:31
GitHub: sofar
IRC: sofar
In-game: sofar

Re: [discussion]Technical notes on how to defeat(*) oredetec

by sofar » Post

TumeniNodes wrote:I'm wondering if this discussion has helped toward a solution in any way yet?
Too many people can't distinguish between solutions that don't solve the underlying problem: The client receives all map data.

My attempt was (well, not the main goal, but still) to make people creatively think about how to make essentially hacked clients useless, whether it be CSM or people patching their binaries. Eliminating a vast amount of mining related exploits entirely from the game is more beneficial than eliminating it only from "unmodified" clients.

In the same reason that bittorrent will always exist: you simply get movies easier than through legal means; hacked clients will always exist in one way or another.

There's also a lot of complaining about how players "don't like the possible gameplay". Obviously this is entirely hypothetical, as most will probably admit they've never played in a way that was described in several methods.

So, sadly, this whole discussion feels like me talking to a brick wall. Most people don't even read beyond the first line in the first topic.

Xudo
Member
Posts: 162
Joined: Wed Nov 09, 2016 16:43
GitHub: akryukov92
In-game: Xudo

Re: [discussion]Technical notes on how to defeat(*) oredetec

by Xudo » Post

sofar wrote:The client receives all map data.
It shouldn't.
Client should not receive all map data, because this is the security breach used by oredetect.
You can think of different implementations of this rule in MT engine: line of sight, special "revealing" event, block update and so on. If hacked client has no information about ores, then it is useless.
Any "gameplay" solutions should be implemented as an optional mod.
Fixing security breach with gameplay solution does not seems to be a good solution anyway.

sofar
Developer
Posts: 2146
Joined: Fri Jan 16, 2015 07:31
GitHub: sofar
IRC: sofar
In-game: sofar

Re: [discussion]Technical notes on how to defeat(*) oredetec

by sofar » Post

Xudo wrote:
sofar wrote:The client receives all map data.
It shouldn't.
Client should not receive all map data, because this is the security breach used by oredetect.
You can think of different implementations of this rule in MT engine: line of sight, special "revealing" event, block update and so on. If hacked client has no information about ores, then it is useless.
This may very well be, but line of sight is incredibly expensive to calculate. Essentially, you're asking the server to perform the graphics calculations of *every client* and duplicate that on the server, which is near impossible to do.

So, what you suggest as a solution is unrealistic.

User avatar
Glory!
Member
Posts: 92
Joined: Thu Apr 30, 2015 17:45
GitHub: Glory7000
In-game: Glory7000
Location: Kernel Debugging Land <3

Re: [discussion]Technical notes on how to defeat(*) oredetec

by Glory! » Post

Haven't read half of the third page, I agree with the idea of an expensive ore detector tool.

I'd augment to that by having layers upon layers upon layers of increasingly rarer ores and increasingly more expensive tools that finds even rarer ores, thus creating a relatively balanced, layer based mining; somewhat like levels, stages.

Example:

- A mese tool that finds mese, diamond, gold, and emeralds; emerald tool that finds mese, diamond, gold, emeralds, ruby, and loremipsumnium;
- A few hundred nodes under the start of diamond spawn, the start of emerald & ruby spawn.
- Some dozen kilonodes under the surface, loremipsumnium starts spawning.

I don't know ore mods, this is just my 2 cents into the discussion.
Behold the Razgriz, its wings of black sheath. :: My skin A competitor that unfortunately needs attention to stay afloat.

User avatar
Joseph16
Member
Posts: 310
Joined: Tue Dec 06, 2016 05:35
In-game: smb3

Re: [discussion]Technical notes on how to defeat(*) oredetec

by Joseph16 » Post

How about this: we add some code to the engine that reports what Client mods are enabled.

The server gets a list from each player.

The server owner can set the server to kick any player with ‘oredetect’ in the list.

It should then display a message saying: kicked for using oredetect. Please de-activate it and then try again.

I know people could rename it, but is it worth even THINKING about changing the way the entire game is played just to stop cheaters?

I know this topic is for ideas on how to stop them but I think it’s unbelievable that people would even suggest changing the way ores work just to stop cheaters.

How about we add a spectator mode and play owner catching hackers?

This would be better than changing the game and I think a lot of people will agree.

I know nothing is happening ATM but still. Please don’t change the game!
Testin' mines since 1989

wilkgr76
Member
Posts: 832
Joined: Wed Feb 18, 2015 02:44
GitHub: wilkgr76

Re: [discussion]Technical notes on how to defeat(*) oredetec

by wilkgr76 » Post

Joseph13 wrote:How about this: we add some code to the engine that reports what Client mods are enabled
In theory that is a good idea, and (I think) has been discussed previously.

Unfortunately, as Minetest is open-source, anyone can modify their client to not report mods. :/
N/A

User avatar
Lone_Wolf
Member
Posts: 2576
Joined: Sun Apr 09, 2017 05:50
GitHub: LoneWolfHT
IRC: LandarVargan
In-game: LandarVargan

Re: [discussion]Technical notes on how to defeat(*) oredetec

by Lone_Wolf » Post

wilkgr76 wrote:
Joseph13 wrote:How about this: we add some code to the engine that reports what Client mods are enabled
In theory that is a good idea, and (I think) has been discussed previously.

Unfortunately, as Minetest is open-source, anyone can modify their client to not report mods. :/
It'll prevent some people from using banned CSMs at least.
My ContentDB -|- Working on CaptureTheFlag -|- Minetest Forums Dark Theme!! (You need it)

User avatar
ExeterDad
Member
Posts: 1717
Joined: Sun Jun 01, 2014 20:00
In-game: ExeterDad
Location: New Hampshire U.S.A

Re: [discussion]Technical notes on how to defeat(*) oredetec

by ExeterDad » Post

Lone_Wolf wrote:
wilkgr76 wrote:
Joseph13 wrote:How about this: we add some code to the engine that reports what Client mods are enabled
In theory that is a good idea, and (I think) has been discussed previously.

Unfortunately, as Minetest is open-source, anyone can modify their client to not report mods. :/
It'll prevent some people from using banned CSMs at least.
It wouldn't work at all. The mods are just text files. The user can name the mod anything they wish. They could name a "restricted" mod a approved mod and do as they wish.

User avatar
GreenXenith
Member
Posts: 1356
Joined: Wed Oct 28, 2015 01:26
GitHub: GreenXenith
Location: UTC-8:00
Contact:

Re: [discussion]Technical notes on how to defeat(*) oredetec

by GreenXenith » Post

TL;DR dunno if this has been suggested yet, but I found this in adv settings
Image
If CSM's send their code to the server, then block CSM's that do functions that oredetect does (find_nodes_in_area or whatever it is). If this isn't already in the engine, it should be, so servers can detect what CSM code is used.
(Also that screenshot is a 0.4.16-dev-5045bdc so maybe that isn't a thing in 0.4.16 and was added later.)
YouTube | Mods | Patreon | Minetest Discord @greenxenith

You should not be able to read this message.

sofar
Developer
Posts: 2146
Joined: Fri Jan 16, 2015 07:31
GitHub: sofar
IRC: sofar
In-game: sofar

Re: [discussion]Technical notes on how to defeat(*) oredetec

by sofar » Post

GreenDimond wrote: If CSM's send their code to the server, then block CSM's that do functions that oredetect does (find_nodes_in_area or whatever it is). If this isn't already in the engine, it should be, so servers can detect what CSM code is used.
(Also that screenshot is a 0.4.16-dev-5045bdc so maybe that isn't a thing in 0.4.16 and was added later.)
CSM's don't send their code to the server. And all of the above options can be defeated trivially by anyone with a compiler.

User avatar
Linuxdirk
Member
Posts: 3216
Joined: Wed Sep 17, 2014 11:21
In-game: Linuxdirk
Location: Germany
Contact:

Re: [discussion]Technical notes on how to defeat(*) oredetec

by Linuxdirk » Post

sofar wrote:And all of the above options can be defeated trivially by anyone with a compiler.
We all know that. You don't need to justify not having any CSM security by repeating this over and over again.

User avatar
duane
Member
Posts: 1715
Joined: Wed Aug 19, 2015 19:11
GitHub: duane-r
Location: Oklahoma City
Contact:

Re: [discussion]Technical notes on how to defeat(*) oredetec

by duane » Post

Linuxdirk wrote:
sofar wrote:And all of the above options can be defeated trivially by anyone with a compiler.
We all know that. You don't need to justify not having any CSM security by repeating this over and over again.
What's the point of easily defeated security? Would you use a padlock made of styrofoam?
Believe in people and you don't need to believe anything else.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest