Closed WlinkNET closed 9 months ago
Thanks for the report. Let us take a closer look into it. From the first sight (it should be investigated thoroughly), the case you have reported looks quite rare event to happen to take any significant advantage of it. It would be great if you could provide any example of using it.
in p3d github repository file: src/lib.rs at lines 110 - 122
if let Some(rot) = trans {
let axis_normalized = Vector3::new(
rot[0] as f64 * 45.0 / 256.0,
rot[1] as f64 * 45.0 / 256.0,
rot[2] as f64 * 45.0 / 256.0,
).normalize();
mesh.apply_transformation(
Mat4::from_axis_angle(
axis_normalized,
Deg(rot[3] as f64 * 360.0 / 256.0),
)
);
}
if rot[3] is 0 then Mat4::from_axis_angle will return the same value (a matrix wich doesn't affect the object in any way) for every value of rot[0],rot[1],rot[2]. The reason of this is obviously, rotating an object with angle 0 will not change anything.
The simples way to solve this is to check at the beggining of the hash function (at line 46 -> pub fn p3d_process...) if the 4th element of trans is 0. If this element it's 0 the function can just return an empty array, like there is no result hash.
Example scenario in which this bug is critical for mining: Let's say we pregenerate a lot of random objects with rotation 0 (100m+,1b+), it will take some hours, but then we can store them to use later at anytime. Then, the node can be easily modified to generate blocks for mining continuosly and discard all which doesn't have the 4th byte in prehash 0. For example on a 7950x cpu we can run 8 nodes at the same time and each one is generating a new block in 30-50ms -> 25 blocks per second for only one instance and for all of them 258 = 200 blocks per second, so it means one cpu can generate almost 1 valid block (with 4th byte 0) at almost every second. Let's say we have 10 cpus for this so in total we will get 8-10 good blocks per second. After this we can build a simple proxy/server which will request every node for its blocks. In the end our new miner will use the very big list with objects and all generated blocks to just do sha3 hashes. Think that every new block generated means another (length of the big list) hashes checked (in our example 100m 10(blocks per second) will result in 1gh per second).
The current bug/exploit is nearly the same with the last one and with my solution you solve it forever . You can make an object and you can hash it with a prehash like x y z 0 … it doesnt matter what are the values for x y z because the hash will be the same. So if you generate many blocks you can do the hardwork only once and then just do the sha3 part ( basically skip the main step in the hashing process ) .
solution : just check for the "empty" rotation (when the 4th byte is 0), so hashes with no rotation cannot be built