NSA

People

Mon, 25 Jun 2007 16:51:36 GMT

Jeff Gribschaw

Mon, 25 Jun 2007 14:46:00 GMT

!__Publications__
*S. Krasser, G. Conti, J. Grizzard, J. Gribschaw, and H. Owen, "Real-Time and Forensic Network Data Analysis Using Animated and Coordinated Visualization," in Proc. of sixth IEEE Systems, Man and Cybernetics Information Assurance Workshop, June 2005, pp. 42-49.

Sven Krasser

Mon, 25 Jun 2007 14:45:00 GMT

!__Publications__
!!Journal Publications
*D. Barlow, V. Vassiliou, S. Krasser, H. Owen, J. Grimminger, H.-P. Huth, and J. Sokol, "Traffic engineering based on local states in Internet protocol-based radio access networks," accepted IEEE Journal of Communications and Networks.
*S. Krasser, J. Grizzard, H. Owen, and J. Levine, "The use of honeynets to increase computer network security and user awareness," in Journal of Security Education, pp. 23-37, vol. 1, no. 2/3.
!!Conference Publications
* J. Grizzard, C. Simpson, Jr., S. Krasser, H. Owen, and G. Riley, "Flow Based Observations from NETI@home and Honeynet Data," in Proc. of sixth IEEE Systems, Man and Cybernetics Information Assurance Workshop, June 2005, pp. 244-251.
* S. Krasser, G. Conti, J. Grizzard, J. Gribschaw, and H. Owen, "Real-Time and Forensic Network Data Analysis Using Animated and Coordinated Visualization," in Proc. of sixth IEEE Systems, Man and Cybernetics Information Assurance Workshop, June 2005, pp. 42-49.
* S. Krasser, H. Owen, J. Sokol, H.-P. Huth, and J. Grimminger, "Adaptive per-flow traffic engineering based on probe packet measurements," accepted CNSR 2005.
* H. Altunbasak, S. Krasser, H. Owen, J. Grimminger, H.-P. Huth, and J. Sokol, "Securing layer 2 in local area networks," accepted IEEE ICN 2005.
* H. Altunbasak, S. Krasser, H. Owen, J. Sokol, J. Grimminger, and H.-P. Huth, "Addressing the weak link between layer 2 and layer 3 in the Internet architecture," in Proc. IEEE International Conference on Local Computer Networks, Tampa, Florida, USA, pp. 417-418, November 2004.
*J. Grizzard, S. Krasser, H. Owen, G. Conti, and E. Dodson, "Towards an approach for automatically repairing compromised network systems," in Proc. 3rd IEEE International Symposium on Network Computing and Applications, Cambridge, Massachusetts, USA, pp. 389-392, August 2004.
*S. Krasser, H. Owen, J. Grimminger, H.-P. Huth, and J. Sokol, "Online traffic engineering and connection admission control based on path queue states," in Proc. IEEE SoutheastCon 2004, Greensboro, North Carolina, USA, pp. 255-260, March 2004.
*S. Krasser, H. Owen, J. Grimminger, H.-P. Huth, and J. Sokol, "Probing available bandwidth in radio access networks," in Proc. IEEE Global Communications Conference 2003, San Francisco, California, USA, vol. 6, pp. 3437-3441, December 2003.
*S. Krasser, H. Owen, J. Grimminger, H.-P. Huth, and J. Sokol, "Distributed bandwidth reservation by probing for available bandwidth," in Proc. IEEE International Conference on Networks 2003, Sydney, Australia, pp. 443-448, September 2003.
*S. Krasser, H. Owen, D. Barlow, J. Grimminger, H.-P. Huth, and J. Sokol, "Evaluation of the local state fair share bandwidth algorithm," in Proc. International Conference on Telecommunications 2003, Papeete, French Polynesia, vol. 2, pp. 911-916, February 2003.

Julian Grizzard

Mon, 25 Jun 2007 14:41:00 GMT

!__Publications__
!!Journal Publications
*J. Levine, J. Grizzard, and H.Owen, "Detecting and Categorizing Kernel-Level Rootkits to Aid Future Detection," in IEEE Security & Privacy, January/February 2006, pp. 24-32, vol. 4, no. 1. (featured article)
*D. Barlow, V. Vassiliou, S. Krasser, H. Owen, J. Grimminger, H.-P. Huth, and J. Sokol, "Traffic engineering based on local states in Internet protocol-based radio access networks," accepted IEEE Journal of Communications and Networks.
*J. Levine, J. Grizzard, and H. Owen, "Using honeynets to protect large enterprise networks," in IEEE Security & Privacy, November/December 2004, pp. 73-75, vol. 2, no. 6.
*S. Krasser, J. Grizzard, H. Owen, and J. Levine, "The use of honeynets to increase computer network security and user awareness," in Journal of Security Education, pp. 23-37, vol. 1, no. 2/3.
!!Conference Publications
* J. Grizzard and H. Owen, "On a µ-kernel Based System Architecture Enabling Recovery from Rootkits", accepted First IEEE International Workshop on Critical Infrastructure Protection, 2005.
* J. Grizzard, C. Simpson, Jr., S. Krasser, H. Owen, and G. Riley, "Flow Based Observations from NETI@home and Honeynet Data," in Proc. of sixth IEEE Systems, Man and Cybernetics Information Assurance Workshop, June 2005, pp. 244-251.
* S. Krasser, G. Conti, J. Grizzard, J. Gribschaw, and H. Owen, "Real-Time and Forensic Network Data Analysis Using Animated and Coordinated Visualization," in Proc. of sixth IEEE Systems, Man and Cybernetics Information Assurance Workshop, June 2005, pp. 42-49.
* J. Grizzard, J. Levine, and H. Owen, "Re-establishing trust in compromised systems: Recovering from rootkits that trojan the system call table," in Proc. 9th European Symposium on Research in Computer Security, September 2004, pp. 369-384.
* D. Dagon, X. Qin, G. Gu, W. Lee, J. Grizzard, J. Levine, and H. Owen, "Honeystat: local worm detection using honeypots," in 7th International Symposium on Recent Advances in Intrusion Detection, Sophia Antipolis, France, September 2004.
* J. Grizzard, S. Krasser, H. Owen, G. Conti, and E. Dodson, "Towards an approach for automatically repairing compromised network systems," in Proc. 3rd IEEE International Symposium on Network Computing and Applications, Cambridge, Massachusetts, USA, pp. 389-392, August 2004.
* J. Grizzard, E. Dodson, G. Conti, J. Levine, and H. Owen, "Towards a trusted immutable kernel extension (TIKE) for selfhealing systems: a virtual machine approach," in Proc. 5th IEEE Information Assurance Workshop, June 2004, pp. 444-446.
* J. Levine, J. Grizzard, and H. Owen, "A methodology to detect and characterize kernel level rootkit exploits involving redirection of the system call table," in Proc. of Second IEEE International Information Assurance Workshop, April 2004, pp. 107-125.
* T. Jackson, J. Levine, J. Grizzard, and H. Owen, "An investigation of a compromised host on a honeynet begin used to increase the security of a large enterprise network," in Proc. 5th IEEE Information Assurance Workshop, March 2004, pp. 9-14.
* J. Levine, J. Grizzard, and H. Owen, "Application of a methodology to characterize rootkits retrieved from honeynets," in Proc. 5th IEEE Information Assurance Workshop, March 2004, pp. 15-21.

Hayriye Altunbasak

Mon, 25 Jun 2007 14:38:00 GMT

!__Publications__
* H. Altunbasak, S. Krasser, H. Owen, J. Grimminger, H.-P. Huth, and J. Sokol, "Securing layer 2 in local area networks," accepted IEEE ICN 2005.
* H. Altunbasak, S. Krasser, H. Owen, J. Sokol, J. Grimminger, and H.-P. Huth, "Addressing the weak link between layer 2 and layer 3 in the Internet architecture," in Proc. IEEE International Conference on Local Computer Networks, Tampa, Florida, USA, pp. 417-418, November 2004.

Kevin Fairbanks

Mon, 25 Jun 2007 14:37:00 GMT

!__Publications__
* Kevin D. Fairbanks, Christopher P. Lee, Ying H. Xia, Henry L. Owen III. “TimeKeeper: A Metadata Archiving Method for Honeypot Forensics.” 8th Annual IEEE SMC Information Assurance Workshop. West Point, NY. 20-22 June 2007
* Xia, Y., Fairbanks, K., Owen, H. "Establishing trust in black-box programs." SoutheastCon, 2007. IEEE, Vol., Iss., March 2007, pp. 462-465.

Ying Xia

Mon, 25 Jun 2007 14:36:00 GMT

Yu-Xi Lim

Mon, 25 Jun 2007 14:36:00 GMT

!__Publications__
*Yu-Xi Lim and Henry Owen, "Secure wireless location services," in Proceedings of IEEE SoutheastCon 2007, 22-25 Mar, 2007.

Research

Mon, 25 Jun 2007 14:34:00 GMT

!__Security Research__
!!The Georgia Tech Honeynet
NSA runs a honeynet in cooperation with the [[Honeynet Research Alliance|http://www.honeynet.org/alliance/index.html]]. More information can be found on our [[project webpage|The Georgia Tech Honeynet]].
!!Establishing Trust in black-box programs
Encrypted binaries are increasingly being used as deterrence for software piracy as well as vulnerability exploitation. The application of encrypted programs, however, leads to increased security concerns, as users are unable to identify malicious behavior by monitoring the encrypted executables. This paper proposes a method to monitor encrypted programs that assures users that the black-box program on their system is not violating any security concerns. Our approach is to embed a system call monitoring tool into the operating system that monitors system call content for suspicious behavior or the lack thereof.

!__Forensics Research__
!!~TimeKeeper: A Metadata Archiving Method for Honeypot Forensics
Internet attacks are becoming more advanced as the economy for cybercrime grows and the tools for evading detection become ubiquitous. To counter this threat, new detection and forensics tools are needed to capture these new techniques. In this paper, we propose a method to extract and analyze a richer set of forensic information from the file system journal of honeypots in spite of anti-forensic tool use. We show initial results of our journal monitoring prototype, ~TimeKeeper, of file system activities and argue that by detecting these events, we are able to capture previously unavailable forensic information. This forensic information can then be used for system recovery, research on attack techniques, insight into attacker motives, and for criminal investigations.

!__Networking Research__
!!Secure wireless location services
Wireless Internet access is becoming increasingly pervasive, and likewise we increasingly expect to use this Internet access while "on the go." In such a scenario where both the service and the users are no longer constrained by simple physical boundaries, there needs to be a secure means of determining the location of the users and using this information for purposes such as security or other location-based services which add value to the network. This talk proposes an architecture for such a secure location service and evaluates its
feasibility and effectiveness and compares existing insecure architectures.

You can also read more about [[past research|Past Research Projects]].

Publications

Mon, 25 Jun 2007 14:09:00 GMT

Journal Publications

J. Levine, J. Grizzard, and H.Owen, "Detecting and Categorizing Kernel-Level Rootkits to Aid Future Detection," in IEEE Security & Privacy, January/February 2006, pp. 24-32, vol. 4, no. 1. (featured article)

D. Barlow, V. Vassiliou, S. Krasser, H. Owen, J. Grimminger, H.-P. Huth, and J. Sokol, "Traffic engineering based on local states in Internet protocol-based radio access networks," accepted IEEE Journal of Communications and Networks.

J. Levine, J. Grizzard, and H. Owen, "Using honeynets to protect large enterprise networks," in IEEE Security & Privacy, November/December 2004, pp. 73-75, vol. 2, no. 6.

S. Krasser, J. Grizzard, H. Owen, and J. Levine, "The use of honeynets to increase computer network security and user awareness," in Journal of Security Education, pp. 23-37, vol. 1, no. 2/3.

href="http://users.ece.gatech.edu/~owen/Research/Journal%20Publications/journal_publications.htm">[more journal publications]

Refereed Conference Publications

Kevin D. Fairbanks, Christopher P. Lee, Ying H. Xia, Henry L. Owen III. “TimeKeeper: A Metadata Archiving Method for Honeypot Forensics.” 8th Annual IEEE SMC Information Assurance Workshop. West Point, NY. 20-22 June 2007

Xia, Y., Fairbanks, K., Owen, H. "Establishing trust in black-box programs." SoutheastCon, 2007. IEEE, Vol., Iss., March 2007, pp. 462-465.
Yu-Xi Lim and Henry Owen, "Secure wireless location services," in Proceedings of IEEE SoutheastCon 2007, 22-25 Mar, 2007.

J. Grizzard and H. Owen, "On a µ-kernel Based System Architecture Enabling Recovery from Rootkits", accepted First IEEE International Workshop on Critical Infrastructure Protection, 2005.

J. Grizzard, C. Simpson, Jr., S. Krasser, H. Owen, and G. Riley, "Flow Based Observations from NETI@home and Honeynet Data," in Proc. of sixth IEEE Systems, Man and Cybernetics Information Assurance Workshop, June 2005, pp. 244-251.
S. Krasser, G. Conti, J. Grizzard, J. Gribschaw, and H. Owen, "Real-Time and Forensic Network Data Analysis Using Animated and Coordinated Visualization," in Proc. of sixth IEEE Systems, Man and Cybernetics Information Assurance Workshop, June 2005, pp. 42-49.
S. Krasser, H. Owen, J. Sokol, H.-P. Huth, and J. Grimminger, "Adaptive per-flow traffic engineering based on probe packet measurements," accepted CNSR 2005.

H. Altunbasak, S. Krasser, H. Owen, J. Grimminger, H.-P. Huth, and J. Sokol, "Securing layer 2 in local area networks," accepted IEEE ICN 2005.

H. Altunbasak, S. Krasser, H. Owen, J. Sokol, J. Grimminger, and H.-P. Huth, "Addressing the weak link between layer 2 and layer 3 in the Internet architecture," in Proc. IEEE International Conference on Local Computer Networks, Tampa, Florida, USA, pp. 417-418, November 2004.

J. Grizzard, J. Levine, and H. Owen, "Re-establishing trust in compromised systems: Recovering from rootkits that trojan the system call table," in Proc. 9th European Symposium on Research in Computer Security, September 2004, pp. 369-384.

D. Dagon, X. Qin, G. Gu, W. Lee, J. Grizzard, J. Levine, and H. Owen, "Honeystat: local worm detection using honeypots," in 7th International Symposium on Recent Advances in Intrusion Detection, Sophia Antipolis, France, September 2004.

J. Grizzard, S. Krasser, H. Owen, G. Conti, and E. Dodson, "Towards an approach for automatically repairing compromised network systems," in Proc. 3rd IEEE International Symposium on Network Computing and Applications, Cambridge, Massachusetts, USA, pp. 389-392, August 2004.

J. Grizzard, E. Dodson, G. Conti, J. Levine, and H. Owen, "Towards a trusted immutable kernel extension (TIKE) for selfhealing systems: a virtual machine approach," in Proc. 5th IEEE Information Assurance Workshop, June 2004, pp. 444-446.

J. Levine, J. Grizzard, and H. Owen, "A methodology to detect and characterize kernel level rootkit exploits involving redirection of the system call table," in Proc. of Second IEEE International Information Assurance Workshop, April 2004, pp. 107-125.

S. Krasser, H. Owen, J. Grimminger, H.-P. Huth, and J. Sokol, "Online traffic engineering and connection admission control based on path queue states," in Proc. IEEE SoutheastCon 2004, Greensboro, North Carolina, USA, pp. 255-260, March 2004.

T. Jackson, J. Levine, J. Grizzard, and H. Owen, "An investigation of a compromised host on a honeynet begin used to increase the security of a large enterprise network," in Proc. 5th IEEE Information Assurance Workshop, March 2004, pp. 9-14.

J. Levine, J. Grizzard, and H. Owen, "Application of a methodology to characterize rootkits retrieved from honeynets," in Proc. 5th IEEE Information Assurance Workshop, March 2004, pp. 15-21.

S. Krasser, H. Owen, J. Grimminger, H.-P. Huth, and J. Sokol, "Probing available bandwidth in radio access networks," in Proc. IEEE Global Communications Conference 2003, San Francisco, California, USA, vol. 6, pp. 3437-3441, December 2003.

S. Krasser, H. Owen, J. Grimminger, H.-P. Huth, and J. Sokol, "Distributed bandwidth reservation by probing for available bandwidth," in Proc. IEEE International Conference on Networks 2003, Sydney, Australia, pp. 443-448, September 2003.

S. Krasser, H. Owen, D. Barlow, J. Grimminger, H.-P. Huth, and J. Sokol, "Evaluation of the local state fair share bandwidth algorithm," in Proc. International Conference on Telecommunications 2003, Papeete, French Polynesia, vol. 2, pp. 911-916, February 2003.

href="http://users.ece.gatech.edu/~owen/Research/Conference%20Publications/conference_publications.htm">[more
conference publications]

DatePlugin

Wed, 20 Jun 2007 14:42:00 GMT

/***
|Name|DatePlugin|
|Source|http://www.TiddlyTools.com/#DatePlugin|
|Version|2.3.0|
|Author|Eric Shulman - ELS Design Studios|
|License|http://www.TiddlyTools.com/#LegalStatements <
>and [[Creative Commons Attribution-ShareAlike 2.5 License|http://creativecommons.org/licenses/by-sa/2.5/]]|
|~CoreVersion|2.1|
|Type|plugin|
|Requires||
|Overrides||
|Description|formatted dates plus popup menu with 'journal' link, changes and (optional) reminders|

There are quite a few calendar generators, reminders, to-do lists, 'dated tiddlers' journals, blog-makers and GTD-like schedule managers that have been built around TW. While they all have different purposes, and vary in format, interaction, and style, in one way or another each of these plugins displays and/or uses date-based information to make finding, accessing and managing relevant tiddlers easier. This plugin provides a general approach to embedding dates and date-based links/menus within tiddler content.

This plugin display formatted dates, for the specified year, month, day using number values or mathematical expressions such as (Y+1) or (D+30). Optionally, you can create a link from the formatted output to a 'dated tiddler' for quick blogging or create a popup menu that includes the dated tiddler link plus links to changes made on that date as well as links to any pending reminders for the coming 31 days (if the RemindersPlugin is installed). This plugin also provides a public API for easily incorporating formatted date output (with or without the links/popups) into other plugins, such as calendar generators, etc.
!!!!!Usage
<<<
When installed, this plugin defines a macro: {{{<>}}}. All of the macro parameters are optional and, in it's simplest form, {{{<>}}}, it is equivalent to the ~TiddlyWiki core macro, {{{<>}}}.

However, where {{{<>}}} simply inserts the current date/time in a predefined format (or custom format, using {{{<>}}}), the {{{<>}}} macro's parameters take it much further than that:
* [mode] is either ''display'', ''link'' or ''popup''. If omitted, it defaults to ''display''. This param let's you select between simply displaying a formatted date, or creating a link to a specific 'date titled' tiddler or a popup menu containing a dated tiddler link, plus links to changes and reminders.
* [date] lets you enter ANY date (not just today) as ''year, month, and day values or simple mathematical expressions'' using pre-defined variables, Y, M, and D for the current year, month and day, repectively. You can display the modification date of the current tiddler by using the keyword: ''tiddler'' in place of the year, month and day parameters. Use ''tiddler://name-of-tiddler//'' to display the modification date of a specific tiddler. You can also use keywords ''today'' or ''filedate'' to refer to these //dynamically changing// date/time values.
* [format] and [linkformat] uses standard ~TiddlyWiki date formatting syntax. The default is "YYYY.0MM.0DD"
>^^''DDD'' - day of week in full (eg, "Monday"), ''DD'' - day of month, ''0DD'' - adds leading zero^^
>^^''MMM'' - month in full (eg, "July"), ''MM'' - month number, ''0MM'' - adds leading zero^^
>^^''YYYY'' - full year, ''YY'' - two digit year, ''hh'' - hours, ''mm'' - minutes, ''ss'' - seconds^^
>^^//note: use of hh, mm or ss format codes is only supported with ''tiddler'', ''today'' or ''filedate'' values//^^
* [linkformat] - specify an alternative date format so that the title of a 'dated tiddler' link can have a format that differs from the date's displayed format

In addition to the macro syntax, DatePlugin also provides a public javascript API so that other plugins that work with dates (such as calendar generators, etc.) can quickly incorporate date formatted links or popups into their output:

''{{{showDate(place, date, mode, format, linkformat, autostyle, weekend)}}}''

Note that in addition to the parameters provided by the macro interface, the javascript API also supports two optional true/false parameters:
* [autostyle] - when true, the font/background styles of formatted dates are automatically adjusted to show the date's status: 'today' is boxed, 'changes' are bold, 'reminders' are underlined, while weekends and holidays (as well as changes and reminders) can each have a different background color to make them more visibly distinct from each other.
* [weekend] - true indicates a weekend, false indicates a weekday. When this parameter is omitted, the plugin uses internal defaults to automatically determine when a given date falls on a weekend.
<<<
!!!!!Examples
<<<
The current date: <>
The current time: <>
Today's blog: <>
Recent blogs/changes/reminders: <> <> <>
The first day of next month will be a <>
This tiddler (DatePlugin) was last updated on: <>
The SiteUrl was last updated on: <>
This document was last saved on <>
<> will be a <>
<<<
!!!!!Installation
<<<
import (or copy/paste) the following tiddlers into your document:
''DatePlugin'' (tagged with <>)
<<<
!!!!!Revision History
<<<
''2007.05.31 [2.3.0]'' list "created" tiddlers in date popup. Also, force re-cache of created/modified indices when displaying current date and store.isDirty(), so that popup is kept in sync with tiddler changes.
''2006.05.09 [2.2.1]'' added "todaybg" handling to set background color of current date. Also, honor excludeLists tag when getting lists of tiddlers. Based on suggestions by Mark Hulme.
''2006.05.05 [2.2.0]'' added "linkedbg" handling to set background color when a 'dated tiddler' exists. Based on a suggestion by Mark Hulme.
''2006.03.08 [2.1.2]'' add 'override leadtime' flag param in call to findTiddlersWithReminders(), and add "Enter a title" default text to new reminder handler. Thanks to Jeremy Sheeley for these additional tweaks.
''2006.03.06 [2.1.0]'' hasReminders() nows uses window.reminderCacheForCalendar[] when present. If calendar cache is not present, indexReminders() now uses findTiddlersWithReminders() with a 90-day look ahead to check for reminders. Also, switched default background colors for autostyled dates: reminders are now greenish ("c0ffee") and holidays are now reddish ("ffaace").
''2006.02.14 [2.0.5]'' when readOnly is set (by TW core), omit "new reminders..." popup menu item and, if a "dated tiddler" does not already exist, display the date as simple text instead of a link.
''2006.02.05 [2.0.4]'' added var to variables that were unintentionally global. Avoids FireFox 1.5.0.1 crash bug when referencing global variables
''2006.01.18 [2.0.3]'' In 1.2.x the tiddler editor's text area control was given an element ID=("tiddlerBody"+title), so that it was easy to locate this field and programmatically modify its content. With the addition of configuration templates in 2.x, the textarea no longer has an ID assigned. To find this control we now look through all the child nodes of the tiddler editor to locate a "textarea" control where attribute("edit") equals "text", and then append the new reminder to the contents of that control.
''2006.01.11 [2.0.2]'' correct 'weekend' override detection logic in showDate()
''2006.01.10 [2.0.1]'' allow custom-defined weekend days (default defined in config.macros.date.weekend[] array)
added flag param to showDate() API to override internal weekend[] array
''2005.12.27 [2.0.0]'' Update for TW2.0
Added parameter handling for 'linkformat'
''2005.12.21 [1.2.2]'' FF's date.getYear() function returns 105 (for the current year, 2005). When calculating a date value from Y M and D expressions, the plugin adds 1900 to the returned year value get the current year number. But IE's date.getYear() already returns 2005. As a result, plugin calculated date values on IE were incorrect (e.g., 3905 instead of 2005). Adding +1900 is now conditional so the values will be correct on both browsers.
''2005.11.07 [1.2.1]'' added support for "tiddler" dynamic date parameter
''2005.11.06 [1.2.0]'' added support for "tiddler:title" dynamic date parameter
''2005.11.03 [1.1.2]'' when a reminder doesn't have a specified title parameter, use the title of the tiddler that contains the reminder as "fallback" text in the popup menu. Based on a suggestion from BenjaminKudria.
''2005.11.03 [1.1.1]'' Temporarily bypass hasReminders() logic to avoid excessive overhead from generating the indexReminders() cache. While reminders can still appear in the popup menu, they just won't be indicated by auto-styling the date number that is displayed. This single change saves approx. 60% overhead (5 second delay reduced to under 2 seconds).
''2005.11.01 [1.1.0]'' corrected logic in hasModifieds() and hasReminders() so caching of indexed modifieds and reminders is done just once, as intended. This should hopefully speed up calendar generators and other plugins that render multiple dates...
''2005.10.31 [1.0.1]'' documentation and code cleanup
''2005.10.31 [1.0.0]'' initial public release
''2005.10.30 [0.9.0]'' pre-release
<<<
!!!!!Credits
<<<
This feature was developed by EricShulman from [[ELS Design Studios|http:/www.elsdesign.com]].
<<<
!!!!!Code
***/
//{{{
version.extensions.date = {major: 2, minor: 3, revision: 0, date: new Date(2007,5,31)};
//}}}

//{{{
config.macros.date = {
format: "YYYY.0MM.0DD", // default date display format
linkformat: "YYYY.0MM.0DD", // 'dated tiddler' link format
linkedbg: "#babb1e", // "babble"
todaybg: "#ffab1e", // "fable"
weekendbg: "#c0c0c0", // "cocoa"
holidaybg: "#ffaace", // "face"
createdbg: "#bbeeff", // "beef"
modifiedsbg: "#bbeeff", // "beef"
remindersbg: "#c0ffee", // "coffee"
holidays: [ "01/01", "07/04", "07/24", "11/24" ], // NewYearsDay, IndependenceDay(US), Eric's Birthday (hooray!), Thanksgiving(US)
weekend: [ 1,0,0,0,0,0,1 ] // [ day index values: sun=0, mon=1, tue=2, wed=3, thu=4, fri=5, sat=6 ]
};
//}}}

//{{{
config.macros.date.handler = function(place,macroName,params)
{
// do we want to see a link, a popup, or just a formatted date?
var mode="display";
if (params[0]=="display") { mode=params[0]; params.shift(); }
if (params[0]=="popup") { mode=params[0]; params.shift(); }
if (params[0]=="link") { mode=params[0]; params.shift(); }
// get the date
var now = new Date();
var date = now;
if (!params[0] || params[0]=="today")
{ params.shift(); }
else if (params[0]=="filedate")
{ date=new Date(document.lastModified); params.shift(); }
else if (params[0]=="tiddler")
{ date=store.getTiddler(story.findContainingTiddler(place).id.substr(7)).modified; params.shift(); }
else if (params[0].substr(0,8)=="tiddler:")
{ var t; if ((t=store.getTiddler(params[0].substr(8)))) date=t.modified; params.shift(); }
else {
var y = eval(params.shift().replace(/Y/ig,(now.getYear()<1900)?now.getYear()+1900:now.getYear()));
var m = eval(params.shift().replace(/M/ig,now.getMonth()+1));
var d = eval(params.shift().replace(/D/ig,now.getDate()+0));
date = new Date(y,m-1,d);
}
// date format with optional custom override
var format=this.format; if (params[0]) format=params.shift();
var linkformat=this.linkformat; if (params[0]) linkformat=params.shift();
showDate(place,date,mode,format,linkformat);
}
//}}}

//{{{
window.showDate=showDate;
function showDate(place,date,mode,format,linkformat,autostyle,weekend)
{
if (!mode) mode="display";
if (!format) format=config.macros.date.format;
if (!linkformat) linkformat=config.macros.date.linkformat;
if (!autostyle) autostyle=false;

// format the date output
var title = date.formatString(format);
var linkto = date.formatString(linkformat);

// just show the formatted output
if (mode=="display") { place.appendChild(document.createTextNode(title)); return; }

// link to a 'dated tiddler'
var link = createTiddlyLink(place, linkto, false);
link.appendChild(document.createTextNode(title));
link.title = linkto;
link.date = date;
link.format = format;
link.linkformat = linkformat;

// if using a popup menu, replace click handler for dated tiddler link
// with handler for popup and make link text non-italic (i.e., an 'existing link' look)
if (mode=="popup") {
link.onclick = onClickDatePopup;
link.style.fontStyle="normal";
}

// format the popup link to show what kind of info it contains (for use with calendar generators)
if (!autostyle) return;
if (hasModifieds(date)||hasCreateds(date))
{ link.style.fontStyle="normal"; link.style.fontWeight="bold"; }
if (hasReminders(date))
{ link.style.textDecoration="underline"; }
if(isToday(date))
{ link.style.border="1px solid black"; }

if( (weekend!=undefined?weekend:isWeekend(date)) && (config.macros.date.weekendbg!="") )
{ place.style.background = config.macros.date.weekendbg; }
if(isHoliday(date)&&(config.macros.date.holidaybg!=""))
{ place.style.background = config.macros.date.holidaybg; }
if (hasCreateds(date)&&(config.macros.date.createdbg!=""))
{ place.style.background = config.macros.date.createdbg; }
if (hasModifieds(date)&&(config.macros.date.modifiedsbg!=""))
{ place.style.background = config.macros.date.modifiedsbg; }
if (store.tiddlerExists(linkto)&&(config.macros.date.linkedbg!=""))
{ place.style.background = config.macros.date.linkedbg; }
if (hasReminders(date)&&(config.macros.date.remindersbg!=""))
{ place.style.background = config.macros.date.remindersbg; }
if(isToday(date)&&(config.macros.date.todaybg!=""))
{ place.style.background = config.macros.date.todaybg; }
}
//}}}

//{{{
function isToday(date) // returns true if date is today
{ var now=new Date(); return ((now-date>=0) && (now-date<86400000)); }

function isWeekend(date) // returns true if date is a weekend
{ return (config.macros.date.weekend[date.getDay()]); }

function isHoliday(date) // returns true if date is a holiday
{
var longHoliday = date.formatString("0MM/0DD/YYYY");
var shortHoliday = date.formatString("0MM/0DD");
for(var i = 0; i < config.macros.date.holidays.length; i++) {
var holiday=config.macros.date.holidays[i];
if (holiday==longHoliday||holiday==shortHoliday) return true;
}
return false;
}
//}}}

//{{{
// Event handler for clicking on a day popup
function onClickDatePopup(e)
{
if (!e) var e = window.event;
var theTarget = resolveTarget(e);
var popup = createTiddlerPopup(this);
if(popup) {
// always show dated tiddler link (or just date, if readOnly) at the top...
if (!readOnly || store.tiddlerExists(this.date.formatString(this.linkformat)))
createTiddlyLink(popup,this.date.formatString(this.linkformat),true);
else
createTiddlyText(popup,this.date.formatString(this.linkformat));
addCreatedsToPopup(popup,this.date,this.format);
addModifiedsToPopup(popup,this.date,this.format);
addRemindersToPopup(popup,this.date,this.linkformat);
}
scrollToTiddlerPopup(popup,false);
e.cancelBubble = true;
if (e.stopPropagation) e.stopPropagation();
return(false);
}
//}}}

//{{{
function indexCreateds() // build list of tiddlers, hash indexed by creation date
{
var createds= { };
var tiddlers = store.getTiddlers("title","excludeLists");
for (var t = 0; t < tiddlers.length; t++) {
var date = tiddlers[t].created.formatString("YYYY0MM0DD")
if (!createds[date])
createds[date]=new Array();
createds[date].push(tiddlers[t].title);
}
return createds;
}
function hasCreateds(date) // returns true if date has created tiddlers
{
if (!config.macros.date.createds) config.macros.date.createds=indexCreateds();
return (config.macros.date.createds[date.formatString("YYYY0MM0DD")]!=undefined);
}

function addCreatedsToPopup(popup,when,format)
{
var force=(store.isDirty() && when.formatString("YYYY0MM0DD")==new Date().formatString("YYYY0MM0DD"));
if (force || !config.macros.date.createds) config.macros.date.createds=indexCreateds();
var indent=String.fromCharCode(160)+String.fromCharCode(160);
var createds = config.macros.date.createds[when.formatString("YYYY0MM0DD")];
if (createds) {
createds.sort();
var e=createTiddlyElement(popup,"div",null,null,"created:");
for(var t=0; t var link=createTiddlyLink(popup,createds[t],false);
link.appendChild(document.createTextNode(indent+createds[t]));
createTiddlyElement(popup,"br",null,null,null);
}
}
}
//}}}

//{{{
function indexModifieds() // build list of tiddlers, hash indexed by modification date
{
var modifieds= { };
var tiddlers = store.getTiddlers("title","excludeLists");
for (var t = 0; t < tiddlers.length; t++) {
var date = tiddlers[t].modified.formatString("YYYY0MM0DD")
if (!modifieds[date])
modifieds[date]=new Array();
modifieds[date].push(tiddlers[t].title);
}
return modifieds;
}
function hasModifieds(date) // returns true if date has modified tiddlers
{
if (!config.macros.date.modifieds) config.macros.date.modifieds = indexModifieds();
return (config.macros.date.modifieds[date.formatString("YYYY0MM0DD")]!=undefined);
}

function addModifiedsToPopup(popup,when,format)
{
var force=(store.isDirty() && when.formatString("YYYY0MM0DD")==new Date().formatString("YYYY0MM0DD"));
if (force || !config.macros.date.modifieds) config.macros.date.modifieds=indexModifieds();
var indent=String.fromCharCode(160)+String.fromCharCode(160);
var mods = config.macros.date.modifieds[when.formatString("YYYY0MM0DD")];
if (mods) {
mods.sort();
var e=createTiddlyElement(popup,"div",null,null,"changed:");
for(var t=0; t var link=createTiddlyLink(popup,mods[t],false);
link.appendChild(document.createTextNode(indent+mods[t]));
createTiddlyElement(popup,"br",null,null,null);
}
}
}
//}}}

//{{{
function indexReminders(date,leadtime) // build list of tiddlers with reminders, hash indexed by reminder date
{
var reminders = { };
if(window.findTiddlersWithReminders!=undefined) { // reminder plugin is installed
// DEBUG var starttime=new Date();
var t = findTiddlersWithReminders(date, [0,leadtime], null, null, 1);
for(var i=0; i // DEBUG var out="Found "+t.length+" reminders in "+((new Date())-starttime+1)+"ms\n";
// DEBUG out+="startdate: "+date.toLocaleDateString()+"\n"+"leadtime: "+leadtime+" days\n\n";
// DEBUG for(var i=0; i // DEBUG alert(out);
}
return reminders;
}

function hasReminders(date) // returns true if date has reminders
{
if (window.reminderCacheForCalendar)
return window.reminderCacheForCalendar[date]; // use calendar cache
if (!config.macros.date.reminders)
config.macros.date.reminders = indexReminders(date,90); // create a 90-day leadtime reminder cache
return (config.macros.date.reminders[date]);
}

function addRemindersToPopup(popup,when,format)
{
if(window.findTiddlersWithReminders==undefined) return; // reminder plugin not installed

var indent = String.fromCharCode(160)+String.fromCharCode(160);
var reminders=findTiddlersWithReminders(when, [0,31],null,null,1);
var e=createTiddlyElement(popup,"div",null,null,"reminders:"+(!reminders.length?" none":""));
for(var t=0; t link = createTiddlyLink(popup,reminders[t].tiddler,false);
var diff=reminders[t].diff;
diff=(diff<1)?"Today":((diff==1)?"Tomorrow":diff+" days");
var txt=(reminders[t].params["title"])?reminders[t].params["title"]:reminders[t].tiddler;
link.appendChild(document.createTextNode(indent+diff+" - "+txt));
createTiddlyElement(popup,"br",null,null,null);
}
if (readOnly) return; // omit "new reminder..." link
var link = createTiddlyLink(popup,indent+"new reminder...",true); createTiddlyElement(popup,"br");
var title = when.formatString(format);
link.title="add a reminder to '"+title+"'";
link.onclick = function() {
// show tiddler editor
story.displayTiddler(null, title, 2, null, null, false, false);
// find body 'textarea'
var c =document.getElementById("tiddler" + title).getElementsByTagName("*");
for (var i=0; i // append reminder macro to tiddler content
if (i if (store.tiddlerExists(title)) c[i].value+="\n"; else c[i].value="";
c[i].value += "< c[i].value += " day:"+when.getDate();
c[i].value += " month:"+(when.getMonth()+1);
c[i].value += " year:"+when.getFullYear();
c[i].value += ' title:"Enter a title" >>';
}
};
}
//}}}

News

Wed, 20 Jun 2007 14:42:00 GMT

Today is <>
The current time is <>

!__Current Events__

!__Past Events__

L4Linux-2.6 System Call Locations

Wed, 20 Jun 2007 13:44:00 GMT

Note: all folders in l4linux-2.6/
*Documentation/~DocBook/kernel-hacking.tmpl:
**asmlinkage long sys_mycall(int arg)
*arch/i386/kernel/sys_i386.c:
**int sys_pipe(unsigned long _user * fildes)
**int sys_olduname(struct oldold_utsname _user * name)
**int old_select(struct sel_arg_struct _user *arg)
**int old_mmap(struct mmap_arg_struct _user *arg)
**int sys_uname(struct old_utsname _user * name)
**int sys_ipc (uint call, int first, int second, int third, void _user *ptr, long fifth)
**long sys_mmap2(unsigned long addr, unsigned long len, unsigned long prot, unsigned long flags, unsigned long fd, unsigned long pgoff)
*arch/l4/kernel/arch-i386/ioport.c:
**long sys_ioperm(unsigned long from, unsigned long num, int turn_on)
**long sys_iopl(unsigned long unused)
*arch/l4/kernel/arch-i386/ldt.c:
**int sys_modify_ldt(int func, void _user *ptr, unsigned long bytecount)
*arch/l4/kernel/arch-i386/process.c:
**int sys_fork(void)
**int sys_clone(void)
**int sys_vfork(void)
**int sys_execve(char *name, char **argv, char **envp)
**int sys_set_thread_area(struct user_desc _user *u_info)
**int sys_get_thread_area(struct user_desc _user *u_info)
*arch/l4/kernel/arch-i386/ptrace.c:
**int sys_ptrace(long request, long pid, long addr, long data)
*arch/l4/kernel/arch-i386/signal.c:
**int sys_sigaltstack(unsigned long ebx)
**int sys_rt_sigsuspend(struct pt_regs _regs)
**int sys_sigreturn(unsigned long _unused)
**int sys_rt_sigreturn(unsigned long _unused)
**int sys_sigaction(int sig, const struct old_sigaction _user *act, struct old_sigaction _user *oact)
**int sys_sigsuspend(int history0, int history1, old_sigset_t mask)
*arch/l4/kernel/arch-i386/unimpl.c:
**int sys_vm86(void)
**int sys_vm86old(void)
*fs/aio.c:
**long sys_io_setup(unsigned nr_events, aio_context_t _user *ctxp)
**long sys_io_destroy(aio_context_t ctx)
**long sys_io_submit(aio_context_t ctx_id, long nr, struct iocb _user * _user *iocbpp)
**long sys_io_cancel(aio_context_t ctx_id, struct iocb _user *iocb, struct io_event _user *result)
**long sys_io_getevents(aio_context_t ctx_id, long min_nr, long nr, struct io_event _user *events, struct timespec _user *timeout)
*fs/buffer.c:
**long sys_sync(void)
**long sys_fsync(unsigned int fd)
**long sys_fdatasync(unsigned int fd)
**long sys_bdflush(int func, long data)
*fs/dcache.c:
**long sys_getcwd(char _user *buf, unsigned long size)
*fs/dcookies.c:
**long sys_lookup_dcookie(u64 cookie64, char _user * buf, size_t len)
*fs/eventpoll.c:
**long sys_epoll_ctl(int epfd, int op, int fd, struct epoll_event _user *event)
**long sys_epoll_create(int size)
**long sys_epoll_wait(int epfd, struct epoll_event _user *events, int maxevents, int timeout)
*fs/exec.c:
**long sys_uselib(const char _user * library)
*fs/fcntl.c:
**long sys_dup2(unsigned int oldfd, unsigned int newfd)
**long sys_dup(unsigned int fildes)
**long sys_fcntl(unsigned int fd, unsigned int cmd, unsigned long arg)
**long sys_fcntl64(unsigned int fd, unsigned int cmd, unsigned long arg)
*fs/filesystems.c:
**long sys_sysfs(int option, unsigned long arg1, unsigned long arg2)
*fs/ioctl.c:
**long sys_ioctl(unsigned int fd, unsigned int cmd, unsigned long arg)
*fs/locks.c:
**long sys_flock(unsigned int fd, unsigned int cmd)
*fs/namei.c:
**long sys_mknod(const char _user * filename, int mode, unsigned dev)
**long sys_mkdir(const char _user * pathname, int mode)
**long sys_rmdir(const char _user * pathname)
**long sys_unlink(const char _user * pathname)
**long sys_symlink(const char _user * oldname, const char _user * newname)
**long sys_link(const char _user * oldname, const char _user * newname)
**long sys_rename(const char _user * oldname, const char _user * newname)
*fs/namespace.c:
**long sys_umount(char _user * name, int flags)
**long sys_oldumount(char _user * name)
**long sys_mount(char _user * dev_name, char _user * dir_name, char _user * type, unsigned long flags, void _user * data)
**long sys_pivot_root(const char _user *new_root, const char _user *put_old)
*fs/nfsctl.c:
**sys_nfsservctl(int cmd, struct nfsctl_arg _user *arg, void _user *res)
*fs/open.c:
**long sys_statfs(const char _user * path, struct statfs _user * buf)
**long sys_statfs64(const char _user *path, size_t sz, struct statfs64 _user *buf)
**long sys_fstatfs(unsigned int fd, struct statfs _user * buf)
**long sys_fstatfs64(unsigned int fd, size_t sz, struct statfs64 _user *buf)
**long sys_truncate(const char _user * path, unsigned long length)
**long sys_ftruncate(unsigned int fd, unsigned long length)
**long sys_truncate64(const char _user * path, loff_t length)
**long sys_ftruncate64(unsigned int fd, loff_t length)
**long sys_utime(char _user * filename, struct utimbuf _user * times)
**long sys_utimes(char _user * filename, struct timeval _user * utimes)
**long sys_access(const char _user * filename, int mode)
**long sys_chdir(const char _user * filename)
**long sys_fchdir(unsigned int fd)
**long sys_chroot(const char _user * filename)
**long sys_fchmod(unsigned int fd, mode_t mode)
**long sys_chmod(const char _user * filename, mode_t mode)
**long sys_chown(const char _user * filename, uid_t user, gid_t group)
**long sys_lchown(const char _user * filename, uid_t user, gid_t group)
**long sys_fchown(unsigned int fd, uid_t user, gid_t group)
**long sys_open(const char _user * filename, int flags, int mode)
**long sys_creat(const char _user * pathname, int mode)
**long sys_close(unsigned int fd)
**long sys_vhangup(void)
*fs/quota.c:
**long sys_quotactl(unsigned int cmd, const char _user *special, qid_t id, void _user *addr)
*fs/read_write.c:
**ssize_t sys_readv(unsigned long fd, const struct iovec _user *vec, unsigned long vlen)
**size_t sys_writev(unsigned long fd, const struct iovec _user *vec, unsigned long vlen)
**off_t sys_lseek(unsigned int fd, off_t offset, unsigned int origin)
**long sys_llseek(unsigned int fd, unsigned long offset_high, unsigned long offset_low, loff_t _user * result, unsigned int origin)
**ssize_t sys_read(unsigned int fd, char _user * buf, size_t count)
**ssize_t sys_write(unsigned int fd, const char _user * buf, size_t count)
**ssize_t sys_pread64(unsigned int fd, char _user *buf, size_t count, loff_t pos)
**ssize_t sys_pwrite64(unsigned int fd, const char _user *buf, size_t count, loff_t pos)
**ssize_t sys_sendfile(int out_fd, int in_fd, off_t _user *offset, size_t count)
**ssize_t sys_sendfile64(int out_fd, int in_fd, loff_t _user *offset, size_t count)
*fs/readdir.c:
**long old_readdir(unsigned int fd, struct old_linux_dirent _user * dirent, unsigned int count)
**long sys_getdents(unsigned int fd, struct linux_dirent _user * dirent, unsigned int count)
**long sys_getdents64(unsigned int fd, struct linux_dirent64 _user * dirent, unsigned int count)
*fs/select.c:
**long sys_poll(struct pollfd _user * ufds, unsigned int nfds, long timeout)
**long sys_select(int n, fd_set _user *inp, fd_set _user *outp, fd_set _user *exp, struct timeval _user *tvp)
*fs/stat.c:
**long sys_stat(char _user * filename, struct _old_kernel_stat _user * statbuf)
**long sys_lstat(char _user * filename, struct _old_kernel_stat _user * statbuf)
**long sys_fstat(unsigned int fd, struct _old_kernel_stat _user * statbuf)
**long sys_newstat(char _user * filename, struct stat _user * statbuf)
**long sys_newlstat(char _user * filename, struct stat _user * statbuf)
**long sys_newfstat(unsigned int fd, struct stat _user * statbuf)
**long sys_readlink(const char _user * path, char _user * buf, int bufsiz)
**long sys_stat64(char _user * filename, struct stat64 _user * statbuf)
**long sys_lstat64(char _user * filename, struct stat64 _user * statbuf)
**long sys_fstat64(unsigned long fd, struct stat64 _user * statbuf)
*fs/super.c:
**long sys_ustat(unsigned dev, struct ustat _user * ubuf)
*fs/xattr.c:
**long sys_setxattr(char _user *path, char _user *name, void _user *value, size_t size, int flags)
**long sys_lsetxattr(char _user *path, char _user *name, void _user *value, size_t size, int flags)
**long sys_fsetxattr(int fd, char _user *name, void _user *value, size_t size, int flags)
**ssize_t sys_getxattr(char _user *path, char _user *name, void _user *value, size_t size)
**ssize_t sys_lgetxattr(char _user *path, char _user *name, void _user *value, size_t size)
**ssize_t sys_fgetxattr(int fd, char _user *name, void _user *value, size_t size)
**ssize_t sys_listxattr(char _user *path, char _user *list, size_t size)
**ssize_t sys_llistxattr(char _user *path, char _user *list, size_t size)
**ssize_t sys_flistxattr(int fd, char _user *list, size_t size)
**long sys_removexattr(char _user *path, char _user *name)
**long sys_lremovexattr(char _user *path, char _user *name)
**long sys_fremovexattr(int fd, char _user *name)
*ipc/mqueue.c:
**long sys_mq_open(const char _user *u_name, int oflag, mode_t mode, int oflag, mode_t mode, struct mq_attr _user *u_attr)
**long sys_mq_unlink(const char _user *u_name)
**long sys_mq_timedsend(mqd_t mqdes, const char _user *u_msg_ptr, size_t msg_len, unsigned int msg_prio, const struct timespec _user *u_abs_timeout)
**ssize_t sys_mq_timedreceive(mqd_t mqdes, char _user *u_msg_ptr, size_t msg_len, unsigned int _user *u_msg_prio, const struct timespec _user *u_abs_timeout)
**long sys_mq_notify(mqd_t mqdes, const struct sigevent _user *u_notification)
**long sys_mq_getsetattr(mqd_t mqdes, const struct mq_attr _user *u_mqstat, struct mq_attr _user *u_omqstat)
*kernel/acct.c:
**long sys_acct(const char _user *name)
*kernel/capability.c:
**long sys_capget(cap_user_header_t header, cap_user_data_t dataptr)
**long sys_capset(cap_user_header_t header, const cap_user_data_t data)
*kernel/exec_domain.c:
**long sys_personality(u_long personality)
*kernel/exit.c:
**long sys_exit(int error_code)
**void sys_exit_group(int error_code)
**long sys_waitid(int which, pid_t pid, struct siginfo _user *infop, int options, struct rusage _user *ru)
**long sys_wait4(pid_t pid, int _user *stat_addr, int options, struct rusage _user *ru)
**long sys_waitpid(pid_t pid, int _user *stat_addr, int options)
*kernel/fork.c:
**long sys_set_tid_address(int _user *tidptr)
*kernel/futex.c:
**long sys_futex(u32 _user *uaddr, int op, int val, struct timespec _user *utime, u32 _user *uaddr2, int val3)
*kernel/itimer.c:
**long sys_getitimer(int which, struct itimerval _user *value)
**long sys_setitimer(int which, struct itimerval _user *value, struct itimerval _user *ovalue)
*kernel/module.c:
**long sys_init_module(void _user *umod, unsigned long len, const char _user *uargs)
**long sys_delete_module(const char _user *name_user, unsigned int flags)
*kernel/posix-timers.c:
**long sys_timer_create(clockid_t which_clock, struct sigevent _user *timer_event_spec, timer_t _user * created_timer_id)
**long sys_timer_settime(timer_t timer_id, int flags, const struct itimerspec _user *new_setting, struct itimerspec _user *old_setting)
**long sys_timer_gettime(timer_t timer_id, struct itimerspec _user *setting)
**long sys_timer_getoverrun(timer_t timer_id)
**long sys_timer_delete(timer_t timer_id)
**long sys_clock_gettime(clockid_t which_clock, struct timespec _user *tp)
**long sys_clock_settime(clockid_t which_clock, const struct timespec _user *tp)
**long sys_clock_getres(clockid_t which_clock, struct timespec _user *tp)
**long sys_clock_nanosleep(clockid_t which_clock, int flags, const struct timespec _user *rqtp, struct timespec _user *rmtp)
*kernel/printk.c:
**long sys_syslog(int type, char _user * buf, int len)
*kernel/sched.c:
**long sys_nice(int increment)
**long sys_sched_setscheduler(pid_t pid, int policy, struct sched_param _user *param)
**long sys_sched_setparam(pid_t pid, struct sched_param _user *param)
**long sys_sched_getscheduler(pid_t pid)
**long sys_sched_getparam(pid_t pid, struct sched_param _user *param)
**long sys_sched_setaffinity(pid_t pid, unsigned int len, unsigned long _user *user_mask_ptr)
**long sys_sched_getaffinity(pid_t pid, unsigned int len, unsigned long _user *user_mask_ptr)
**long sys_sched_yield(void)
**long sys_sched_get_priority_max(int policy)
**long sys_sched_get_priority_min(int policy)
**long sys_sched_rr_get_interval(pid_t pid, struct timespec _user *interval)
*kernel/signal.c:
**long sys_tkill(int pid, int sig)
**long sys_rt_sigaction(int sig, const struct sigaction _user *act, struct sigaction _user *oact, size_t sigsetsize)
**long sys_rt_sigprocmask(int how, sigset_t _user *set, sigset_t _user *oset, size_t sigsetsize)
**long sys_rt_sigpending(sigset_t _user *set, size_t sigsetsize)
**long sys_rt_sigtimedwait(const sigset_t _user *uthese, siginfo_t _user *uinfo, const struct timespec _user *uts, size_t sigsetsize)
**long sys_rt_sigqueueinfo(int pid, int sig, siginfo_t _user *uinfo)
**long sys_sigprocmask(int how, old_sigset_t _user *set, old_sigset_t _user *oset)
**long sys_restart_syscall(void)
**long sys_tgkill(int tgid, int pid, int sig)
**long sys_pause(void)
**long sys_kill(int pid, int sig)
**unsigned long sys_signal(int sig, _sighandler_t handler)
**long sys_sgetmask(void)
**long sys_ssetmask(int newmask)
**long sys_sigpending(old_sigset_t _user *set)
*kernel/sys.c:
**long sys_setpriority(int which, int who, int niceval)
**long sys_getpriority(int which, int who)
**long sys_reboot(int magic1, int magic2, unsigned int cmd, void _user * arg)
**long sys_setregid(gid_t rgid, gid_t egid)
**long sys_setgid(gid_t gid)
**long sys_setreuid(uid_t ruid, uid_t euid)
**long sys_setuid(uid_t uid)
**long sys_setresuid(uid_t ruid, uid_t euid, uid_t suid)
**long sys_getresuid(uid_t _user *ruid, uid_t _user *euid, uid_t _user *suid)
**long sys_setresgid(gid_t rgid, gid_t egid, gid_t sgid)
**long sys_getresgid(gid_t _user *rgid, gid_t _user *egid, gid_t _user *sgid)
**long sys_setfsuid(uid_t uid)
**long sys_setfsgid(gid_t gid)
**long sys_times(struct tms _user * tbuf)
**long sys_setpgid(pid_t pid, pid_t pgid)
**long sys_getpgid(pid_t pid)
**long sys_getpgrp(void)
**long sys_getsid(pid_t pid)
**long sys_setsid(void)
**long sys_getgroups(int gidsetsize, gid_t _user *grouplist)
**long sys_setgroups(int gidsetsize, gid_t _user *grouplist)
**long sys_newuname(struct new_utsname _user * name)
**long sys_sethostname(char _user *name, int len)
**long sys_setdomainname(char _user *name, int len)
**long sys_getrlimit(unsigned int resource, struct rlimit _user *rlim)
**long sys_old_getrlimit(unsigned int resource, struct rlimit _user *rlim)
**long sys_setrlimit(unsigned int resource, struct rlimit _user *rlim)
**long sys_getrusage(int who, struct rusage _user *ru)
**long sys_umask(int mask)
**long sys_prctl(int option, unsigned long arg2, unsigned long arg3, unsigned long arg4, unsigned long arg5)
*kernel/sys_ni.c:
**long sys_ni_syscall(void)
*kernel/sysctl.c:
**long sys_sysctl(struct _sysctl_args _user *args)
*kernel/time.c:
**long sys_time(time_t _user * tloc)
**long sys_stime(time_t _user *tptr)
**long sys_gettimeofday(struct timeval _user *tv, struct timezone _user *tz)
**long sys_settimeofday(struct timeval _user *tv, struct timezone _user *tz)
**long sys_adjtimex(struct timex _user *txc_p)
*kernel/timer.c:
**unsigned long sys_alarm(unsigned int seconds)
**long sys_getpid(void)
**long sys_getppid(void)
**long sys_getuid(void)
**long sys_geteuid(void)
**long sys_getgid(void)
**long sys_getegid(void)
**long sys_gettid(void)
**long sys_nanosleep(struct timespec _user *rqtp, struct timespec _user *rmtp)
**long sys_sysinfo(struct sysinfo _user *info)
*kernel/uid16.c:
**long sys_chown16(const char _user * filename, old_uid_t user, old_gid_t group)
**long sys_lchown16(const char _user * filename, old_uid_t user, old_gid_t group)
**long sys_fchown16(unsigned int fd, old_uid_t user, old_gid_t group)
**long sys_setregid16(old_gid_t rgid, old_gid_t egid)
**long sys_setgid16(old_gid_t gid)
**long sys_setreuid16(old_uid_t ruid, old_uid_t euid)
**long sys_setuid16(old_uid_t uid)
**long sys_setresuid16(old_uid_t ruid, old_uid_t euid, old_uid_t suid)
**long sys_getresuid16(old_uid_t _user *ruid, old_uid_t _user *euid, old_uid_t _user *suid)
**long sys_setresgid16(old_gid_t rgid, old_gid_t egid, old_gid_t sgid)
**long sys_getresgid16(old_gid_t _user *rgid, old_gid_t _user *egid, old_gid_t _user *sgid)
**long sys_setfsuid16(old_uid_t uid)
**long sys_setfsgid16(old_gid_t gid)
**long sys_getgroups16(int gidsetsize, old_gid_t _user *grouplist)
**long sys_setgroups16(int gidsetsize, old_gid_t _user *grouplist)
**long sys_getuid16(void)
**long sys_geteuid16(void)
**long sys_getgid16(void)
**long sys_getegid16(void)
*mm/fadvise.c:
**long sys_fadvise64_64(int fd, loff_t offset, loff_t len, int advice)
**long sys_fadvise64(int fd, loff_t offset, size_t len, int advice)
*mm/filemap.c:
**ssize_t sys_readahead(int fd, loff_t offset, size_t count)
*mm/fremap.c:
**long sys_remap_file_pages(unsigned long start, unsigned long size, unsigned long _prot, unsigned long pgoff, unsigned long flags)
*mm/madvise.c:
**long sys_madvise(unsigned long start, size_t len_in, int behavior)
*mm/mempolicy.c:
**long sys_mbind(unsigned long start, unsigned long len, unsigned long mode, unsigned long _user *nmask, unsigned long maxnode, unsigned flags)
**long sys_set_mempolicy(int mode, unsigned long _user *nmask, unsigned long maxnode)
**long sys_get_mempolicy(int _user *policy, unsigned long _user *nmask, unsigned long maxnode, unsigned long addr, unsigned long flags
*mm/mincore.c:
**long sys_mincore(unsigned long start, size_t len, unsigned char _user * vec)
*mm/mlock.c:
**long sys_mlock(unsigned long start, size_t len)
**long sys_munlock(unsigned long start, size_t len)
**long sys_mlockall(int flags)
**long sys_munlockall(void)
*mm/mmap.c:
**unsigned long sys_brk(unsigned long brk)
**long sys_munmap(unsigned long addr, size_t len)
*mm/mremap.c:
**unsigned long sys_mremap(unsigned long addr, unsigned long old_len, unsigned long new_len, unsigned long flags, unsigned long new_addr)
*mm/msync.c:
**long sys_msync(unsigned long start, size_t len, int flags)
*mm/nommu.c:
**unsigned long sys_brk(unsigned long brk)
**long sys_munmap(unsigned long addr, size_t len)
*mm/mprotect.c:
**long sys_mprotect(unsigned long start, size_t len, unsigned long prot)
*mm/swapfile.c:
**long sys_swapoff(const char _user * specialfile)
**long sys_swapon(const char _user * specialfile, int swap_flags)
*security/keys/keyctl.c:
**long sys_add_key(const char _user *_type, const char _user *_description, const void _user *_payload, size_t plen, key_serial_t ringid)
**long sys_request_key(const char _user *_type, const char _user *_description, const char _user *_callout_info, key_serial_t destringid)
**long sys_keyctl(int option, unsigned long arg2, unsigned long arg3, unsigned long arg4, unsigned long arg5)

spine

Wed, 20 Jun 2007 13:44:00 GMT

This is a random collection of L4 notes until we get enough content to organize.
!__Links__
*[[L4 Fiasco homepage|http://os.inf.tu-dresden.de/fiasco/]]
*[[L4 lecture slides|http://os.inf.tu-dresden.de/Studium/KMB/SS2004/]]
*[[L4Linux homepage|http://os.inf.tu-dresden.de/L4/LinuxOnL4/]]
*[[L4 system call C-bindings reference manual (L4 version 2)|http://os.inf.tu-dresden.de/l4env/doc/l4sys-l4v2/]]
*[[Subscribe to l4-hackers mailing list|http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers]]
*[[L4-hackers mail archive|http://os.inf.tu-dresden.de/pipermail/l4-hackers/]]
*[[Manpages for L4/x86 and Fiasco system calls and services|http://os.inf.tu-dresden.de/L4/l4man.html]]
*[[Manpage for Fiasco kernel|http://os.inf.tu-dresden.de/fiasco/man.html]]
*[[L4 Environment|http://os.inf.tu-dresden.de/l4env/]]
*[[Multiboot specification|http://orgs.man.ac.uk/documentation/grub/multiboot.html]]
*[[Linux System Calls|http://www.cs4nerds.com/school/resources/syscalls.htm]]
*[[Linux Source Code|http://lxr.linux.no]]
*[[Export of Sys Call Table|http://seclists.org/lists/linux-kernel/2002/Oct/1192.html]]
!__Installation Notes__
*[[20041021 Installation Notes for Hello World Example|20041021_l4_install.notes]]
*[[20050523 Installation Notes for Hello World Example|20050523_l4_install.notes]]
*[[20050629 Installation Notes for L4Linux-2.6|20050629_l4linux26_install.notes]]

!__20050706 Test Box Setup Notes__
# install debian from CD
# add sources to /etc/apt/sources.list
##e.g.
##deb http://mirrors.kernel.org/debian/ sarge main
##deb http://mirrors.kernel.org/debian/ sarge contrib
##deb http://mirrors.kernel.org/debian/ sarge non-free
##deb-src http://mirrors.kernel.org/debian/ sarge main
##deb-src http://mirrors.kernel.org/debian/ sarge contrib
##deb-src http://mirrors.kernel.org/debian/ sarge non-free
##deb http://security.debian.org/ sarge/updates main
##deb http://security.debian.org/ sarge/updates contrib
##deb http://security.debian.org/ sarge/updates non-free
# apt-get install ssh
# setup public key:
##scp ~/.ssh/id_rsa.pub ${1}:
##ssh ${1} "mkdir -p .ssh && cat id_rsa.pub >>.ssh/authorized_keys"
##ssh ${1} "chmod og-rwx .ssh/authorized_keys"
##ssh ${1} "rm id_rsa.pub"
##WHERE ${1} is of the form @
#add development IP to /etc/hosts file
#apt-get install gcc-2.95 gcc binutils-doc cpp-doc make manpages-dev autoconf automake libtool flex bison gdb gcc-doc gcc-3.3-doc libc-dev libc6-dev libncurses5-dev gawk module-init-tools g++ python zlib1g zlib1g-dev latex latex2html transfig tetex-extra vim-full cvs
#cd /usr/bin
#rm gcc
#ln -s gcc-2.95 gcc
#scp grub from /group/logger/20050523_fiasco_cvs/grub
#cd grub
#./configure
#make
#make install
#/usr/local/sbin/grub-install /dev/hda1
!__RMGR Congiguration Example - Limit ~L4Linux Memory__

__Contents of menu.lst file:__
title ~L4Linux
root (hd0,0)
kernel /boot/rmgr_mod -sigma0 -configfile
modaddr 0x02000000
module /boot/main -nokdb -nowait -serial -comport 1
module /boot/sigma0
module /boot/rmgr.cfg
module /boot/vmlinuz.V2 no-scroll no-hlt l4irqack=linux root=/dev/hda1
__Contents of rmgr.cfg file:__
task modname "vmlinuz"
memory max 0x10000000 in [0, 0x10000000]

end
!__Directory/File Locations__
main kernel source
DIR: l4/kernel/fiasco/src/kern

interrupt descriptor table
FILE: l4/kernel/fiasco/src/kern/shared/idt.cpp

linux sys calls
FILE: l4linux-2.4/arch/l4/kernel/entry.S

L4 emulates syscalls
DIR: l4linux-2.4/arch/l4/emulib/

L4 emulates syscalls - main
FILE: l4linux-2.4/arch/l4/emulib/user.c
!__L4 ~APIs __
Notes from [[l4-hackers mailing archive|http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers]] (March 14, 2003):

There are currently three L4 ~APIs in more or less widespread use:
-//Version 2//, //Version X.0//, and //Version X.2// (aka, Version 4)
!!*Version 2
This is the original L4 API as implemented in Jochens assembly kernels. The API supports 64 bit thread ~IDs with subfields containing (among other things) the thread no, task no, chief no, and version no.

The chief field of the thread ID is used for implementing the Clans & Chiefs security model. A thread within a Clan can only communicate with other threads within the Clan, or the Chief of the Clan. Any attempt to communicate with any outside parties are automatically redirected to the Chief. The Chief is then used to enforce the communication security policies for the threads within its Clan.

Having large thread ~IDs also enables a relatively large number of threads/tasks to be created. However, the fixed amount of bits allocated to thread numbers and task numbers still makes the scheme unsuitable for many purposes. (There can only be a fixed amount of threads within a task. For most purposes this amount is way to high. For other purposes the amount of threads within a task is to low.) The fixed association of threads to tasks also makes it impossible to migrate a thread to another address spaces---an important operation for NUMA systems.

The original Version 2 API is very ia32 specific. ~APIs for other architectures (e.g., MIPS and Alpha) have been ported to the Version 2 API in ad hoc ways.

Fiasco implements the Version 2 API.
!!*Version X.0
This API was targeted at dealing with some of the problems experienced with the Version 2 API. The API is very similar to Version 2, the most notable differences being the 32 bit thread ~IDs and the lack of Clans & Chiefs.

The change in the thread ID came about because the Version 2 thread ~IDs were found to be unwieldly and inflexible. Reducing the ID to 32 bits freed up one register for other purposes and made thread ID handling more efficient. The freed up register enabled the IPC ABI to be use 50% more registers (i.e., 3 instead of 2) for register only IPC transfer. This boosted performance for many common micro kernel applications.

The Clans and Chiefs model of Version 2 was found to be way to inefficient for most purposes (the overhead of redirection was too great). The scheme is also unflexible since a thread is tied to a Chief for the complete lifetime of the thread (the Chief is specified in the thread ID). This prevents dynamically changing security policies to be implemented efficiently. With Version X.0 we experimented with other ways to deal with security policies. Most notable is a more flexible and efficient IPC redirection scheme (implemented in IBM internal versions of L4, not in Hazelnut).

It should be noted that the Version X.0 API was not meant to necessarily solve all the problems with the Version 2 API. Rather, the API was meant as an experimental, albeit very stable, test-bench (hance the X in the version number) to try out new ideas. It was merely meant as a step in the direction of what we envisioned the new improved next generation microkernel API to look like. In particular, the API does not solve all the issues related to flexible and efficient security policy management.

Hazelnut implements the Version X.0 API.
!!*Version X.2 (aka. Version 4)
This API aims at solving many of the problems we identified while working with the X.0 API. The task ~IDs are now completely separated from the thread ~IDs; task (address space) and thread management is separated. The memory management is more flexible. The IPC operation is more powerful and allows for medium and short size messages to be transferred more efficiently. There is support for multiprocessing, and the API enables better control over processor and system resources.

The most notable difference for the users of the new API is that there is now a clear separation between API and ABI. This makes Version X.2 (Version 4) compliant L4 applications much more portable.

Pistachio implements the Version X.2 API. Current architectures supported by Pistachio are: ia32, ia64, ~PowerPC, MIPS, and Alpha. The Version X.2 API is meant to eventually stabilize and become Version 4.

!__CVS Notes__

--Update repository:
cvs up -dP
!__Sys Call Locations__
[[L4Linux-2.4 System Call Locations]]

[[L4Linux-2.6 System Call Locations]]

[[L4Linux-2.4 System Calls]]
!__Rebooting Linux 2.6 Reboots System__

In l4linux-2.6/arch/l4/kernel/main.c --- main.c
+++ main.c
@ @ -36,6 +36,7 @ @
#include
#include
#include
+#include

#include
#include
@ @ -847,6 +848,7 @ @
l4xi_linux_main_exit_recv(&main_id, &server_env);

~LOG_printf("Terminating ~L4Linux.\n");
+ l4util_reboot();
return 0;
}
!__Names Module__

include file: l4/pkg/names/include/libnames.h
*int names_register(const char* name);
*int names_register_thread_weak(const char* name, l4_threadid_t id);
*int names_unregister(const char* name);
*int names_unregister_thread(const char* name, l4_threadid_t id);
*int names_query_name(const char* name, l4_threadid_t* id);
*int names_query_id(const l4_threadid_t id, char* name, const int length);
*int names_waitfor_name(const char* name, l4_threadid_t* id, const int timeout);
*int names_query_nr(int nr, char* name, int length, l4_threadid_t *id);
*int names_unregister_task(l4_threadid_t tid);
*int names_dump(void);
!__L4Linux task with L4 IPC __
Good example of creating an ~L4Linux task that can do L4 IPC as well: l4/pkg/loader/examples/dump-l4/

Intrusion Analysis November 2003

Wed, 20 Jun 2007 13:43:00 GMT

On November 1, 2003 a Microsoft Windows 2000 Pro machine on the Georgia Tech Honey Net was compromised by an attacker. The attack originated from eastnet on Georgia Tech's Eastnet . However, analysis of the data seems to indicate that this host was only a relay for the attack and not the attacker's actual machine.

The attack first appeared as a standard Nachi attack, but after an initial attempt to compromise the machine revealed to the attacker that the machine had already been infected, he or she switched tactics and used an ~MSBlaster style exploit to open port 4444 with root privileges, thus indicating by the sophistication and the timing that this was a life attacker not an automated program. He or she then began setting up a root-kit on the machine.

The root-kit is made up of two self-extracting .exe files. This attacker names them c.exe and x.exe. The former extracts to a directory named "svchost" with a subdirectory "service" while the later extracts to "service" and "spools." The "svchost" directory contains ~WinMngr.EXE, ident.bat, one.exe, svc.bat, win.dll, cygwin1.dll, lsass.exe, regsvc.exe services.exe, and svchost.exe. These form the core of the root-kit. The subdirectory "svchost\service" is used for storage of warez, but because the attacker does not want disk usage to be noticed, he or she only places a few files on each compromised machine. The "service" directory created by x.exe contains mostly duplicate files from the "svchost" directory (possibly to avoid path issues), but it does have one important file in thug.bat.

Our attacker extracts these files and directories to "C:\WINNT\system32\Setup." The attacker then moves into the "svchost" directory and executes svc.bat. This file is the primary installer of the root-kit. The svc.bat file sets the user name of the IRC bot in win.dll (which is actually just a plain text file) and starts both the "Remote Registry Backup" service and the "Microsoft Networks" service, but binds both to the attacker's "svchost\lsass.exe" file. This results in 3 processes called lsass.exe, though only one is legitimate. The "Remote Registry Backup" service is also bound to "svchost\ident.bat" which executes ~WinMngr.EXE, while "Microsoft Networks" is also tied to "svchost\regsvc.exe." The effect of starting all of these files as services is to make them impossible to kill via the Windows(r) Task Manager. It is necessary to stop the services these files are attached to in order to bring them down. The next step taken by svc.bat is to hide the directories created by the zip file. Using the "attrib" command, the bat file runs: "attrib +S +H spools" (aka C:\WINNT\system32\Setup\spools) and "attrib +S +H svchost." These commands set both the system bit and the hidden bit on the directories causing Windows to hide them unless the bits are unset or someone checks "show hidden files and directories" and unchecks "hide protected operating system files" in the tools->file options->view menu of any Windows Explorer window.

[img[images/image002.gif]]
__Figure 1: Windows Explorer view of system compromise__

The fact that svc.bat which came from c.exe hides a directory "spools" that came from x.exe suggests that both files were created by the same person and intended to work together as a single root-kit.

The other half of this root-kit, x.exe, provides similar tools to the attacker, but with some things added. "Spools" for instance contains a number of utilities useful for hacking, such as wget, netcat, fport, and fscan. None of these are called directly by the services that are set up. This suggests the attacker wants the ability to hack other machines from this one. While it is possible the attacker just wanted to have certain tools around for setting things up, the deletion of the zip files (presumably just so save space) combined with the small amount of warez stored on the machine seems to negate this as our attacker seems to be interested in saving space so as to not show up on a cursory disk usage analysis. Given this evidence, and the sophistication of this attack, as well as the number of compromised boxes found (some 25 machines on Georgia Tech's campus alone, including the attacking host) it seems likely that the attacking host was being used a relay and the owner is not our attacker.

The third directory created by our attacker contains more interesting tools, including one (kill.exe) that is very useful in purging the system of this root-kit. The first file ofimportance is thug.bat. This is where the "Virtual Guide Numbering" service is created and bound to "service\lsass.exe" (which gives us a total of 4 processes named lsass running) and "services\winampa.exe" (which the name of the popular media player Winamp's background executable). This gives us two more processes running that are attached to services and can't be killed from the Task Manager. The batch file then hides the "C:\WINNT\system32\service" directory in the same manner as the other two and removes x.exe.

At some point in running these various programs, one of them creates a number of registry keys. This is the root-kit's signature and can be found on any machine infected by an unaltered version. The keys are placed in ~HKEY_USERS-->S-1-5-21-79052478-1383384898-1202660629-1107(this number may be unique to each install) -->Software-->Microsoft-->Internet Explorer-->Explorer Bars-->{~C4EE31F3-4768-11D2-BE5C-00A0C9A83DA1}(again possibly unique to each install)-->~FilesNamedMRU. Each one registers the name of a file the attacker installed but not its full path. Currently, it seems logical to conclude that the programs themselves both set and read these keys, thus executing all of the files listed if any one of them is started.

[img[images/image004.gif]]
__Figure 2: registry entry of compromised system__

This root-kit does not appear to cause any actual damage to the attacked system (in fact it patches the system against future attacks on port 135), but instead sets the machine up as a warez server via IRC. The bot installed connects to irc.efnet.com and joins the channel #~XiSO, where it broadcasts repeatedly the files it has available for download from the svchost\service directory.
Fortunately, removing this root-kit is not especially difficult after it is understood. To remove it, simply do the following:

# Using the Administrative Tools, stop the services that are infected and set them to manual start. (Be careful if you decide to disable them as doing so can cause headaches if the wrong services are disabled when the system is restarted).
#Edit the C:\WINNT\system32\Setup\svchost\x.pid file to find the process id (PID) of the IRC daemon.
#Using the kill.exe found in either "service" or "spools," kill the pid using C:\kill.exe . This stops the IRC daemon from running. Your logs will no longer be flooded with IRC data. You may also safely kill all ~WinMngr.EXE, winampa.exe and cmd.exe processes. You may kill the lsass and svchost processes, but the legitimate versions of these need to be running and may or may not restart properly if killed.
#Delete, or move the directories the attacker created:
##C:\WINNT\system32\Setup\spools
##C:\WINNT\system32\Setup\service
##C:\WINNT\system32\Setup\svchost
#Using regedit, remove all the keys placed by the attacker.
#Upon first booting the machine, ensure that you have only one copy of lsass.exe running, the registry keys are gone, and that none of the illegal services started. This is your indication that the machine is clean.

In conclusion, this root-kit displays a fair amount of skill and is not the work of a "script-kiddie." Analysis of the techniques used, as well as the tools involved, suggest an experienced, though not necessarily a highly-skilled, person conducted the attack. The root-kit itself suggests that the machine attacking our Honey Net was a relay machine. The hacking tools present in the kit suggest the intended use for this kit is not just to run an IRC bot, but also to allow remote control of and subsequent hacking using a compromised box. The techniques used by the attacker make it difficult, though not impossible, to find his or her files. Once located and understood, the root-kit is easily removed. However, the complexity of the kit itself and its potential to reinsert parts of itself make it difficult to deal with until it is understood. Had the attacker removed kill.exe, not used x.pid, and used executables instead of batch files the root-kit would have been very difficult to remove indeed. In short, this was a basic attack, based on someone else's work, that used good tools that could be improved to be very difficult to remove.

Turn off Auto WikiWord Plugin

Wed, 20 Jun 2007 13:39:00 GMT

// //[[Alan Watson|http://www.alan-watson.org/]]
// //2 September 2005

// //Standard ~TiddlyWiki implicitly links ~WikiWords. This plugin changes that behaviour, causing ~WikiWords and ~WikiWordEscapes to be treated as normal text. You can still make explicit links to tiddlers using [ [ and ] ].

// //To use this plugin, copy this tiddler to your ~TiddlyWiki and tag it with systemConfig.

// //The code really is a bit of a hack. It would be cleaner to add a boolean option and a tiny bit of logic to Tiddler.prototype.changed and wikifyLinks. Instead, we change the ~WikiWord regular expresssion to use reversed ~BOMs, which should not appear in well-formed text.

{{{
wikiNamePattern = "(\uFFFE)(\uFFFE)";
setupRegexp();
for (var t in store.tiddlers)
store.tiddlers[t].changed();
}}}

October 2005 – March 2006

Wed, 20 Jun 2007 13:38:00 GMT

!__1. Deployments__
!!''1.1 Current technologies deployed. Describe anything that you have deployed that is collecting information, including honeynets, client honeypots, honeyd, mwcollect, or anything else honeypot related.''
We are running a GEN II Honeynet with a variety of ~OSs of interest. We are using the honeywall "roo" CDROM and conduct all monitoring of the honeynet on an analysis box that is separate from the honeywall (bridge) machine. We continue to maintain a Darknet within our honeynet and a majority of our real machines are high-interaction honeypots, although we are starting to experiment with low-interaction honeypots (nepenthes). We have one linux (~RH8) and two Win XP (w & w/o ~SP2) boxes.

Our focus is on using the honeynet as an intrusion detection tool to help secure the campus network and to promote visualization research. We aim to make management of the honeynet more scalable by providing real-time visualization1, daily report generation2, trend analysis3, and attack analysis tools4. Additionally, we have worked on a network capture (pcap) anonymization script5 that help the administrator to share data to promote further research.

1. ~HoneyTrap, Rumint, ~SecVis, ~VisualFirewall
2. ~HoneyReport, ~TrojanSSH
3. FAD: Flow Analysis Database
4. Rumint, ~SecVis
5. ~PacketScrubber

!!1.2 Activity timeline: Highlight attacks, compromises, and interesting information collected.
During this last quarter, we observed only one successful compromised. Earlier this year (say about mid February) we were SSH brute forced. The attacker installed a simple spam mailing script and tested it a couple of times before the compromised was detected and cut. The details of this attack will be release to the public at a later date.
!__2.0 Findings__
!!2.1 Highlight any unique findings, attacks, tools, or methods.
!!2.2 Any trends seen in the past six months.
Our most notable finding is that there has been a stark decrease in on-campus activity seen on the honeypots. We believe this trend (we are still investigating) is due to the partitioning our campus network with separate firewall, effectively separating us from the dorm networks and removing the more interesting attacks. Also, our Office of Information Technology (OIT) in alliance with our Residential Network Office (~ResNet) as deployed a START system that scans new machines as they register on the network before they are allowed normal access. OIT also actively scans the networks for known vulnerabilities.

We are also trying to perform long-term analysis, but haven't progressed far in our research yet. Here are some initial graphs to show flow counts over time.
[img[images/http.png]]
[img[images/smb.png]]
[img[images/ssh.png]]
[img[images/WindowMessenger.png]]

!!2.3 What are you using for data analysis? What is working well, and what is missing, what data analysis functionality would you like to see developed?
We are using our own custom tools for data analysis: ~HoneyReport, ~SecVis, Rumint, ~TrojanSSH, FAD, and ~HoneyTrap. We will describe them in Section 4.

!__3.0 Lessons Learned__
!!3.1 What new positive things can you share with the community, so they can replicate your success?
We are working on new reporting and visualization techniques that will aid in maintaining a honeynet, responding to attacks, and analyzing trends in data. We are also working on packet anonymization.
!!3.2 What new mistakes can you share with the community, so they don't make the same mistakes?
We have repeated this often, but documentation of the current state of our honeynet is constantly stale and is hard to keep updated. We want to think of ways that honeynet deployment is almost self-documenting.
!!3.3 Are there any research ideas you would like to see developed?
We are interested in continuing our research in reporting and visualization and we want to consider practices that are self-documenting, meaning that in the very act of doing our tasks, current documentation is kept.
!__4.0 New Tools__
!!4.1 What new tools or technology are you working on?
Data analysis is our primary focus. We are working on several projects to enable more real-time monitoring and daily report generation. Additionally, we are also developing a pcap file anonymization tool.

Our daily reporting tool is called ~HoneyReport. Our tool duplicates much of the functionality of ~HoneySnap, developed by the UK Honeynet Project, but has some additional functionality that we find useful. We believe that everyone's reporting needs are different and that making a generic tool that everyone would like may be difficult. With that in mind, our tool generates reports that are useful to our organization and may be useful to other organizations.

~HoneyReport parses pcap files to generate flow records and captures traffic from various protocols. The flow records are saved to a database for our FAD analysis later. Statistics are then run on the flow data to generate reports on top attackers, biggest flows, port hit counts, and other interesting data. The reports are generated as HTML documents and stored on our data processing box. The HTML is then rendered as a text document using "links", is PGP encrypted, and then sent via email to the honeynet administrators. There are two other reports with different information that is sent to Georgia Tech's Office of Information Technology (OIT) for doing campus intrusion detection. An example ~HoneyReport report will be provided with this status report.

We have written before about Greg Conti, Julian Grizzard, and Sven Krasser's work on Rumint and ~SecVis. These tools provide a real-time or forensic analysis visualization using parallel coordinate plots. A screenshot of ~SecVis is provided below.

[img[images/secvis.jpg]]

We have been interested in getting information about keystrokes and logins via SSH. We originally tried to use the sebek client but found it was logging too much information. Instead, our solution was to simply trojan our version of SSH to drop all the password attempts and record each keystroke. Each login attempt will send the attacker IP, attempted username, and attempted password via a UDP packet sent to an unrouteable address (so it doesn't leave the honeynet). The honeywall can then capture that information and present it in the ~HoneyReport report. So far we have collected a few thousand login username/password pairs including some interesting ones like: harrypotter/harrypotter. Hopefully we can use this information later to discuss trends in password attempts (e.g., longer password attempts, more dictionary words). Successful logins generate a different record type in the UDP packet sent to alert the honeywall of a successful login (for fast reporting and reaction). A third packet type is used to send keystrokes. At a later date, we will present how to edit sshd to drop this information.

We are logging flows into our Flow Analysis Database (FAD) for performing long-term trend analysis. This database was used to generate the four flow count charts above. Currently there are about 3 1/2 million flow records in the database covering approximately the last 3 years. We are currently redesigning this tool to provide a richer repository of information and keep much more metadata about attackers such as traceroute, ping times, whois records, and country of origin. We will use this to generate week, monthly, and yearly reports of honeynet activity.

[img[images/CountryCounts_200602.png]]

We have just started research in a new real-time, passive visualization interface called ~HoneyTrap. This interface is meant to remain on the screen of a computer in the corner or on a secondary monitor. The administrator would simply glance at it periodically to see if new activity is spotted on the honeynet. This is a flash application that polls a web page that generates flash consumable data structures from an alarm database. The flash application continues to poll the webserver every five seconds to check for new alarms. We are working on a write up for this tool and will deliver a pre-publish copy to the Alliance. The rest of you must wait until we've published.

[img[images/HT_3.1_02.png]]

Our last tool is ~PacketScrubber, a pcap header and payload anonymization script. This script parses packets, maps the IP addresses using multimap techniques that somewhat prefix preserving, updates checksums, maps payload-embedded IP addresses, removes hostnames and netbios share names, and offsets mac addresses. In trying to share this tool with other organizations, we have found, just like with reporting, everyone's needs are different. We feel that we provide a lot of novel functionality that could easily be modified to suit different organizations' needs. We are working hard to provide a publicly releasable version of this tool.

!!4.2 Would you like to integrate this with any other tools, or you looking for help or collaboration with others in testing or developing the tool?
We would like to release ~HoneyReport, ~HoneyTrap, and ~PacketScrubber and receive feature requests for future enhancement. We will enlist several undergraduate students to join us and help us enhance these tools and motivate them to future research.

We have learned that packet anonymization is a daunting task, but we are able to do a good 95% approach with our current methods. We would like to find developers to write ~NetPacket modules (in perl) to dissect more packet types.
! __5.0 Papers and Presentations __
!!5.1 Are you working any papers to be published, such as KYE or academic papers?
We are currently in the first phase of writing a paper on ~HoneyTrap and hope to submit it to ~VizSec 2006.
!!5.2 Are you looking for any data or people to help with your papers?
We would be happy to discuss ideas for possible publications.
!!5.3 Where did you publish/present honeypot-related material?
Julian Grizzard presented "Visualizations for Honeynet Data Analysis" at the Department of Energy Honeynet Workshop in March.
Published paper:
G. Conti, K. Abdullah, J. Grizzard, J. Stasko, J. Copeland, and M. Ahamad, and C. Lee, "Countering Security Analyst and Network Administrator Overload Through Alert and Packet Visualization," IEEE Computer Graphics & Applications, March/April 2006, pp. 60-70, vol. 26, no. 2.
!__6.0 Organizational__
!!6.1 Changes in the structure of your organization.
Christopher Lee is transitioning to lead of the Georgia Tech ~HoneyNet and will be responsible for daily maintenance, status reports (including this one), communicating with other alliance members, recruiting researchers, and sharing results. Julian Grizzard will graduate in May.
!!6.2 Your feedback on Alliance activities.
We are excited to see the new ways that we can communicate with other Alliance members, especially being able to communicate with new honeynet groups as to expand our base of deployed honeynets. The internal website, SILC channel, mailing lists, and IRC channels are excellent for contacting other members, but it would be helpful to have more chatrooms for various purposes (e.g., not just Roo development). We would also like to see an emphasis on detecting and understanding botnets and phishing. The German Honeynet Project's work on the topic has been quite promising.
!!6.3 Any suggestions for improving the Alliance?
We see a lot of good improvements with internal, mailing lists, and IRC. We would like a general topic SILC channel along with several other specific topics such as analysis, visualization, and reporting.
!__7.0 Goals__
!!7.1 Which of your goals did you meet for the last six months?
*We developed an anonymization tool: ~PacketScrubber
*Developed ~HoneyReport, ~HoneyTrap, ~TrojanSSH, and FAD
*Successfully captured an SSH break in and spamming package
*Started generating new reports for OIT that they requested
!!7.2 Which of your goals did you not meet for the last six months?
*We did not release any tools that we developed since the last report.
!!7.3 Goals for the next six months
1. Develop anonymization tools so that data can be publicly released
2. Continue visualization work in real-time, daily, and long-term analysis
3. Release tools: ~PacketScrubber, ~HoneyReport, and perhaps ~HoneyTrap
4. Contribute to ~SotM
5. Expand our low-interaction honeypot deployment
!__8.0 Misc. Activities__
!!8.1 Anything else not covered you would like to share.
!__Appendix A__
Example ~HoneyReport report. All data is representative.

http-equiv="content-type">

link="#0000ee" vlink="#551a8b">

style="border: thin solid black; background: rgb(255, 255, 204) none repeat scroll 0%; -moz-background-clip: initial; -moz-background-origin: initial; -moz-background-inline-policy: initial;">
Honeynet Report for 20060411
Generated on 04/12/2006
Overall Throughput
In: 43537 packets, 89163776 bytes
Out: 37403 packets, 76601344 bytes
Flows inbound: 5021, Flows outbound: 0
data/20060411/pcap.20060411.1144713662 (20835456)
eb9b69993d9bf3ba7b5d65743229df79
Outbound Flows
Id Start Time Src IP Dst IP Src Port Dst Port Pkts Bytes
Packets vs. Time
^ | 50,000
* | 49,000
* | 48,000
* | 47,000
* | 46,000
* | 45,000
* | 44,000
* | 43,000
* | 42,000
* | 41,000
* | 40,000
* | 39,000
* | 38,000
* | 37,000
* | 36,000
* | 35,000
* | 34,000
* | 33,000
* | 32,000
* | 31,000
* | 30,000
* | 29,000
* | 28,000
* | 27,000
* | 26,000
* | 25,000
* | 24,000
* | 23,000
* | 22,000
* | 21,000
* | 20,000
* | 19,000
* | 18,000
* | 17,000
* | 16,000
* | 15,000
* | 14,000
* | 13,000
* | 12,000
* | 11,000
* | 10,000
* | 9,000
** | 8,000
** | 7,000
* ** | 6,000
* ** | 5,000
* ** | 4,000
* ** | 3,000
* ** *| 2,000
* ** *| 1,000
***** ** *** ************* *** *****************| 0,000
------------------------------------------------+
000000000000000000001111111111111111111122222222
001122334455667788990011223344556677889900112233
030303030303030303030303030303030303030303030303
000000000000000000000000000000000000000000000000
Top 10 Flows
Source IP Src Port Destination IP Dst Port Packets Bytes
58.251.33.172 40738 100.100.100.39 22 49 100352
58.251.33.172 58260 100.100.100.33 22 48 98304
58.251.33.172 39313 100.100.100.33 22 48 98304
58.251.33.172 54085 100.100.100.33 22 48 98304
58.251.33.172 53318 100.100.100.39 22 48 98304
58.251.33.172 42196 100.100.100.39 22 48 98304
58.251.33.172 43757 100.100.100.33 22 48 98304
58.251.33.172 50125 100.100.100.19 22 47 96256
216.57.7.90 34041 100.100.100.13 22 45 92160
58.251.33.172 43101 100.100.100.14 22 44 90112
Managed IPs
Mananged IP Ports Date Hostname
Top Ten Offenders
Attacker IP Country Packets
58.251.33.172 - 69052
216.57.7.90 US 8355
140.247.94.201 US 600
210.103.124.7 KR 293
212.227.62.110 DE 290
204.16.208.114 - 268
80.168.22.243 GB 240
62.94.87.181 IT 178
125.188.163.49 - 160
67.90.90.10 US 157
204.16.208.75 - 154
204.16.208.106 - 141
Per Port Statistics
Proto Port Pkts Bytes
tcp 21 56 114688
tcp 22 77990 159723520
tcp 80 310 634880
tcp 113 124 253952
tcp 555 128 262144
tcp 697 79 161792
tcp 1021 122 249856
tcp 1532 114 233472
tcp 2100 138 282624
tcp 3128 2 4096
tcp 3306 157 321536
tcp 3372 94 192512
tcp 5900 278 569344
tcp 8080 4 8192
tcp 10000 240 491520
tcp 23241 112 229376
udp 2 7 14336
udp 1026 799 1636352
udp 1027 159 325632
udp 1030 4 8192
udp 1031 2 4096
udp 1032 2 4096
udp 1033 9 18432
udp 4321 3 6144
udp 4329 7 14336
HTTP Traffic URIs
Client IP Destination IP URL
60.208.212.1 100.100.100.43 GET http://hacker.org.ru/prxjdg.php
60.208.217.95 100.100.100.43 GET http://hacker.org.ru/prxjdg.php
60.208.219.17 100.100.100.43 GET http://hacker.org.ru/prxjdg.php
60.216.176.56 100.100.100.43 GET http://hacker.org.ru/prxjdg.php
62.94.87.181 100.100.100.43 HEAD /
218.56.240.198 100.100.100.43 GET http://hacker.org.ru/prxjdg.php
218.56.243.116 100.100.100.43 GET http://hacker.org.ru/prxjdg.php
221.196.242.108 100.100.100.43 GET
http://www.proxygrade.com/proxygrade.php?hash=7D86E0933DFFEAF682CF812B
005099B04EBEAD5324EC
GET
http://www.proxygrade.com/proxygrade.php?hash=7D86E0933DFFEAF682CF812B
005099B04EBEAD5324EC
FTP Sessions
1144718479.532958: 84.173.189.8:2605 -> 100.100.100.4:21
1144718479.543423: 84.173.189.8:2606 -> 100.100.100.6:21
1144718479.545087: 84.173.189.8:2607 -> 100.100.100.9:21
1144718479.546555: 84.173.189.8:2608 -> 100.100.100.11:21
1144718479.548001: 84.173.189.8:2609 -> 100.100.100.17:21
1144718479.548956: 84.173.189.8:2610 -> 100.100.100.18:21
1144718479.550266: 84.173.189.8:2611 -> 100.100.100.19:21
1144718479.551426: 84.173.189.8:2612 -> 100.100.100.27:21
1144718479.552802: 84.173.189.8:2613 -> 100.100.100.28:21
1144718479.553749: 84.173.189.8:2614 -> 100.100.100.31:21
1144718479.555584: 84.173.189.8:2615 -> 100.100.100.32:21
1144718479.556792: 84.173.189.8:2616 -> 100.100.100.37:21
1144718479.558209: 84.173.189.8:2617 -> 100.100.100.38:21
1144718479.559980: 84.173.189.8:2618 -> 100.100.100.39:21
Trojaned SSH
100.100.100.43
root:root
root:root123
root:password
root:!@#$%^&*(
root:123456
root:root1234
root:antonio
root:root12345JJJJ
root:12345Ã¹Ã¹Ã¹Ã¹Ã¹Ã¹Ã¹Ã¹
news:news
news:news123
news:123456
news:12345""""""""
john:john
john:john123
john:12345--------

Honeynet Network Capture Anonymization

Wed, 20 Jun 2007 13:31:00 GMT

In order to release captures of network attack traffic to the public, much of the sensitive information contained within the capture files must be removed. The goals of our anonymization algorithms are to protect the sensitive information while allowing researchers and the public at large to examine and analyze the network attacks. Our solution uses one-to-one mappings of IP addresses (even within payloads) and overwriting of hostnames.

!Anonymization Methods
------------------------------------
!!__IP Address Mapping__
We map the top two octets and the bottom two octets separately. For the top two octets, we generate one map and for the bottom two octets we create a map for each of our subdomains with the Georgia Tech IP space and one for other non-Georgia Tech addresses. Some /16 networks should not be mapped since they are private, unroutable, or have some special attribute. We identified several networks that we do not map the top two octets as listed below. For the remaining networks, we randomly mix the mapping.
*0.0.0.0/8
*10.0.0.0/8
*127.0.0.0/8
*169.254.0.0/16
*172.16.0.0/16
*192.168.0.0/16
*224.0.0.0/4
*240.0.0.0/4
The lower mappings consist of mapping the lower two octets of the IP addresses. In the lower mappings, if the last octet is equal to 0 or 255, it is mapped to another address ending in 0 or 255. All other lower two octets are randomly mapped.

!!__IP Header Anonymization__
For each IP packet, the packet is first disassembled. Then, the source and destination IP addresses are remapped, and then reassemble the packet. We use a perl module, ~NetPacket::IP for the purpose of parsing and reassembling the packet. This perl module is kind enough to recalculate the IP header checksum so that an attacker can not calculate the original IP addresses.

!!__ICMP, TCP, and UDP Header Anonymization__
The next layer of the communications stack gives a new set of details that could be used to calculate the original IP addresses. Both the TCP and UDP header checksum are calculated from a psuedo-header which contains the source and destination IP addresses (from the IP header). ICMP is tricker. ICMP oftentimes embeds the headers of rejected packets within its payload that require further sanitization. We do a simple test for embedded ~IPv4 packets by looking for 0x45 as the first byte of the payload. If the test detects an embedded packet, the algorithm recurses on the payload. ~NetPacket::TCP and ~NetPacket::UDP were used to parse and reassemble the TCP and UDP packets respectively.

!!__Upper Layer Packet Anonymization__
Payload anonymization is too difficult to describe without risking censorship. Various protocols find interesting ways of hiding revealing information in the payload in ways completely unparsable by anything (including the original software). We have leaned on the side of protecting privacy at the risk of destroying information in the payload. To this end, we overwrite data that matches a very general regular expression with 'X' characters, and hope that it was not something needed for analysis.

!!!DNS Protocol Sanitization
Among the various problematic packets that require anonymization, are DNS packets. The format of DNS packets varies upon the codes within the packet and requires a full decode to correctly manipulate. For example, if the packet is a response packet and has a code equal to 0, then the last 4 bytes are an IP address that must be mapped. If the code was equal to 3, a dynamic update, then there yet another domain name that must be removed.

!!!Samba Protocol Sanitization
Another frustrating protocol is the Windows Networking protocol, known as samba. The Tree Connect ~AndX Request message includes a path portion that contains a unicode encoded string with slashes and a host network name, IP address, or ~NetBios name. Since the format of this path is difficult to anticipate, we simply replaced any printable character between the beginning two slashes, and the next slash. (E.g. \\POTENTIAL.NOWHERE.COM\IPC$) There are other messages such as the Trans2 Request that sometimes has the hostname as the file specification, but without the proper slash notation. This much be removed by a general regular expression. The netbios name is impossible to recognize without a full decode of the SMB protocol. We have not been able to accomplish this yet.

!!!IRC Traffic Sanitization
Currently we only perform regular expression search and replace on IRC traffic. No attempts were made to actually decode the protocol. The regular expression contains all letters, digits, at-symbols, and periods ending with a valid domain such as com, edu, jp, nl, ro, and biz. This has an unfortunate effect of obfuscating entities that are not proper domain names because of the generality of the regular expression.

!Future Work Needed
---------------------------------
We have only begun the rigorous work of packet sanitation and much work is needed. First, we need to learn from the community what information is vital to retain in order for proper analysis and balance their needs with the complexity of maintaining privacy. Secondly, decoders are needed for many protocols, but focusing first on protocols used during attacks such as SMB, FTP, IRC, HTTP, and DNS. Next, a flexible but fast-running packet manipulation framework needs to be made that can rapidly manipulate packets.

!Conclusion
--------------------
The Georgia Tech Honeynet team has created a pcap-file anonymization tool in PERL that allows for quick remapping of IP addresses and does some packet decoding and a lot of string searches and replacements in order to anonymize the traffic captures. We believe this to be a good first-order approach to the problem of packet anonymization, but a more flexible approach is needed for future work.

Past Research Projects

Wed, 20 Jun 2007 13:30:00 GMT

!__Data Link Layer Security__
Nsa is investigating architectural approaches to secure the data link layer (Layer 2) in wired local area networks. The main objectives of this research are to address the weak link between Layer 2 and upper layers and accommodate future network architectures.
!__Traffic Engineering/Quality of Service__
The objective of this research is to develop a multipath traffic engineering framework to deliver more equal shares of bandwidth to best-effort users as compared to traditionalshortest path algorithm. In a multi-service capable network, some portion of the bandwidth is reserved for guaranteed services and the leftover portion is dedicated to best-effort service. This research examines a problem of traffic engineering for the remaining network bandwidth which is utilized by best-effort traffic where demands are not known a priori. This framework will result in making the limited available best-effort traffic bandwidth more equitably shared by the best-effort flows over a wide range of demands.
!__Re-establishing Trust in Compromised Hosts__
We are investigating approaches to automatically recover from compromises without the need to completely reinstall the system. An [[overview poster|self-healing-systems.pdf]] of this research is available. This research topic uses the [[Fiasco L4 microkernel|http://os.inf.tu-dresden.de/fiasco/]] as a secure foundation of integrity. You can find local L4 notes and more on the [[spine]] webpage.
!__Large-Scale Network Simulation for Security and Survivability Evaluation__
In a project conducted jointly with [[MANIACS|http://www.ece.gatech.edu/research/labs/MANIACS/]], NSA is researching on large-scale simulations of critical Internet infrastructure including DNS and BGP using the [[Georgia Tech Network Simulator|http://www.ece.gatech.edu/research/labs/MANIACS/GTNetS/]].
!__Network Security Visualization__
NSA is investigating novel approaches to visualize network security data for intrusion detection and forensic analysis.

TWSECategories

Tue, 19 Jun 2007 20:27:00 GMT

IS410
Systems Analysis
IS420
Advanced Database
IS450
Web Programming I
Acct 201
Intro to Accounting