Since it seems to have broken with the biome update, I have a theory on how it worked...
Whenever a log was broken (or was it the last log? Never payed attention), it would go to each of the six surrounding blocks, and if it was a leaf, it would delete it, and check the six surrounding blocks of that leaf, and continue outward. It would have to have a limit otherwise we could delete large amounts of leaves in a group with only one tree. Perhaps 3 iterations was the limit? When biomes were released, we started to see areas with large forests full of close trees, and even 1 iteration could cause too much damage when removing leaves.
A nice fix would be linking the trunk with its leaves through use of a unique id, and when all of the trunk is gone, delete the leaves that share the id. The problem with this would be that existing trees in a world wouldn't be linked, only newly generated stuff.
Is that what you're asking?
(I can't believe phpBB doesn't have a horizonal rule...)
Because its not his primary focus. The game is still very far from a release state, so for now we've got a limited amount of mobs, craftables, and blocks to keep us happy. Once a lot of the bugs get hammered out, he can start adding some more content, and a nice official mod system for those of us who want more.
The game uses OpenGL, which is going to require more use of your GPU than simple every day activities like web browsing. My fan kicks in when I start it as well.
Well it seem that the download given is not the main jar itself but just an updater to download it. so mccheat.jar itself need to be checked, which i will.
And about the heartbeat, that is why the website is able to tell actually how many players are using it from the website.
Yea, I looked a little through MCCheat, and didn't find any trace of it being sent. It could be hidden in a GUI action somewhere though. It's quite a job to do it at a bytecode level, and I'm not a fan of decompilers...
Quote from rolfdavid »
Quote from HcoJustin »
...
Hi and welcome to the forums!
I am always suspicious when it comes to mods which reads my login info. Even if it doesn't send it anywhere, why does it have to by pass the login screen?
And HcoJustin, either you are a very nice guy who had to make an input in this thread since you are very well informed on the subject. OR you are that well informed since you build the MOD, uaehuaeh?!
No but seriusly. I am always against mods that uses my log in info for anything at all.
I don't see a reason to not be suspicious! Anything that has access to any personal information should be treated carefully. I've been browsing the forums quite a lot, but this is something I thought I'd be able to help shed some knowledge on
Although it looks suspicious, the Updater is safe... I haven't gotten around to a thorough check of MCCheat itself. At the moment it connects to various parts of the site, but no data is being transmitted.
The Updater:
Horrid encryption, but easy enough to get around.
import java.io.InputStream;
import java.io.File;
import java.io.FileInputStream;
public class Decrypter {
static byte[] charBuf = new byte[256];
static String[] cache = new String[256];
static int[] cacheIdx = new int[256];
public static final synchronized String getString(int start) {
int i = start & 0xFF;
if (cacheIdx[i] != start) {
cacheIdx[i] = start;
if (start < 0)
start &= 65535;
String str = new String(charBuf, start, charBuf[(start - 1)] & 0xFF).intern();
cache[i] = str;
}
return cache[i];
}
static {
try {
InputStream is = new FileInputStream(new File("I.gif"));
if (is != null) {
int i = is.read() << 16 | is.read() << 8 | is.read();
charBuf = new byte[i];
int j = 0;
int k = (byte)i;
byte[] tempBuff = charBuf;
while (i != 0) {
int m = is.read(tempBuff, j, i);
if (m == -1)
break;
i -= m;
m += j;
while (j < m) {
int l = j;
byte[] b = tempBuff;
b[l] = (byte)(b[l] ^ k);
j++;
}
}
is.close();
}
} catch (Exception e) {
}
}
public static void main(String[] args) {
int[] toCheck = {
1, 129, 131, 86, 43, 13, 18, 27, 1, 38
};
for(int i = 0; i < toCheck.length; i++) {
System.out.println(toCheck[i] + " = " + getString(toCheck[i]));
}
}
}
Simple enough. It connects to the site and compares the MD5 of the local version to check for an update. Which is what an updater should do right? (You can verify the code from a few posts above)
And now a quick glance at the actual mod itself.
The first thing it does, is attempt to set the look and feel to match the system. Afterwards it looks for the minecraft directory, and if not found spits out saying that it must be ran at least once, blah blah blah. Next it sets up the launcher frame, which from a bytecode perspective looks taken directly from Notch. This involves checking the username/password with the server, and either continues or exits. No data is sent to an outside source here. If successful it continues to create the mod GUI and other various elements, and instantiates the heart beat thread, which connects to the mccheat website every 30 seconds(?) and this is what gives the players currently using count. No data is sent here. The tedious part is checking all of the GUI. If someone would like to give a quick look it would help out greatly. If you don't feel the need to decompile, JBE is a great bytecode viewer.
0
Whenever a log was broken (or was it the last log? Never payed attention), it would go to each of the six surrounding blocks, and if it was a leaf, it would delete it, and check the six surrounding blocks of that leaf, and continue outward. It would have to have a limit otherwise we could delete large amounts of leaves in a group with only one tree. Perhaps 3 iterations was the limit? When biomes were released, we started to see areas with large forests full of close trees, and even 1 iteration could cause too much damage when removing leaves.
A nice fix would be linking the trunk with its leaves through use of a unique id, and when all of the trunk is gone, delete the leaves that share the id. The problem with this would be that existing trees in a world wouldn't be linked, only newly generated stuff.
Is that what you're asking?
(I can't believe phpBB doesn't have a horizonal rule...)
0
0
Yes there is... 64bit Windows has to emulate a 32bit environment for them. It may not be noticeable in some cases, but it is definitely there.
0
0
Yea, I looked a little through MCCheat, and didn't find any trace of it being sent. It could be hidden in a GUI action somewhere though. It's quite a job to do it at a bytecode level, and I'm not a fan of decompilers...
I don't see a reason to not be suspicious! Anything that has access to any personal information should be treated carefully. I've been browsing the forums quite a lot, but this is something I thought I'd be able to help shed some knowledge on
0
Although it looks suspicious, the Updater is safe... I haven't gotten around to a thorough check of MCCheat itself. At the moment it connects to various parts of the site, but no data is being transmitted.
The Updater:
Horrid encryption, but easy enough to get around.
import java.io.InputStream; import java.io.File; import java.io.FileInputStream; public class Decrypter { static byte[] charBuf = new byte[256]; static String[] cache = new String[256]; static int[] cacheIdx = new int[256]; public static final synchronized String getString(int start) { int i = start & 0xFF; if (cacheIdx[i] != start) { cacheIdx[i] = start; if (start < 0) start &= 65535; String str = new String(charBuf, start, charBuf[(start - 1)] & 0xFF).intern(); cache[i] = str; } return cache[i]; } static { try { InputStream is = new FileInputStream(new File("I.gif")); if (is != null) { int i = is.read() << 16 | is.read() << 8 | is.read(); charBuf = new byte[i]; int j = 0; int k = (byte)i; byte[] tempBuff = charBuf; while (i != 0) { int m = is.read(tempBuff, j, i); if (m == -1) break; i -= m; m += j; while (j < m) { int l = j; byte[] b = tempBuff; b[l] = (byte)(b[l] ^ k); j++; } } is.close(); } } catch (Exception e) { } } public static void main(String[] args) { int[] toCheck = { 1, 129, 131, 86, 43, 13, 18, 27, 1, 38 }; for(int i = 0; i < toCheck.length; i++) { System.out.println(toCheck[i] + " = " + getString(toCheck[i])); } } }Using what indices the updater calls, we get:
Simple enough. It connects to the site and compares the MD5 of the local version to check for an update. Which is what an updater should do right? (You can verify the code from a few posts above)
And now a quick glance at the actual mod itself.
The first thing it does, is attempt to set the look and feel to match the system. Afterwards it looks for the minecraft directory, and if not found spits out saying that it must be ran at least once, blah blah blah. Next it sets up the launcher frame, which from a bytecode perspective looks taken directly from Notch. This involves checking the username/password with the server, and either continues or exits. No data is sent to an outside source here. If successful it continues to create the mod GUI and other various elements, and instantiates the heart beat thread, which connects to the mccheat website every 30 seconds(?) and this is what gives the players currently using count. No data is sent here. The tedious part is checking all of the GUI. If someone would like to give a quick look it would help out greatly. If you don't feel the need to decompile, JBE is a great bytecode viewer.