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

sofar
Developer
 
Posts: 2066
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 » Wed Jul 26, 2017 17:37

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: 153
Joined: Wed Nov 09, 2016 16:43
GitHub: akryukov92
In-game: Xudo

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

by Xudo » Wed Jul 26, 2017 19:25

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: 3874
Joined: Sun Sep 09, 2012 17:31
GitHub: Sokomine

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

by Sokomine » Wed Jul 26, 2017 19:49

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: 831
Joined: Wed Feb 18, 2015 02:44
GitHub: wilkgr76

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

by wilkgr76 » Thu Jul 27, 2017 06:29

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: 2066
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 » Thu Jul 27, 2017 22:11

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
Location: Linux
GitHub: cdqwertz
In-game: cd cd2

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

by cd2 » Fri Jul 28, 2017 12:15

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: 2066
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 » Fri Jul 28, 2017 20:58

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: 831
Joined: Wed Feb 18, 2015 02:44
GitHub: wilkgr76

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

by wilkgr76 » Fri Jul 28, 2017 22:14

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
(273.5 KiB) Not downloaded yet
N/A
 

sofar
Developer
 
Posts: 2066
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 » Fri Jul 28, 2017 22:23

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: 831
Joined: Wed Feb 18, 2015 02:44
GitHub: wilkgr76
 

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

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

by cd2 » Sat Jul 29, 2017 08:41

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: 570
Joined: Sun Sep 04, 2016 15:15
GitHub: bell07

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

by bell07 » Sun Jul 30, 2017 21:03

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: 2826
Joined: Fri Feb 26, 2016 19:49
Location: in the dark recesses of the mind
GitHub: TumeniNodes
IRC: tumeninodes
In-game: TumeniNodes

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

by TumeniNodes » Thu Aug 10, 2017 20:21

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.
Ich mag keine grünen Eier und Schinken, ich mag sie nicht Sam I Am
 

sofar
Developer
 
Posts: 2066
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 » Thu Aug 10, 2017 20:41

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: 153
Joined: Wed Nov 09, 2016 16:43
GitHub: akryukov92
In-game: Xudo

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

by Xudo » Thu Aug 10, 2017 22:03

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: 2066
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 » Fri Aug 11, 2017 00:32

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
Location: Kernel Debugging Land <3
GitHub: Glory7000
In-game: Glory7000

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

by Glory! » Wed Aug 23, 2017 13:08

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: 308
Joined: Tue Dec 06, 2016 05:35
In-game: Joseph16

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

by Joseph16 » Sat Nov 11, 2017 18:03

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: 831
Joined: Wed Feb 18, 2015 02:44
GitHub: wilkgr76

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

by wilkgr76 » Sun Nov 12, 2017 00:12

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: 2186
Joined: Sun Apr 09, 2017 05:50
Location: Hopefully very far from yours, snoop :P
GitHub: LoneWolfHT
IRC: Lone_Wolf
In-game: Lone_Wolf

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

by Lone_Wolf » Sun Nov 12, 2017 22:11

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.
 

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

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

by ExeterDad » Mon Nov 13, 2017 01:08

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
GreenDimond
Member
 
Posts: 1272
Joined: Wed Oct 28, 2015 01:26
Location: SCP-3008
GitHub: GreenXenith
IRC: GreenDimond
In-game: GreenDimond

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

by GreenDimond » Mon Nov 13, 2017 06:06

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.)
Y▹uTube | Mods | Patre●n | Twitter | Minetest Discord | GreenDimond#3232

Hey, you. You're finally awake.
You were trying to view their profile, right? Found the rest of their signature, same as us, and that guest over there.
 

sofar
Developer
 
Posts: 2066
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 » Mon Nov 13, 2017 08:18

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: 2178
Joined: Wed Sep 17, 2014 11:21
Location: Germany
In-game: Linuxdirk

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

by Linuxdirk » Mon Nov 13, 2017 10:38

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: 1582
Joined: Wed Aug 19, 2015 19:11
Location: Oklahoma City
GitHub: duane-r

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

by duane » Mon Nov 13, 2017 15:25

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.
 

PreviousNext

Return to Client-side modding



Who is online

Users browsing this forum: No registered users and 1 guest