kernel 2.5.61

[X11]

Playing tricks on netcraft could be in the area of pranking, that or misinfomration, but i prefer pranking.

[Void Main]

I wouldn't call it either. I would consider what I am doing "kernel research and development or debugging". It could also be considered security related. Someone else might use it for a prank.

[ThePreacher]

I wouldn't call it either. I would consider what I am doing "kernel research and development or debugging". It could also be considered security related. Someone else might use it for a prank.

Actually this is far from a prank, and it turns out that because of his research, he discovered a pretty big bug. Im going to do a little research and see if anyone else out there discovered this problem.

[X11]

you have good point there.

[Void Main]

For anyone interested in hacking I believe the one place that needs to be changed is in "/usr/src/linux-2.5.62/include/net/tcp.h" line 1004:

Code: Select all

/* TCP timestamps are only 32-bits, this causes a slight
 * complication on 64-bit systems since we store a snapshot
 * of jiffies in the buffer control blocks below.  We decidely
 * only use of the low 32-bits of jiffies and hide the ugly
 * casts with the following macro.
 */
#define tcp_time_stamp          ((__u32)(jiffies))


As you can see this is where the timestamp is set. You can also see that it set to the 32 bit jiffies variable which recently has been changed to wrap 10 times faster than it used to. Now as a test I changed the above line to:

Code: Select all

#define tcp_time_stamp          ((__u32)(jiffies/100))


figuring dividing by 10 would only get us back to the 497 day limit. Well it appears that "tcpdump" showed the timestamp I was after (although I knew this alone would not solve the problem), nmap wouldn't show an uptime at all. I don't know if that means nmap would need to be patched or the increment of the timestamp var is too slow when dividing by 100 (there are limits).

At any rate if the above would have worked then instead of using "((__u32)(jiffies/100))" we would need something like "((__u32)(jiffies_64/100))" but I'm quite rusty on my C and can not get this to work. There is actually a function that should probably be used here rather than the jiffies_64 var itself called "get_jiffies_64()".

Here is an interesting and pretty easy to understand reference:
http://www.securiteam.com/securitynews/5NP0C153PI.html

I would think that "jiffies_64/100" would keep us well within the range and give us about a 13.6 year rollover (about one third of the BSD uptime capability). Where am I whacked?